Use of init: vs application:didFinishLaunchingWithOptions:


#1

I know most of the examples for views have been using a single init method with initFromFrame calling that method and I did understand that.

I’m curious of the reason for using init in the UIApplicationDelegate classes with regards to using application:didFinishLaunchingWithOptions. Both of these are only called once, correct? Could all logic in the init go in the application:didFinishLaunchingWithOptions method?

I understand the rationale that an instance of AppLauncher could be sent the init message; however, is it likely to happen?

Thanks,
Cris


#2

It is mostly a separation of logic, but, there is one big difference in the order in which these methods are called.

init is sent to an object when it is being created. In the case of the application delegate, this is sent at the beginning of the NIB unarchiving process. All of the archived objects in the NIB are instantiated and sent init (or initWithCoder:, in the case of objects that conform to NSCoding and are fully supported IB objects).

However, during init, all of the IBOutlets for the AppDelegate will be nil. The NIB unarchiving process will not have connected outlets at the time it is instantiating the archived objects. (This makes sense, if you send init to an object as it is being created, you could not have set its outlets beforehand; the object didn’t exist!)

application:didFinishLaunchingWithOptions: is sent after the NIB file has been fully loaded; right before the application enters the run loop. All connected outlets will be valid at this point.

Why did we do it this way? Aaron likes separating the instantiation of model objects and the final application setup. (You can tell which chapters he wrote the source code for by this design decision. While he and I have incredibly similar styles, there are a few places we differ, and we thought it would be best to present both options to the readers.)