The following is how I am initializing the LocationDisplay
Criteria criteria = new Criteria(); criteria.setAccuracy(Criteria.ACCURACY_FINE); AndroidLocationDataSource androidLocationDataSource = new AndroidLocationDataSource(mContext, criteria, 250L, 1L); mLocationDisplay.setLocationDataSource(androidLocationDataSource); mLocationDisplay.setWanderExtentFactor(0);
You'd think this would mean it updates up to four times a second, but it doesn't.
Especially after resuming the activity, it updates whenever it feels like it.
Sometimes that's two seconds, sometimes five seconds, sometimes 15 seconds.
Here is an illustration.
A service running in the background IS getting the location every second through locationManager.
The arrow just isn't keeping up.
It will catch up to the track once in a while.
How do I make the LocationDisplay behave decently?
I could create my own LocationDataSource - maybe.
But it would be a major pain because you don't allow subclassing and your code is very obscure.
And how do I know the bottleneck isn't somewhere else besides the LocationDataSource?
The AndroidLocationDataSource receives location updates form the Android framework's LocationManager. Internally it calls LocationManager.requestLocationUpdates() passing in the parameters that you have provided to the AndroidLocationDataSource constructor. The AndroidLocationDataSource does some additional filtering on these location updates. Any location that is more than twice as inaccurate as the previous location's horizontal accuracy (Location.getAccuracy()) is ignored. Please check the accuracy of the locations you are receiving and see if this criteria might apply, thus you won't see more frequent location updates.
In addition, the `minTimeMS` parameter of LocationManager.requestLocationUpdates() doesn't guarantee that you will get updates every 250ms. See documentation:
The elapsed time between location updates will never be less than this parameter, although it may be more depending on location availability and other factors.
Yes, I do believe the accuracy of the locations that I and customers are receiving makes a difference. I don't have any control over what that accuracy is and whether the reported accuracy is actually real or bogus.
I am all in favor of filtering, and in fact the dots you see are filtered using a Kalman filter.
Do you know the reasoning behind that filter? Is this a mathematically proven way to do so? Has it proven to be helpful and user friendly?
End users are simply seeing it as a bug.
But I take it I have to reinvent the wheel with a LocationDataSource if I don't want this filtering?
There is currently no way to configure the filter of an AndroidLocationDataSource as a user. Your only way to work around this right now is to implement your own LocationDataSource. We will consider configuration of the filter as an enhancement for a future release.
I am seeing similar behavior with LocationDisplay specifically on Android 10 devices. Essentially what happens is that if a device is stationary for something like 5+ minutes LocationDisplay listener stops responding (LocationDisplay.LocationChangedListener()).
If I move the device or pan on the mapview then I start getting LocationDisplay updates again. I have verified that Android LocationManager on change events are still hitting even though the ESRI LocationDisplay listener no longer responds. What gives here?
Just to add to this I put a timer on this and what happens every time is if the device is not moved the locationDisplay will only update for 64 seconds. If accelerometer goes it will go for exactly another 64 seconds.
Hi Gunther, The weird thing about this is I do not see this behavior in Field Maps application on Android. Even if device is stationary for a long period of time the GPS Cursor keeps updating. How did Doug Morgenthaler and crew get around this?
On further investigation the official GitHub ESRI Sample project for 100.9 (display-device-location.java) Android exhibits the same behavior so this has got to be a bug. If I add an Android LocationManager LocationListener it continues to update every second, even after device is stationary for over 64 seconds. This definitely seems wrong.