[TIMOB-26675] Android: Add getLastLocation to FusedLocationProvider
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | n/a |
Status | Open |
Resolution | Unresolved |
Affected Version/s | n/a |
Fix Version/s | Release 10.2.0 |
Components | n/a |
Labels | android, geolocation |
Reporter | Michael Gangolf |
Assignee | Joshua Quick |
Created | 2018-12-20T18:28:38.000+0000 |
Updated | 2021-10-19T20:44:53.000+0000 |
Description
The current implementation of the
FuseLocationProvider
is not using the getLastLocation()
method:
https://github.com/appcelerator/titanium_mobile/blob/master/android/modules/geolocation/src/java/ti/modules/titanium/geolocation/android/FusedLocationProvider.java
According to https://developer.android.com/training/location/retrieve-current#java you can use getLastLocation()
on the provider.
Adding this to the Java file mentioned above:
fusedLocationClient.getLastLocation().addOnSuccessListener(new OnSuccessListener<Location>() {
@Override
public void onSuccess(Location location)
{
// Got last known location. In some rare situations this can be null.
if (location != null) {
Log.i("Fused", "Location: " + location);
}
}
});
works fine, it just needs to transfer those values to the JS location
event .
Thanks for the feature ticket. Our engineers will look into it. Thanks.
PR: https://github.com/appcelerator/titanium_mobile/pull/13133 had this in my queue for a longer time :)
getLastLocation
will get the last cached location in the device and that's sometimes far from the current location. let us say an app request location data on day 1 so this location will be the last location requested on the device then after 30 days if no other app make a new location request thengetLastLocation
will get that same old location that was requested since 30 days ago So I don't thinkgetLastLocation
should firelocation
If you want to try it please use my ti.locationservices module https://github.com/AhmedMSayed/ti.locationservicesThanks for the feedback [~ahmed.mohamed20320]! I have to check it again but shouldn't that be covered by the included timestamp? But you are right, if you don't check that it can be very wrong. I'll have a look again. BTW: I'm using the userLocation event of ti.map since that is using internal map stuff by Google and returned a proper fix quicker than geoolaction in my tests.