iPhone App Development: The Missing Manual

Technical Design: Between Pictures and Code

But for now, everyone on the team is happy with the design, so it's time to start building it. Oh boy, you finally get to write some code! But not just yet.

The final step in the iPhone app design process is to translate the visual design into a technical design. You're going to be creating classes with methods as you work toward what you've put on paper. It's a good idea to think about how these pieces are going to fit together in the Model-View-Controller (MVC) pattern that was mentioned in the previous chapter.

If you neglect this important step, you'll find that you end up rewriting a lot of code. You don't need to write a 100-page specification that describes the technical needs in minute detail, but you do need to spend a little time planning where you're headed.

Start Naming

A good first step in this process is to start giving things names. You've probably already come up with some terminology as you've discussed the design with the other members of your team. It's time to start codifying the pieces of your application.

A UIViewController typically manages a screenful of data in an iPhone app. Since you're going to have two screens in your product, that's a natural place to start naming things. The view with the light source is the first one that you see after launch, so you decide to call it the "main screen." It would be fun to call the other view the "dimmer switch screen," but you think better of it and call it the "settings screen."

Now it's time to start thinking about the things you find on each screen and to give them names, too. This is when you start thinking of what you're going to call your models, views, and controllers. As with your visual design, strive for simplicity and consistency.

First light

So what kinds of classes are going to be required for the main screen? You'll need a view controller class to manage the contents of the screen. That controller will, in turn, manage view classes for the information at the top of the window, the light source, and the toolbar. Call these views the "info view," "light view," and "toolbar."

You'll also need a couple of models. One will manage and persist the current settings for the flashlight, so it makes sense to call it the "flashlight model." It also seems like a good idea to put the emergency signal generator into its own "SOS model."

Overall, the classes will fit together as shown in Figure 4-7.

This is also a good time to start thinking about the kinds of instance variables that each class is going to need. The view controller will have instance variables for each of the views and models (so that it can send messages to them). You'll also need actions to respond to the button presses on the toolbar: –toggleFlasher, –toggleDisco, –startSOS, and –showSettings.

You decide to have two types of messages in the info view: one for informational messages, the other for alerts. That type along with the message will be stored as instance data for the view.

The light view will have a state: The illumination state can be on, off, or flashing. You also want to be able to control its brightness and color, so you'll add properties for those to the view. A delegate instance variable will also let you report touch events back to the controller via the –lightView:singleTapAtPoint: and –lightView:doubleTapAtPoint: methods.

Since you're trying to simulate the physical behavior of a light bulb, it also makes sense to define how quickly the light reacts to changes. An envelope will let you change how quickly the light turns on (attack) and turns off (release).

Figure 4-7. The classes used for the main screen of the flashlight. Three views and two models will be attached to the controller. The views represent the information, the light source, and the toolbar. Models for the flashlight and SOS signal will provide data for the views via the controller.

The last view, the toolbar, will have items consisting of buttons that send actions and visual separators. For the flashlight model, you'll want to store and retrieve the brightness, speed, and default color. The disco mode will need a random color, so you'll add an attribute for that as well. The SOS model will need a method to start sending the signal and a way to get the current Morse code element (a dot, dash, or the gap between each).

The dimmer switch

The settings screen will also have a view controller that sits center stage. It's going to use the same flashlight model used by the main screen since you want the current flashlight data to be consistent across both views.

You'll also get to reuse the light view class from the main screen. It has properties like brightness and color that you can use for the preview. Objective-C and Cocoa Touch make it easy to write something once and use it over and over again.

The standard slider controls will be used for the light's brightness and flasher speed. Likewise, you'll be using the standard picker view to select the color. The sliders will invoke the –brightnessChanged and –speedChanged methods on the controller. The controller will act as a delegate for the picker view and implement the –pickerView:didSelectRow:inComponent: method to track changes in the control.

Like with the main view controller, there will be instance variables for each of the views and the model. Figure 4-8 shows the overall architecture of the screen.

Figure 4-8. The classes used on the settings screen. The four controls are for the brightness, speed, color, and a preview of the light. One model is used to store and retrieve the current flashlight settings.