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.