Behaviour for significant change location API when terminated/suspended?

user_73488 0
Viewed 33341

This is the section from the CLLocationManager documentation describing the app behavior with startMonitoringSignificantLocationChanges:

If you start this service and your application is subsequently terminated, the system automatically relaunches the application into the background if a new event arrives. In such a case, the options dictionary passed to the application:didFinishLaunchingWithOptions: method of your application delegate contains the key UIApplicationLaunchOptionsLocationKey to indicate that your application was launched because of a location event. Upon relaunch, you must still configure a location manager object and call this method to continue receiving location events. When you restart location services, the current event is delivered to your delegate immediately. In addition, the location property of your location manager object is populated with the most recent location object even before you start location services.

So my understanding is that if your app terminates (and I assume if you don't call stopMonitoringSignificantLocationChanges from applicationWillTerminate) you will get woken up with a UIApplicationLaunchOptionsLocationKey parameter to application:didFinishLaunchingWithOptions. At that point you create your CLLocationManager, call startMonitoringSignificantLocationChanges and do your background location processing for a limited time. So I am fine with this bit.

The previous paragraph only talks about what happens when the app is terminated, it doesn't suggest what you do when the application is suspended. The documentation for didFinishLaunchingWithOptions says:

The application tracks location updates in the background, was purged, and has now been relaunched. In this case, the dictionary contains a key indicating that the application was relaunched because of a new location event.

Suggesting that you will only receive this call when your app is launched (because of a location change) after you have been terminated.

However the paragraph on the Significant Change Service in the Location Awareness Programming Guide has the following to say:

If you leave this service running and your application is subsequently suspended or terminated, the service automatically wakes up your application when new location data arrives. At wake-up time, your application is put into the background and given a small amount of time to process the location data. Because your application is in the background, it should do minimal work and avoid any tasks (such as querying the network) that might prevent it from returning before the allocated time expires. If it does not, your application may be terminated.

This suggests you are woken up with location data if your app has been suspended, but fails to mention how you are woken up:

In the process of writing this up, I think I may have just answered my own question, but it would be great to have my understanding of this confirmed by someone more knowledgeable.

ios-app-suspended-state uiapplicationdelegate cllocationmanager core-location ios
4 Answers

So I just have an important note specific to when app was terminated:

For some APIs that can launch the app in the background and later need to be receiving a callback that handles that launching, would likely need a delegate object to be set.

So if you get an app launch (i.e. from terminated state, not suspended state) because of location tracking then, your locationManager delegate callbacks won't be called unless you set the delegate in the didFinishLaunching. To be more precise, you won't get any delegate callbacks until you set your delegate.

  1. So if you're doing follow in your ABC viewcontroller after your app launch
let manager = CLLocationManager()
manager.delegate = self
  1. Then app got terminated
  2. Then app was location due to a location change in the background
  3. YOU WON'T GET a callback until you foreground the app and open your ABC viewcontroller

It's incorrect to think that the app magically knows what the delegate object is. It doesn't persist that information.

Solution:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    
   let myLocationManager = CLLocationManager()
   myLocationManager.delegate = self
}

I figured this out for a totally unrelated API:

optional func userNotificationCenter(_ center: UNUserNotificationCenter, 
                      didReceive response: UNNotificationResponse, 
              withCompletionHandler completionHandler: @escaping () -> Void)

That is, if you don't set your delegate before AppLaunch, then you miss user interaction with the notifications that happen immediately after an app termination. To be more precise you miss any callbacks until you set the userNotification's delegate.

user_51757090
Related