The use of UIApplicationDidFinishLaunchingNotification

Posted immediately after the application finishes launching.

That's what the Apple docs state. But I don't see how an object could receive this notification. It would have to add itself as an observer, bu开发者_运维知识库t the earliest it could do this is in the application:didFinishLaunchingWithOptions: method. At that moment, the notification has already been posted. I don't see any use for this notification, or am I overlooking something?

If you have classes or categories that initialize themselves in +load, they can also take that opportunity to wait for an UIApplicationDidFinishLaunchingNotification. This way, certain objects can perform various levels of "automagic" behavior without any code needing to be inserted into the application's delegate.

Assume you have some object of class "MyController" in the root of your "Main Nib File" (as specified in your target's properties - the default is called "MainWindow.xib"). When your app launches and this main nib file is loaded, all objects in the nib file receive an -awakeFromNib method, including your MyController instance. In there, the instance could add itself as an observer of the UIApplicationDidFinishLaunchingNotification. When the loading of the Main Nib File is finished (and some other startup stuff), and the UIApplicationDelegate receives the -application:didFinishLaunchingWithOptions: message, your MyController instance receives the notification.

Another (probably not very common) case for registering for this notification would be if you instantiated some Objective-C class directly in the main.m file before UIApplicationMain() is called and wanted to know when your app actually did start.

Why do you need to look for this notifcation?

Surely you can call whatever methods you want from the application:didFinishLaunchingWithOptions: method.

The delegate object that receives this notifaction is instanciated and registered as the app delegate during loading of the application .xib files. If you want to do additional setup after the .xibs have been loaded, you can do that here.

Sometimes it's just handy.

Instead of having your delegate, er, delegate everything, and thus forming a great dependency hairball, you can make the controllers themselves responsible for responding to lifecycle events (like becoming inactive, going into the background, etc).