终止/暂停重大变更位置 API 的行为？

My understanding is as follows (I'm in the process of writing an application that relies on this API, but haven't completed this component enough to start testing):

1. Your application is run for the first time, you register to startMonitoringSignificantLocationChanges, and provide a callback function. While your application is running, it will call that callback whenever it receives a significant change.
2. If your application is put to the background, UIApplication will receive applicationWillResignActive, followed by applicationDidEnterBackground.
3. If your application is killed while it is suspended, you will not be notified; however, if your application is killed while it is running (foreground or background to my knowledge), you will get a moment with applicationWillTerminate. You cannot request extra background time from this function.
4. Despite being killed in the background, the OS will relaunch your application. If your application is simply launched by the OS for a change, you will get a call to application didFinishLaunchingWithOptions:

if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])

will help you determine if you've come back from a background location change.

5. If, instead, you were currently running in the background, and your app is manually relaunched by the user, you will receive an applicationWillEnterForeground followed by applicationDidBecomeActive.

6. Regardless of how it happened, when your application is relaunched (unless it was still running in the background as a result of a background task and said task had started monitoring changes), you need to explicitly tell it to startMonitoringSignificantLocationChanges again because the callback is no longer attached after "freeze drying." And yes, you just need to implement code in didUpdateToLocation once you've re-attached a location handler of some kind once coming back from the suspended state.

This is what I'm going on with my code development right now. As I mentioned before, I'm not quite ready to test this on a device so I can't tell if I've interpreted everything correctly, so commenters, please feel free to correct me (though I've done substantial reading on the topic).

Oh, and if by some stroke of bad luck, you release an app that does what I want mine to do, I might cry :)

Good luck!

Since I asked this question, I have done a fair bit of testing (mostly on the train between home and work) and have confirmed that the behaviour for suspended apps is as I suspected at the end of the question.

That is, your suspended app is woken up, you don't receive any callbacks on your app delegate, instead you receive your location updates through your existing CLLocationManagerDelegate. You can detect that you are running in the background by checking the applicationState, and do limited work for the case where you are woken from a suspended state to do location processing.

[UIApplication sharedApplication].applicationState == UIApplicationStateBackground

I came to this conclusion with a location test harness that you are welcome to download and try out. It is a pretty simple app that allows you to turn on significant change and GPS change APIs through the UI and log all the responses that you get back.

N.B. Point six in the previous answer is not correct. Freeze dried suspended apps do receive CLLocationManagerDelegate callbacks when they are woken up from a suspended state.

If the application is evoked from suspended state as a result of location change application will launch in background state.

All the objects will be live and you will recieve location update in the existing delegate.

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

2. Then app got terminated
3. Then app was location due to a location change in the background
4. 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.