Responding to interruptions
On an iPad, various events besides termination can interrupt your app to allow the user to respond - for example, calendar alerts or the user pressing the Sleep/Wake button. Such interruptions may only be temporary. If the user chooses to ignore an interruption, your app continues running as before. If the user decides to tap the alert to deal with it, your app first moves into the inactive state.
When the user quits an app, its process is not terminated (as was the case with iOS 3.2 and earlier versions) - the app is moved to the background, where it is suspended to conserve power. (If an app needs to continue running, it can request execution time from the system.) Because the app is in the background (running or suspended) and still in memory, relaunching is nearly instantaneous. An app's objects (including its windows and views) remain in memory, so they don't need to be re-created when the app relaunches. If memory becomes constrained, iOS may purge background apps to make more room for the foreground app.
Because these interruptions cause a temporary loss of control by your app - meaning that touch events, are no longer sent to your app - it's up to you to prevent what's known in the trade as a "negative user experience." For example, if your app is a game, you should pause the game. In general, your app should store information about its current state when it moves to the inactive state and be able to restore itself to the current state upon a subsequent relaunch.
In all cases, the sequence of events starts the same way - with the applicationWillResignActive: message sent to your application delegate. Using this method, you should pause ongoing tasks, disable timers, and generally put things on hold.
What happens after this depends on the nature of the interruption and/or how the user responds to the interruption. Your application may be
- Moved to the background
The next two sections take a look at each scenario.
Your application is reactivated
If the user ignores the FaceTime call or calendar notification (or similar interruption), the system sends your application delegate the applicationDid BecomeActive: message and resumes the delivery of touch events to your application.
If the user pressed the Sleep/Wake button, the system then puts the device to sleep. When the user wakes the device later, the system sends your application delegate the applicationDidBecomeActive: message and your application receives events again. While the device is asleep, foreground and background applications do continue to run, but should do as little work as possible in order to preserve battery life.
In both cases, you can use the applicationDidBecomeActive: method to restore the application to the state it was in before the interruption. What you do depends on your application. In some applications, it makes sense to resume normal processing. In others - if you've paused a game, for example - you could leave the game paused until the user decides to resume play.