Application & View lifecycle

After application:didFinishLaunchingWithOptions:, then what?

Application enters a “run loop” repeatedly doing the following ...

An autorelease pool is created (more on this in a moment)

Application waits for events (touch, timed event, I/O, etc.)

Events are dispatched through UIKit objects and often on to your objects (via delegates, etc.)

When all is done, the screen is updated (appropriate drawRect: methods are called)

The autorelease pool is drained

Rinse, repeat.

=====================================================================

************************************************************************************************

=====================================================================

The lifecycle starts with alloc and initialization of course

- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)aBundle;

This is UIViewController’s designated initializer.
The UIViewController tries to get its view from the specified .xib file called nibName.
If nibName is nil, it uses the name of the class as the nibName (HappinessViewController.xib).
The bundle allows you to specify one of a number of different .xib files (localization).
We’ll cover NSBundle later in the course when we talk about localization.
Passing nil for aBundle basically means “look in the Resources folder from Xcode.”
Initializing UIViewController with init is very common, it means nibName is nil & aBundle is nil.

After the UIViewController is initialized, viewDidLoad is called
- (void)viewDidLoad;

We learned about his in the last lecture.
This is an exceptionally good place to put a lot of setup code.
But be careful because the geometry of your view (its bounds) is not set yet.
If you need to initialize something based on the geometry of the view, use the next method ...

Just before the view appears on screen, you get notified

- (void)viewWillAppear:(BOOL)animated;

When this is called, your bounds has been set (via your frame by your superview or some such).
Your view will probably only get “loaded” once, but it might appear and disappear a lot.
So don’t put something in this method that really wants to be in viewDidLoad.
Otherwise, you might be doing something over and over unnecessarily.
Use this to optimize performance by waiting until this method (i.e. just before view appears)
to kick off an expensive operation (might have to put up a spinning “loading” icon though).

And you get notified when you will disappear off screen too

- (void)viewWillDisappear:(BOOL)animated

- (void)viewWillDisappear:(BOOL)animated
{
[super viewWillDisappear:animated]; // call this in all the viewWill/Did methods
// let’s be nice to the user and remember the scroll position they were at ...
[self rememberScrollPosition]; // we’ll have to implement this
// do some other clean up now that we’ve been removed from the screen
[self saveDataToPermanentStore];
// but be careful not to do anything time-consuming here, or app will be sluggish
// maybe even kick off a thread to do what needs doing here
}
There are “did” versions of both of these methods too
- (void)viewDidAppear:(BOOL)animated;
- (void)viewDidDisappear:(BOOL)animated;

You already know about viewDidUnload

- (void)viewDidUnload;

Called in low-memory situations.
Be sure to release your outlets (or other data tied to the view and its subviews) here.