Xcode 4 Unleashed: Starting an iOS Application
- Planning the App
- Starting a New iPhone Project
- One More Thing
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Now that you have the basic skills down, let’s move on to a real project. You’ll build an iPhone application that manages a list of quarterbacks and displays their game and career statistics.
Planning the App
Before coding, it’s best (though not customary) to know what you’re doing. Specifically, what are you going to present to the app’s user, what data do you need to keep to make that presentation, and how do you translate between the data and the presentation?
Model-View-Controller
The Model-View-Controller (MVC) design pattern formalizes those questions into an architecture for graphical applications. The Cocoa Touch application framework is designed to implement applications that follow the MVC pattern. If you don’t follow it, you will find yourself “fighting the framework”: Winning through to a finished application would be difficult, and maintaining it would be miraculous. The Xcode development tools are designed to support Cocoa programming and therefore the MVC pattern.
MVC divides the functionality of an application into three parts, and each class in the application must fall into one of them:
- Model objects embody the data and logic of a particular problem domain. Models tend to be unique to each application. You can create your own subclasses of NSObject or NSManagedObject to give life to your models.
- View objects handle user interaction, presenting information and enabling the user to manipulate data or otherwise influence the behavior of the program. Views are usually drawn from a repertoire of standard elements, such as buttons, tables, scrollers, and text fields. Views ideally know nothing about any problem domain: A button can display itself and report taps without needing to know what tapping means to your application. In iOS, views are instances of UIView or its many subclasses.
- Controller objects mediate between the pure logic of the model and the pure mechanics of the views. A controller object decides how views display and how user actions translate into model events. In iOS, controllers are almost always instances of subclasses of UIViewController.
The Model
From the nature of a passer rating, all you need is one model class: a Passer to carry one passer’s name, and the total attempts, completions, yards, touchdowns, and interceptions. Let’s make this a little more interesting: Ratings can be calculated over as many attempts as you like and are usually calculated per-game as well as in a career aggregate. So Passer should “own” any number of Game objects, with details of the game (who played, what date, and so on) as well as the passing statistics for that game.
The model then looks like the diagram presented in Figure 8.1.
)
Figure 8.1. The summary description of what data a passer-rating app would need leads to the plan shown in this diagram: A Passer object serves only to identify a single player; his career statistics are in a set of Game objects that Passer “owns.”
What about the Passer’s aggregate statistics—the career yards, touchdowns, and rating? Those can be pulled out of his Games—it turns out not to be hard at all.
The Views
iPhone applications don’t usually have a concept of documents, but even simple ones acquire many screens’ worth of views. You’ll deal in passers and their games, and you need to view and edit both.
So you need a list of passers, who can be created or edited in a separate view; and a view devoted to a selected passer, with a list of games that need a view of their own to create or edit them. A sketch of the flow appears in Figure 8.2.
)
Figure 8.2. A rough sketch of the Passer Rating application. The initial view (top left) simply lists all the passers known to the app. Touching the + button creates a passer; touching the detail-disclosure button (>) on a passer opens it for editing. Either way, you use the view at the bottom left to edit it. Touching a passer opens his career record and a list of his games (top right). Games, too, can be added (+) or edited (touch the game), and the app needs an editor for them.
Typically, each phase of an iPhone application displays a view object—a UIView—that fills the screen. That main view usually contains a hierarchy of other views. For instance, the Passer editor at the lower-left corner of the sketch (refer to Figure 8.2) consists of a wrapper UIView; it contains a navigation bar (UINavigationItem, at the top) which in turn contains two buttons (UIBarButtonItem, at either end). It also contains a table (UITableView) with three rows (UITableViewCell), each containing a label (UILabel) and a text-entry field (UITextField).
The Controllers
iPhone applications are organized around a sequence of view controllers, objects derived from UIViewController. Each view controller mediates between model objects and the views that fill the iPhone’s screen. For each full-screen view you see in the sketch, you must provide a UIViewController subclass to link the data in the model to the views on the screen. In the life cycle of a view, the controller comes first; when it is initialized, it creates or loads the view objects and sets them up to reflect the model.
Now, even a simple application like this slides four main views onto and off of the screen, according to a precise hierarchy. Managing the relationships between them—which to slide in, which to slide back to—would seem to be an involved task—and is. But, thankfully, it is not a task you need to worry much about. UIKit, the user-facing part of iOS, provides umbrella view controllers (such as UINavigationController) that manage the navigation tasks for you by taking ownership of your controller objects. All you need to do is request a transition between the views, and the umbrella takes care of the rest.