As we discussed in Chapter 18, applications have limited life spans. If iOS ever needs more memory and your application is in the background, Apple might kill it to return memory to the system. This should be transparent to your users; they should always return to the last spot they were within the application.

To achieve this transparency, you must adopt state restoration within your application. State restoration works a lot like another technology you have used to persist data – archiving. When the application is suspended, a snapshot of the view controller hierarchy is saved. If the application was killed before the user opens it again, its state will be restored upon launch. (If the application has not been killed, then everything is still in memory and you have no need to restore any state.)

In this chapter, you will add state restoration to the Homepwner application.

Let’s start by demonstrating the need for state restoration. Open the Homepwner project. Create a new item and drill down to its detail screen (the BNRDetailViewController). Now you need to simulate the process that triggers state restoration. In the iOS Simulator, press the Home button (or use the keyboard shortcut Command-Shift-H). This will put the application into the background. Now, to kill the application as if the system killed it, go back to Xcode and click the stop button (Command-.). Then relaunch the application from Xcode.

When the application launches, you will briefly see the BNRDetailViewController, but that will quickly be replaced with the BNRItemsViewController. Why is this? When applications go into the background, iOS takes a snapshot image of the user interface. Then when the application is relaunched, this snapshot is used as the launch image until the application is loaded into memory.

If an application does not implement state restoration, the user will briefly see the previous application state, but then the screen will change to its fresh-launch state. With Homepwner, you see a flicker of the detail view controller and then the items view controller. This is a disorienting experience.

How State Restoration Works

A running app can be thought of as a tree of view controllers and views, with the root view controller as the root of the tree. For example, the interface of your HypnoNerd app can be thought of as a tree like this:

Figure 24.1  An app is a tree

If you opt-in to state restoration, before your app is terminated, the system walks this tree asking each node, “What is your name?”, “What is your class?”, and “Do you have any data you want me to hold on to?” While the app is dead, this description of the tree is stored on the file system.

A node’s name, actually called the restoration identifier, is typically the object’s class name. The restoration class is typically the class of the object. The data holds the state of the object. For example, the data for a tab view controller includes which tab is currently selected.

When the app is restarted, the system tries to recreate the tree of view controllers and views from that saved description. For each node:

• The system asks the restoration class to create a new view controller for that node.

• The new node is given an array of restoration identifiers: The identifier for the node being created and the identifiers for all of its ancestors. The first identifier in the array is the identifier for the root node. The last is the identifier for the node being recreated.

• The new node is given its state data. This data comes in the form of an NSCoder, which you used in Chapter 18.

In this chapter, you are going to extend the view controllers in Homepwner to properly give their node information when the app is terminating and to use that node information when they are resurrected.