IOS4 note 12 (6)
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.
?