Your application moves to the background
When the user accepts the notification or interruption, or presses the Home button - or the system launches another application - your application then moves into the background state, where it is suspended to conserve power. (If an app needs to continue running, it can request execution time from the system.)
When your app enters the background state, it will be sent the applicationDidEnterBackground: message. In this method, you should save any unsaved data or state (where the user is in the app - the current view, options selected, and stuff like that) to a temporary cache file or to the preferences database "on disk." (Apple calls the iPad storage system a disk even though it is a solid-state drive.) Although don't do this in DeepThoughts, your app's delegate can implement the delegate method applicationWillTerminate: to save the current state and unsaved data.
The next time the user launches your app, your code can use that information to restore your app to its previous state. You need to do everything necessary to restore your application in case it's subsequently purged from memory. You also have to do additional cleanup operations, such as deleting temporary files. Even though your application enters the background state, there's no guarantee that it will remain there indefinitely. If memory becomes constrained, iOS will purge background apps to make more room for the foreground app.
If your application is suspended when your application is purged, it receives no notice that it is removed from memory. You need to save any data beforehand! The state information you save should be as minimal as possible but still let you accurately restore your app to an appropriate point. You don't have to display the exact same screen used previously - for example, if a user edits a contact and then leaves the Contacts app, upon returning, the Contacts app displays the top-level list of contacts, rather than the editing screen for the contact.
If your application requests more execution time or it has declared that it does background execution, it's allowed to continue running after the applicationDidEnterBackground: method returns. If not, your (now) background application is moved to the suspended state shortly after returning from the applicationDidEnterBackground: method.
When your delegate is sent the applicationDidEnterBackground: method, your app has approximately five seconds to finish things up. If the method doesn't return before time runs out (or if your app doesn't request more execution time from iOS), your app is terminated and purged from memory.
Your application resumes processing
At some point, it's likely that the user will once again want to use your app, which has been patiently sitting in the background waiting for this opportunity to respond to the user's tap. When the user returns to your app by tapping it on a Home screen or in the switching pane below the dock, your application delegate is sent the applicationWillEnterForeground: and applicationDidBecomeActive: messages.
Already explained in the previous section what you'll need to do in the applicationDidBecomeActive: method - restart anything it stopped doing and get ready to handle events again.
While an application is suspended, the world still moves on, and iOS tracks all of the things the user is doing that may impact your application. For example, the user may change the device orientation from landscape to portrait, and then to landscape, and then finally back to portrait. While iOS will keep track of all these events, it will send you only a single event that reflects the final change you'll need to process - in this case, the change to portrait.
