IOS4 note 12 (六)
Application Lifetime Events
As I’ve already mentioned, events mark certain important stages in the overall lifetime of your application. These events can arrive either as messages to the app delegate (if you implement the appropriate methods) or as notifications to any object (if that object registers for those notifications).
Starting with iOS 4, however, apps operate in a multitasking environment. The Home button doesn’t terminate your app; it suspends it. This means that your app is essentially freeze-dried in the background; its process still exists, but it isn’t getting any events (though notifications can be stored by the system for later delivery if your app comes to the front once again). You’ll probably never get applicationWillTerminate:, because when your app is terminated by the system, it will already have been suspended.
Thus, you have to worry about what will happen when the app is suspended and when it returns from being suspended (applicationDidEnterBackground: and applicationWillEnterForeground:, and their corresponding notifications), and the notion of the application becoming inactive or active also takes on increased importance(applicationWillResignActive: and applicationDidBecomeActive:, and their notifications). Here are some typical scenarios:
The app launches freshly
Your app delegate receives these messages (just as in the premultitasking world):
• application:didFinishLaunchingWithOptions:
• applicationDidBecomeActive:
The user clicks the Home button
If your app is frontmost, it is suspended, and your app delegate receives these messages:
• applicationWillResignActive:
• applicationDidEnterBackground:
The user summons your suspended app to the front
Your app delegate receives these messages:
• applicationWillEnterForeground:
• applicationDidBecomeActive:
The user double-clicks the Home button
The user can now work in the app switcher. If your app is frontmost, your app delegate receives this message:
• applicationWillResignActive:
The user, in the app switcher, taps on your app’s window
Your app delegate receives this message:
• applicationDidBecomeActive:
The user, in the app switcher, chooses another app
If your app is frontmost, your app delegate receives this message:
• applicationDidEnterBackground:
The screen is locked
If your app is frontmost, your app delegate receives this message:
• applicationWillResignActive:
The screen is unlocked
If your app is frontmost, your app delegate receives this message:
• applicationDidBecomeActive:
The user holds the screen-lock button down
The device offers to shut itself down. If your app is frontmost, your app delegate receives this message:
• applicationWillResignActive:
The user, as the device offers to shut itself down, cancels
If your app is frontmost, your app delegate receives this message:
• applicationDidBecomeActive:
The user, as the device offers to shut itself down, accepts
If your app is frontmost, your app delegate receives these messages:
• applicationDidEnterBackground:
• applicationWillTerminate: (probably the only way a normal app will receive this message in a multitasking world)
Using the existing repertoire of events to work out what’s happening isn’t always easy. For example, let’s say there are things my app wants to do when the user resumes it from a suspended state (applicationWillEnterForeground:), and there are things my app wants to do when the user unlocks the screen (applicationDidBecomeActive:).
Some of these things are the same in both circumstances, but others are not. But the former event is always followed by the latter. So I have to be careful how I respond:
applicationWillEnterForeground:
Do things appropriate to resuming from suspension. But do not do things that are also appropriate to the user unlocking the screen, because applicationDidBecome-
Active: is about to be called, so if I do those things here, I’ll end up doing them twice.
applicationDidBecomeActive:
Do things appropriate both when resuming from suspension and when the user unlocks the screen.
In this section, I’ve talked as if your app’s being backgrounded is identical to its being suspended. However, under highly specialized circumstances, your app can be backgrounded without being suspended. Also, I’ve talked as if your app has no choice but to participate in the multitasking world, but in fact you can opt out by setting the “Application does not run in background” key (UIApplicationExitsOnSuspend) in your Info.plist, thus
causing your app to behave in this regard as if it were linked against iOS3 — when the user clicks the Home button, your app is terminated. For some apps, such as certain games, this might be a reasonable thing to do.