What is the ride request pickup.eta value once driver has arrived to pickup location? Is it set to 0? Is it not provided? Else?
Also, is there a way to set driver's current location on sandbox testing?
From what we see, pickup ETA usually will only count down to 1. We don't see the behavior of it being '0'. Once the driver arrives and the trip starts, the pickup ETA will disappear. Essentially you should show whatever the "pickup ETA" is if the value is there.
"Also, is there a way to set driver's current location on sandbox testing?" - There is not, but you can simulate the change in behavior from arriving to in progress in the Sandbox.
Hope that helps!
Related
I made an attendance app in Flutter in which I want to restrict employees to use only network provided time so that employees won't be able to temper the date and time.
Is there any option or solution to implement this in android and iOS as well?
Using this package datetime_settings we will get the settings of Automatic date & time of mobile so when automatic date & time is on mobile will give us an accurate network time otherwise we will show an error to turn on the automatic date & time in settings. That's how I used to restrict users to use only network-provided time.
I'll tell you what worked for me. Hope this can help you. I don't know if it's the most optimized way to do it, but it worked very well for me:
You need to create an internal clock for your app, and from this, use it instead of the DateTime.now() function. For this, you must take the server time when opening the app, and keep it updated with a timer that runs every 1 second.
Please note that the app goes to sleep (or closes) when the device is locked or the app is minimized for a certain amount of time (this depends on the operating system and battery saver settings), thereby stopping the internal clock, and consequently, it is delayed when the app is activated again. In my case, I got around this problem by using a foreground service that I designated to perform this task (I used flutter_foreground_task). Another advantage of using a foreground service, is that the user can close the app and the clock keeps running (and in my case, I also perform other simple tasks periodically).
If the user does not manipulate the system time, the difference should never reach 1 second.
Optionally, you could check when retrieving the server time, the difference with the device time, and if it is greater than a certain gap that you determine, warn the user, so that he can correct it if he prefers, so that he does not see a discrepancy with the time recorded and displayed by the application.
Regards.
i'm implementing an app where i need to track user's location by the following:
track user's location while the app is in the background or closed
if the user's location is changed for about 2000 meters i should perform an API call.
my approach for this problem is the following:
the first time the user launches the app i start monitoring for a region using his current location
if the didExitRegion is triggered, i perform the API call and replace the current monitored region by a new region using the current location as the center of the new region.
this works fine when the app is in the foreground as the location that is returned from the location manager is accurate.
But if the app is in the background then the location manager will not return an accurate location since it's running for the first time and the first coordinates that are returned are not accurate.
the question is how can i get an accurate location of the user when the didExitRegion is triggered in the background?
thanks
I have not had a lot of luck with didExitRegion: firing reliably; it often fires much further away than the edge of my region.
I'd suggest you use CLLocationManager's -startMonitoringSignificantLocationChanges, if you just need an API call every 2km or so. If your accuracy/precision is important, just register location services as a necessary background state (UIBackgroundModes in your app plist; you may need to do this to use the significant change API from the background, too), and use the normal -startUpdatingLocation, with appropriate distanceFilter and desiredAccuracy field values on your CLLocationManager instance.
Several things happening here.
You mentioned that the region change trigger is a little variable. This is deliberate; to avoid high numbers of triggers being fired as you walk down the boundary between two regions, there is some stickiness to the triggering, in both time and position.
From the documentation (http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/LocationAwarenessPG/CoreLocation/CoreLocation.html#//apple_ref/doc/uid/TP40009497-CH2-SW1)
The system does not report boundary crossings until the boundary plus a designated cushion distance is exceeded. You specify the desired cushion distance for a region when you register it using the startMonitoringForRegion:desiredAccuracy: method. This cushion value prevents the system from generating numerous entered and exited events in quick succession while the user is traveling close the edge of the boundary.
Getting an accurate position is no different from normal. You start up the location manager and wait until you get a location update with the desired accuracy. Shut down the manager and use the position.
Because you're running in the background, you only have ten minutes to do this, and you have to tell the OS that you're doing background processing using UIApplication's startBackgroundTaskWithExceptionHandler. Plenty of documentation on that elsewhere.
Hope that helps.
If I set my CLLocationManager's desired accuracy to be kCLLocationAccuracyKilometer (accurate within a kilometer) will the iPhone deliver a better position eventually, when it gets it ? Or will it stop at my desired accuracy. I can't find this in the documentation.
The idea is that I need a fast fix for the location, but then I would like to go more accurate. Will I have to code this myself, or is it done for me automatically ?
I don't know if the following is 100% correct, but I am pretty sure it works like this: the accuracy filters are primarily designed to save energy. So if you specify that kCLLocationAccuracyKilometer is enough for you and the OS is pretty certain that it can locate you accurately within 1 km using triangulation only, it won't even power up the battery-draining GPS unit. So regarding your first question, the location manager will stop as soon as it reaches your desired accuracy.
Regarding the second question: I don't think the accuracy filter has any influence on the time you receive your first location update. The OS often caches your last known location and will deliver that one almost instantly even if you have specified a very high accuracy. Subsequent location updates will get more and more precise.
You should be able to easily test for yourself if this is indeed the real behavior.
Set the best accuracy you need (but not more, because location services consume too much power). LocationManager will call didUpdateToLocation of your CLLocationManagerDelegate every time accuracy is improved. Stop updating location as soon as you can to prevent battery exhausting.
No, it will stop at the specified accuracy. If you request only kCLLocationAccuracyKilometer then the GPS receiver won't be powered on and it will get no better than WiFi or Cell tower triangulation. [The only exception would be if another app in the background (like TomTom nav) already has the GPS on for high accuracy fixes, then you might get the high (<300m) accuracy fixes too).
If you want better you have to request it and you might as well request it immediately, you'll get the fast fix (1000m accuracy) fix right away and in a minute or two you'll get the high accuracy GPS fix (well, it can take 30 seconds up to 10 min depending on several things). No special coding is required, just specify the accuracy you eventually want.
I am wondering how CLLocationManager's distanceFilter work. According to the docs,
The minimum distance (measured in meters) a device must move laterally before an update event is generated.
So has the phone already gathered the location, but distanceFilter just prevents my call back from getting notified?
I don't see how using the distanceFilter saves battery life, it seems like a Catch-22.
I believe quantumpotato's comment is close. Through Apple's own testing, whatever, they've determined what power level they have to use on the antenna to get readings within a certain accuracy.
As someone who has used this API, I agree with you, it's not perfect and it is somewhat misleading. Think of those flags as "desired levels" and depending on the type of app you want to make, you just need to pick one.
I have been using SOAP to deal with Salesforce.com and have been using the getUpdated() call, using the timestamp I retrieve from the getServertimestamp() call.
I have watched my process check, (it polls every minute) and a few seconds after I save the change in the Sandbox environment, I see it poll, get no <ids> in the getUpdated call, and then on the next poll, the modified id shows up.
Is there a backend replication delay in SFDC? I suspect there is, but have had no luck in identifying the magnitude of it. Anyone else experienced this?
Additionally, I realize I should mention, this is all in a Sandbox copy of the environment, which may confuse matters even further.
Update: I just tested, and I made a change, and my poll ran 48 seconds later, and did not see the updated object. But 1 minute 48 seconds later it did see it. So that is one data point. (I know my SOAP endpoint and Web interface are both running on the same server at SFDC, tapp0).
There's no delay in the recording of the change, but the getUpdate/getDeleted calls round down the specified time to the nearest minute, so a finish time of now, gets rounded down, and the just made change falls outside of the range.
Also, if you're doing near realtime replication via these calls, then make sure to pay attention to the inflight transaction timestamp returned, otherwise you can miss changes (as the change timestamp can't be the actual transaction commit time)