Tracing the iPhone Application Life Cycle

To help you get a sense for where your “work” in developing an iPhone application fits in, it helps to look at the iPhone application life cycle. Figure 1 shows Apple’s simplified diagram of the life cycle.

Figure 1. The life cycle of a typical iPhone application.

Let’s try to put some context around what you’re looking at, starting on the left side of the diagram. As you’ve learned, UIKit is a component of the Cocoa Touch that provides much of the foundation of iPhone applications—user interface management, event management, and overall application execution management. When you create an application, UIKit handles the setup of the application object via the main and UIApplicationMain functions—neither of which you should need to touch.

Once the application is started, an event loop begins. This loop receives the events such as screen touches, and then hands them off to your own methods. The loop continues until the application is asked to move to the background (usually through the user pushing the iPhone Home button).

Your code comes into play on the right side of the diagram. Xcode will automatically set up your iOS projects to include an application delegate class. This class can implement the methods application:didFinishLaunchingWithOptions and applicationDidEnterBackground (among others) so that your program can execute its own custom code when the application launches and when it is suspended by clicking the Home button.

Wait a second?! When does my application stop running!? Beginning in iOS 4.0, applications no longer terminate when the user presses the Home button. Instead, the application stops where it’s at, and sits quietly in the background. When the user selects it from the task manager or starts it from the home screen, it returns to the foreground and continues exactly where it left off – automatically. To support this process, the application delegate provides the method applicationDidEnterBackground, which is called when the application enters the background. This method should be used by your code to store any information that the application needs, in case it is terminated while it is the background – either by iOS cleaning up resources, or by the user manually terminating it in the task manager. The previous method, applicationWillTerminate, can still be used if you develop an application that does not support backgrounding at all, but this is not the default.

After an application finishes launching, the delegate object typically creates a view controller object and view and adds them to the iPhone “window.” You’ll learn more about these concepts in the next hour, but for now, think of a view as what is being displayed on the iPhone screen, and the view controller as an object that can be programmed to respond when it receives an event notification (such as touching a button) from the event loop.

The majority of your work will take place within the view controller. You’ll receive events from the Cocoa Touch interface and react to them by writing Objective-C code that manipulates other objects within the view. Of course, things can get a bit more complex than a single view and a single view controller, but the same basic approach can be applied in most cases.

Now that you have a better picture of the iOS service layers and application life cycle, let’s take a look at some of the classes that you’ll be seeing throughout this book.