Essentials: Geolocation - Location Updates

Created on 13 Jun 2018 · 21Comments · Source: xamarin/Essentials

At the moment iOS is limited to requesting When In Use permission as far as I can tell. Our app would like to request Always permission. Is this planned at all? I realise that it is very platform specific.

VS bug #735668

feature-request needs-more-discussion proposal

Source

Ryan-Palmer

👍2

Most helpful comment

I think we should focus first one: Running App & View and go from there.

In line with this previous comment, is there a chance we can split this feature request into two? One for "Location Updates" and one for "Location Updates While App Backgrounded"? The former should be pretty straightforward as it's already been implemented in James M's Geolocator library.

Completing that first part will enable teams currently using the original Geolocator abstractions to start migrating to this one.

jixer on 24 Apr 2019

👍9

All 21 comments

This is currently not planned at the moment as background updates require a lot of implementation details on iOS/Android/UWP as they are vastly different systems. I will update the title though.

jamesmontemagno on 13 Jun 2018

👍2

this will be great feature

jrahma on 28 Jul 2018

Need this feature before being able to move to Essentials for one of my apps.

Android would require a custom Background Task.

aherrick on 6 Aug 2018

For me I'm interested in non-background location updates, that's essential for basic map operations.

Dresel on 9 Aug 2018

👍2

gonz01d on 10 Oct 2018

davidlucid on 5 Nov 2018

All right folks. I did some preliminary investigation and thought I would share my thoughts to start a discussion.

Basically, there are rules about what is allowed to happen in certain cases - the more background we go, the stricter the rules get.

Running App & View

The first level is just a basic event while the app is running and the view is in the foreground. No need for anything special. This pretty much what we have today, but we stop the events after we receive the first location that matches our requirements - the accuracy.

To do this, I believe we can pretty much use what we have and add an option to not cancel the listeners after the first event.

The issue with this one is that if the view or the app goes to the background and the OS may kill the app and location events will stop.

Suspended/Background App

This is the next level is when the app is in the background because the user launched another app or went home or locked the device.

On iOS, I believe we can add location to the background modes. But we may need to see what happens if we receive and event and the handler uses some elements (maybe UI) that are now part of the suspended app. I think this will add a blue status bar indicating background location. https://developer.apple.com/documentation/corelocation/cllocationmanager/1423750-startupdatinglocation?language=objc

On Android, I think we may have to use a "foreground service" that adds a persistent notification.https://developer.android.com/about/versions/oreo/background-location-limits

On UWP, it appears that if the user switches away from the app, the locations will stop. In order to counter this, a background task will have to be created and used. https://docs.microsoft.com/en-us/windows/uwp/maps-and-location/guidelines-and-checklist-for-detecting-location

One thing to note is that even though the app is in the background, battery usage will still be high as the device is awake and the GPS is running at full strength.

Killed App

Once the app is killed, then other things take over. The code is not running and we have to rely on registering the event with the OS.

On iOS, we may have to use startMonitoringSignificantLocationChanges which will only get events every 500m or so, and only every 5 minutes. https://developer.apple.com/documentation/corelocation/cllocationmanager/1423531-startmonitoringsignificantlocati

On Android, location updates are only provided a few times each hour, according to the docs. https://developer.android.com/about/versions/oreo/background-location-limits

On UWP, the same code works whether the app is suspended or killed, so no extra changes here.

mattleibow on 15 Nov 2018

Well, it should also run or re-run once app is killed.. imagine a calendar app was killed and you were waiting for event notification but you won’t get because the app was killed

jrahma on 18 Nov 2018

This is more about how we handle doing things in the background.

We have some discussion in #409 about general background task stuff. It really boils down to the fact that we can't just simply allow an event to be registered since on platforms like Android your app may be closed, and instead a background service must be used which would have no knowledge of your foreground UI. I think what we will ultimately settle on is the developer/user registering some type which subclasses a background worker abstract type of some sort which will be instantiated when a background event happens. This of course means you will have no access to any UI side scopes, but that's really how background services work on Android (and UWP).

In practice this might look something like this:

public class MyBackgroundGeolocationTask : BackgroundTask<Location>
{
    public Task RunAsync (Location state)
    {
        // Do something with your location
        // Maybe you send info to a webservice, or fire a local notification
    }
}

And you might register it with our API like:

var request = new GeolocationRequest(GeolocationAccuracy.Medium);
Geolocation.RegisterBackgroundHandler(request, typeof(MyBackgroundGeolocationTask));

In any case, we have to finalize #409 and how we implement this pattern in general before we can move on to specific implementations.

Redth on 26 Nov 2018

👍2

I think we should focus first one: Running App & View and go from there.

jamesmontemagno on 29 Nov 2018

James M. looks to have implemented this in his GeoLocatorPlugIn with registering the event CrossGeolocator.Current.PositionChanged. This works on iOS and Android. I would like to switch to Essentials but need this event implemented.

mjorrens on 7 Dec 2018

👍9

Right, the pattern we are going to look at is something like this:

Event for receiving updates when the app is in foreground
Background Task API for receiving updates when the app is in the background

Redth on 10 Dec 2018

👍3

Perfect.

mjorrens on 10 Dec 2018

+1 on this request
I've worked for about a year and a half with the Geolocator library and have incorporated appropriate background functionality for it in my app on iOS and Android (ForeGround service). Let me know if there's any way I can help.

jixer on 4 Apr 2019

👍2