What is the process of a UIViewController birth (which method follows which)?

Geri Borbás picture Geri Borbás · Feb 24, 2011 · Viewed 25.5k times · Source

There are many methods to override, like initWithNibname:, awakeFromNib, loadView, viewDidLoad, viewDidAppear:, layoutSubviews, and I just cannot decide in which order gets these method called.

I just override one of them "by heart".

Any detailed explaination?

Answer

e.James picture e.James · Feb 24, 2011

There is a lot going on behind the scenes with Cocoa view and viewController management.

1. The viewController object

At its most basic, a viewController is a generic controller object. When it is first allocated an initialized, it has no view object associated with it. The view is only instantiated when (and if) it is required. So, without considering the view, the lifecycle of a viewController is the same as any other object:

UIViewController * myVC = [[UIViewController alloc] initWith...];
...
[myVC release];

The designated initializer for viewControllers is -initWithNibname:bundle:. If you specify a nib, the viewController can automagically load its view from that nib and connect any IBOutlets that you have defined (see below for more details).

2. Loading and unloading the view

A viewController will load its view as required. This usually happens when the -view method is called for the first time, and can happen at any time in your program, depending on how you initialize your UI. The view may also be destroyed and reloaded several times during the lifetime of your program, agan depending on how you manage your UI. When the viewController has identified that its view is required but not yet loaded, the -loadView method will be called. The basic message flow goes something like this:

view
  loadView
  viewDidLoad

Note that if you override the -view method, -loadView and viewDidLoad will not be called automatically. If you override -loadView, you must set the viewController's view property. Otherwise, the next call to -view will trigger the loading process again.

The view may also be unloaded at any time during the lifetime of your program simply by setting the view property to nil. The default implementation of -didReceiveMemoryWarning will do this automatically, as long as the view does not have a superview (i.e. if it is not currently part of the active view heirarchy). The message flow goes as follows:

view = nil
   viewDidUnload

2a. Loading the view programmatically

If you choose to override -loadView, you can create a view, subviews, other viewControllers, and any connections between these objects in any way you please. Of course, this means that you are also responsible for memory management with respect to the objects that you create. If your subclass overrides -loadView, it should be initialized using nil for both nibName and bundle.

2b. Loading the view from a nib

If you use a nib file, the default implementation of -loadView will automatically open that nib file, instantiate its objects, add any connections between them, and take care of the memory management for you.

Things get a little more tricky with nib files, since so much happens behind the scenes. The -awakeFromNib method is called for every object that is instantiated when a nib file is loaded, and there is no guarantee that the other objects in the nib file will have been fully loaded when it is called.

3. Displaying views

-viewWillAppear:, -viewDidAppear:, -viewWillDisappear: and -viewDidDisappear: are only called when the view is being displayed or hidden on-screen, especially during animated transistions from one view to another. These methods may be called many times during the lifetime of your program, as views are swapped in and out in your navigation scheme.

4. View layout

The -layoutSubviews method is not part of UIViewController. It is called for UIView objects when their bounds have been changed. If you use a custom UIView subclass in your program, this method can be used to do custom subview layout instead of relying on Cocoa's default autoresizing methods.

5. Putting it all together

Because of the complexity, there are many different ways for this process to occur, but a normal timeline could look something like this:

-[viewController initWithNibname:Bundle:]
-[viewController awakeFromNib]
-[viewController loadView]
-[view awakeFromNib]
-[viewController viewDidLoad]
-[viewController viewWillAppear]
-[viewController viewDidAppear]
...
-[viewController viewWillDisappear]  // user navigated away
-[viewController viewDidDisappear]
...
-[viewController viewWillAppear]     // user navigated back
-[viewController viewDidAppear]
...
-[viewController viewWillDisappear]  // user navigated away
-[viewController viewDidDisappear]
...
-[viewController setView:nil]        // memory warning, perhaps
-[viewController viewDidUnload]
...
-[viewController loadView]           // user navigated back
-[view awakeFromNib]
-[viewController viewDidLoad]
-[viewController viewWillAppear]
-[viewController viewDidAppear]
...