The next step is for the UIApplication to send the ReturnMeToApp Delegate applicationDidFinishLaunching: message. Step 5 in Figure 6-6 represents what happens when the applicationDidFinish Launching: method is invoked.
This figure looks exactly like Figure 6-4, except I added a Step 5: putting the view into the window and then making the window visible. At this point, you’d do any other application initialization as well — and return everything to what it was like when the user last used the application.
Fi П П UqkilMndaw. ii lb
Ш s | ш i л О
VrfwUfidf Ms 11bury infp-rrtar ® •
TIE tlripHid
Figure 6-6 is more than just a conceptual diagram, as you can see from Listing 6-1, which shows two instance variables, window, and viewController. These are automatically "filled in" for you when your application is launched. Then, in the applicationDidFinishLaunching: method, the view controller and its view are added to the window, and the window becomes visible. Note that this was generated automatically by Xcode. (I’ll get into what all those strange things like IBOutlet and @property mean in the next chapter.)
The applic ation Did Finish Launch ing: method installs the view in the window and makes the window visible.
Listing 6-1: ReturnMeToAppDelegate
// ReturnMeToAppDelegate. h
#import <UIKit/UIKit. h>
@class ReturnMeToViewController;
@interface ReturnMeToAppDelegate : NSObject
<UIApplicationDelegate> {
UIWindow *window;
ReturnMeToViewController *viewController;
}
@property (nonatomic, retain) IBOutlet UIWindow *window; @property (nonatomic, retain) IBOutlet
@end
// ReturnMeToAppDelegate. m
#import "ReturnMeToAppDelegate. h" #import "ReturnMeToViewController. h"
@implementation ReturnMeToAppDelegate @synthesize window; @synthesize viewController;
- (void)applicationDidFinishLaunching:
(UIApplication *)application {
[window addSubview:viewController. view]; [window makeKeyAndVisible];
}
JjJJlBEH
What this does is quite a bit; what it doesn’t do is connect objects added to the user interface with the objects that need to know about them. How does my application access the phone number that the user enters, for example? Of course, I could root around in the code, but it would be much easier to have Interface Builder do it at application launch. I show you how that is (easily) done in the next chapter.
Your goal during startup should be to present your application’s user interface as quickly as possible — quick initialization = happy users. Don’t load large data structures that your application won’t use right away. If your application requires time to load data from the network (or perform other tasks that take noticeable time), get your interface up and running first — and then launch the slow task on a background thread. Then you can display a progress indicator or other feedback to the user to indicate that your application is loading the necessary data or doing something important.
The application delegate object 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 life cycle and are your way of implementing this custom behavior. Although you are not required to implement all of the methods of the
UIApplicationDelegate protocol, every application should implement the following critical application tasks:
✓ Initialization, which I have just covered
✓ Responding to interruptions
✓ Responding to low memory warnings
I show you what has to be done to carry out these tasks in the last two sections.