When you create a new project using a template — quite the normal state of affairs, as shown in Chapter 4 of Book I — the basic application environment is included. That means when you launch your app, an application object is created and connected to the window object, the run loop is established, and so on — despite the fact that you haven't done a lick of coding.

Most of this work is done by the UIApplicationMain function, as illustrated back in Figure 1-3. Here's a blow-by-blow description of what the UIApplicationMain function actually does, and Figure 1-4 illustrates the process.

Figure 1-4. The application is launched.

The file MainWindow.xib is what causes your application's delegate, main window, flipside window, and view controller instances to get created at runtime. Remember, this file is provided as part of the project template. You don't need to change or do anything here. This is just a chance to see what's going on behind the scenes.

To take advantage of this once-in-a-lifetime opportunity, go back to your project window in Xcode, expand the Resources folder in the Groups & Files list on the left, and then double-click MainWindow.xib. (You do have a project already started, right? If not, check out Chapter 4 of Book I.) When Interface Builder opens, take a look at the nib file's main window — the one labeled MainWindow.xib, which should look like the MainWindow.xib you see at the bottom of Figure 1-4.

The MainWindow.xib window shows four icons, as follows:

UIApplication loads the parts of the MainWindow.xib as follows:

Listings 1-1 and 1-2 show the header and implementation of DeepThoughtsAppDelegate. All this is done for you as part of the Xcode template.

@class MainViewController;

@interface DeepThoughtsAppDelegate : NSObject
   <UIApplicationDelegate> {
    UIWindow *window;
    MainViewController *mainViewController;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) MainViewController
    *mainViewController;

@end

#import "DeepThoughtsAppDelegate.h"
#import "MainViewController.h"

@implementation DeepThoughtsAppDelegate


@synthesize window;
@synthesize mainViewController;


- (void)applicationDidFinishLaunching:(UIApplication *)
   application {

   MainViewController *aController = [[MainViewController
   alloc] initWithNibName:@"MainView" bundle:nil];
   self.mainViewController = aController;
   [aController release];

    mainViewController.view.frame = [UIScreen mainScreen].
    applicationFrame;
    [window addSubview:[mainViewController view]];
     [window makeKeyAndVisible];
}


- (void)dealloc {
    [mainViewController release];
    [window release];
    [super dealloc];
}

@end

In Listing 1-2, the MainView view controller is initialized with the initWithNibName:bundle: method. You could use the applicationDidFinishLaunching method to do any other application initialization as well — such as returning everything to what it was like when the user last used the application.

If you look inside the MainViewController.m implementation file, as shown in Listing 1-3, you can see that showInfo initializes the Flipside view with the initWithNibName:bundle: method when the user touches the i information button.

- (IBAction)showInfo {

   FlipsideViewController *controller
   = [[FlipsideViewController alloc]
   initWithNibName:@"FlipsideView" bundle:nil];
   controller.delegate = self;

   controller.modalTransitionStyle =
   UIModalTransitionStyleFlipHorizontal;
   [self presentModalViewController:controller animated:YES];

   [controller release];
}

The application delegate object (refer to Listing 1-1) is usually derived from NSObject, the root class (the very base class from which all iPhone application objects are derived), although it can be an instance of any class you like, as long as it adopts the UIApplicationDelegate protocol. The methods of this protocol correspond to behaviors that are needed during the application lifecycle and are your way of implementing this custom behavior. Although you aren't required to implement all the methods of the UIApplicationDelegate protocol, every application should implement the following critical application tasks:

On an iPhone, various events besides termination can interrupt your app to allow the user to respond — for example, incoming phone calls, SMS messages, calendar alerts, or the user pressing the Sleep 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 answer the phone or reply to an SMS message, however, your app will be terminated.

Figure 1-7 shows the sequence of events that occurs during the arrival of a phone call, SMS message, or calendar alert. Here's what that looks like step by step:

The way the Sleep/Wake button is handled is a little different. When the app enters or resumes from a sleep state, two messages are sent to the application delegate: applicationWillResignActive: and applicationDidBecomeActive:, respectively. In this case, your app always resumes, though the user might immediately launch a different app.

Figure 1-7. Handling an interruption.

One of the main responsibilities of all good little applications is to deal with low memory. So the first line of defense is (obviously) to understand how you as a programmer can help them avoid getting into that state.

In the iPhone OS, each program uses the virtual-memory mechanism found in all modern operating systems. But virtual memory is limited to the amount of physical memory available. This is because the iPhone OS doesn't store "changeable" memory (such as object data) on the disk to free up space, and then read it in later when it's needed. Instead, the iPhone OS tries to give the running application the memory it needs — freeing memory pages that contain read-only contents (such as code), where all it has to do is load the "originals" back into memory when they're needed. Of course, this may be only a temporary fix if those resources are needed again a short time later.

If memory continues to be limited, the system may also send notifications to the running application, asking it to free up additional memory. This is one of the critical events that all applications must respond to.