iPhone App Development: The Missing Manual

Refine the Look

Now that you've seen the NIB files, it's time to take a look at how some of the custom views were created. There's a custom view for the light source and another for information displayed at the top of the screen.

LightView

This view is modeled after a physical light. Objects that emulate the real world are usually easier to design, since the correct behavior is already something you're familiar with. They also tend to make your code easier to read.

You see this tendency a lot in Cocoa Touch. For example, the UISwitch control manages its state by using a property named on. Which of these snippets of code is more readable?

mySwitch.on = YES;

or

mySwitch.state = YES;

The properties of the view let you change the state of the light (on, off, or a single pulse). You can also set the brightness and color of the light. To model the physical property of the light, you can also set an envelope where attack and release variables control the amount of time the light takes to turn on and off.

Delegation

Delegation is not just for system classes. The light uses this design pattern to notify another object that taps have occurred in the view. In this application, that object is MainViewController. When the tour reaches the controller code (Strings in user interfaces), you see how it acts as the delegate.

When you look at LightView.h, you see a forward declaration of the protocol:

@protocol LightViewDelegate;

This declaration is needed because there's a chicken-and-egg problem between the ...