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

Solution 1:

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]
...

Solution 2:

I revisited this lately and created a test project: https://github.com/Janek2004/ViewControllerTest

Run the project on the iOS simulator to see the order of execution of the UIViewController subclass methods. Order might be different whenever we use Nib file instead of the storyboard or load view controller programmatically.

1. -[ViewController initWithCoder:] Unarchive data from nib or storyboard
2. -[ViewController awakeFromNib] Prepares the receiver for service after it has been loaded from an Interface Builder archive, or nib file.
3. -[ViewController loadView] You should never call this method directly. The view controller calls this method when its view property is requested but is currently nil. This method loads or creates a view and assigns it to the view property.
4. -[ViewController viewDidLoad] This method is called after the view controller has loaded its view hierarchy into memory.
5. -[ViewController viewWillAppear:] This method is called before the receiver’s view is about to be added to a view hierarchy and before any animations are configured for showing the view.
6. -[ViewController viewWillLayoutSubviews] Called to notify the view controller that its view is about to layout its subviews.When a view’s bounds change, the view adjusts the position of its subviews. Your view controller can override this method to make changes before the view lays out its subviews.
7. -[ViewController viewDidLayoutSubviews] Called to notify the view controller that its view has just laid out its subviews. When the bounds change for a view controller’s view, the view adjusts the positions of its subviews and then the system calls this method. However, this method being called does not indicate that the individual layouts of the view’s subviews have been adjusted. Each subview is responsible for adjusting its own layout.

8. -[ViewController viewDidAppear:] Notifies the view controller that its view was added to a view hierarchy. You can override this method to perform additional tasks associated with presenting the view.

9. -[ViewController viewWillDisappear:] Notifies the view controller that its view is about to be removed from a view hierarchy.This method is called in response to a view being removed from a view hierarchy. This method is called before the view is actually removed and before any animations are configured. Notifies the view controller that its view was added to a view hierarchy. You can override this method to perform additional tasks associated with presenting the view.

10. -[ViewController viewDidDisappear:] Notifies the view controller that its view was removed from a view hierarchy.