iPhone App Development: The Missing Manual

Fashion Your Models

Now that you've ventured through the views of Flashlight Pro, it's time to look at the models that provide data to the application.

You might be thinking, "Data? For a flashlight?"

Yes! Data comes in many forms: The models for the flashlight let you keep track of the light's settings and build a state machine that controls the SOS flasher. It's not data in the traditional sense, but it's still information that you separate from your controllers.

SOSModel

When you're sending an SOS signal, you're dealing with a stream of dots and dashes that change over time. In essence, you're working with a state machine. Since one of a model's functions is to manage internal logic and behavior, it makes the distress signal a good candidate for this kind of object.

The model's interface is simple: A unitInterval property lets you define how long a dot or a dash takes (dashes are defined as being three times as long as a dot). There is also a method that lets you query the current element.

You start the state machine running by invoking the –send method.

Notifications

After you start the state machine running, how do you find out when to change from a dot to a dash? You could poll the element parameter, but you know that polling for value updates is terrible to do in an event-driven environment. And Cocoa Touch is very much an environment driven by events.

The solution is to rely on notifications. As you saw on Notifications, notifications let you distribute information to objects in ...