Programming iOS 4

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.

An example I gave in Chapter 10 was 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.)

In addition to UIView, particular built-in UIView subclasses may have methods you’ll want to customize through subclassing. Typically this will be in order to change the way the view is drawn. In Chapter 10 I gave an example involving UILabel and its drawTextInRect:. Another example is UISlider, which lets you customize the position and size of the slider’s “thumb” by overriding thumbRectForBounds:trackRect:value: (Chapter 25).

UIViewController (Chapter 19) is a good example of a class meant for subclassing. ...