IOS4 note 12 (Chapter 11)

Cocoa Events

None of your code runs until Cocoa calls it. The art of Cocoa programming consists largely of knowing when and why Cocoa will call your code. If you know this, you can put your code in the correct place, with the correct method name, so that your code runs at the correct moment, and your app behaves the way you intend.

 

Reasons for Events

User events

The user does something interactive, and an event is triggered directly. Obvious examples are events that you get when the user taps or swipes the screen, or types a key on the keyboard.

Lifetime events

These are events notifying you of the arrival of a stage in the life of the app, such as the fact that the app is starting up or is about to go into the background, or of a component of the app, such as the fact that a UIViewController’s view has just loaded or is about to be removed from the screen.

Functional events

Cocoa  is about  to do  something, and  turns  to you  in  case you want  to  supply (additional) functionality. I would put into this category things like UIView’s drawRect: (your chance to have a view draw itself) and UILabel’s drawTextInRect: (your chance to modify the look of a label).

Query events

Cocoa turns to you to ask a question; its behavior will depend upon your answer.For example, the way data appears  in a table (a UITableView)  is that whenever Cocoa needs a cell for a row of the table, it turns to you and asks for the cell.

 

Subclassing

A built-in Cocoa class may define methods that Cocoa itself will call and that you are invited (or required) to override in a subclass. Sometimes you know when the method will be called; at other times you don’t know or care exactly when the method is called, but you know that you must override it so that whenever it is called, your behavior, and not (merely) the default behavior, will take place.

For example, the UIView’s drawRect:. The built-in UIView implementation does nothing, so overriding drawRect: in a subclass is your only chance to dictate the full procedure by which a view draws itself. You don’t know exactly when this method will be called, and you don’t care; when it is, you draw, and this guarantees that  the view will always appear  the way you want  it  to.  (You never call drawRect: yourself; if some underlying condition has changed and you want the view to be redrawn, you call setNeedsDisplay and let Cocoa call drawRect: in response.)

For example, you must override loadView if your UIViewController creates its view in code, and you must create and assign it to this instance’s view property at this moment.(I’d probably call that a functional event, because your code has a specific job to do, namely, supply the view.) You may override viewDidLoad to perform additional initializations as your view is first loaded, whether it comes from a nib or you created it in loadView. Methods like view WillAppear: and viewDidDisappear: are called as your UIViewController’s view takes over the screen or is replaced on the screen by some other view; thus, viewWillAppear: is a moment to make sure that whatever happened while your view was offscreen is reflected in how it looks as it comes back onscreen. (Those are obviously lifetime events.)

A method like shouldAutorotateToInterfaceOrientation: is what I call a query event. It is passed an orientation parameter and returns a BOOL telling Cocoa whether your view can appear in that orientation. The default, if you don’t implement it, is that your view can appear only in portrait orientation. If you want this UIViewController’s view to appear in some other orientation, you’ll return YES for that orientation. If you return YES  for more  than one orientation and  the user  rotates  the device, you might  then receive messages like willRotateToInterfaceOrientation:duration: and willAnimateRotationToInterfaceOrientation:duration:, where you can customize what happens to the view as the orientation changes.

Even  further  up  the  inheritance  hierarchy,  you’ll  find  things  like  NSObject’s initialize class method. Every class that is actually sent a class method message (including instantiation) is first sent the initialize message, once. Thus, initialize can be overridden in order to run code extremely early in a class’s lifetime (before it even has an instance). Your project’s application delegate class is instantiated very early in the app’s lifetime, as the main nib loads, so its initialize can be a good place to perform very early app initializations, such as setting default values for any user preferences. For typical code, look at Apple’s Metronome example, in MetronomeAppDelegate.m. Observe that we test, as a matter of course, whether self really is the class in question; otherwise there is a chance that initialize will be called again (and our code will run again) if a subclass of this class is used.