Geolocation - Location Updates

[Ryan-Palmer]

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

[jamesmontemagno]

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.

[jrahma]

this will be great feature

[aherrick]

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

Android would require a custom Background Task.

[Dresel]

+1

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

[gonz01d]

+1

[davidlucid]

+1

[mattleibow]

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.

[jrahma]

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

[Redth]

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.

[jamesmontemagno]

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

[mjorrens]

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.

[Redth]

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

[mjorrens]

Perfect.

[jixer]

+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]

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.

[magtimmermans]

+1

[akammerer]

+1

[timahrentlov]

+1

Needed to move from https://github.com/jamesmontemagno/GeolocatorPlugin to Essentials.

[amr-moomen]

+1
Needed to move from https://github.com/jamesmontemagno/GeolocatorPlugin to Essentials.

[AbdellahMobiArchitects]

+1
Needed to move from https://github.com/jamesmontemagno/GeolocatorPlugin to Essentials.

[chinkan]

+1
Needed to move from https://github.com/jamesmontemagno/GeolocatorPlugin to Essentials.

[starlisa]

Is there any intention of adding a location change event to Xamarin.Essentials.Geolocation, or should we assume that it's not going to happen and find other ways to achieve it? I've seen multiple requests, but every time, they simply get closed. An actual reply would be wonderful, thanks.

[jfversluis]

@starlisa we won't be doing this anymore for Xamarin.Essentials. If this is still something that is important to you, please see if there is an issue tracking this for .NET MAUI.