You've come a long way in the past few hours—you've provisioned a developer profile for your phone, learned the basics of the Objective-C language, explored Cocoa Touch, and gotten a feel for Xcode and Interface Builder. Although you've already used a few prebuilt projects, you have yet to build one from scratch. That's about to change!
In this hour, you will learn about the application design pattern known as Model-View-Controller and create a single application from start to finish.
Understanding the Model-View-Controller Paradigm
When you start programming, you'll quickly come to the conclusion that there is more than one "correct" way to do just about everything. Part of the joy of programming is that it is a creative process that allows you to be as clever as your imagination allows. This doesn't mean, however, that adding structure to the development process is a bad idea. Having a defined and documented structure means that other developers will be able to work with your code, projects large and small will be easy to navigate, and you'll be able to reuse your best work in multiple applications.
The application design approach that you'll be using on the iPhone is known as Model-View-Controller (MVC), and will guide you in creating clean, efficient applications.
Before we get into MVC, let's first talk about the development practice that we want to avoid, and why. When creating an application that interacts with a user, several things must be taken into account. First, the user interface. You must present something that the user interacts with: buttons, fields, and so on. Second, handling and reacting to the user input. Finally, the application must store the information necessary to correctly react to the user—frequently in the form of a database.
One approach to incorporating all of these pieces is to combine them into a single class. The code that displays the interface is mixed with the code that implements the logic and the code that handles data. This can be a very straightforward development methodology, but it limits the developer in several ways:
- When code is mixed together, it is difficult for multiple developers to work together because there is no clear division between any of the functional units.
- The interface, application logic, and data are unlikely to be reusable in other applications because the combination of the three is too specific to the current project to be useful elsewhere.
- The application is difficult to extend. Adding features requires working around existing code. The developer must work around the existing code to include new features, even if they are unrelated.
In short, mixing code, logic, and data leads to a mess! This is known as "spaghetti code" and is the exact opposite of what we want for our iPhone applications. Model-View-Controller to the rescue!
Structured Application Design with MVC
MVC defines a clean separation between the critical components of our apps. As implied by the name, MVC defines three parts of an application:
- A model provides the underlying data and methods that provide information to the rest of the application. The model does not define how the application will look or how it will act.
- One or more views make up the user interface. A view consists of the different onscreen widgets (buttons, fields, switches, and so forth) that a user can interact with.
- A controller is typically paired with a view. The controller is responsible for receiving the user's input and acting accordingly. Controllers may access and update a view using information from the model and update the model using the results of user interactions in the view. In short, it bridges the MVC components.
The logical isolation created between the functional parts of an application, illustrated in Figure 6.1, means the code becomes more easily maintainable, reusable, and extendable—the exact opposite of spaghetti code.
Figure 6.1 MVC design isolates the functional components of an app.
Unfortunately, MVC comes as an afterthought in many application development environments. A frequent question that I am asked when suggesting MVC design is, "How do I do that?" This isn't indicative of a misunderstanding of what MVC is or how it works, but a lack of a clear means of implementing it.
In the Apple Development Suite, MVC design is natural. As you create new projects and start coding, you'll be guided into using MVC design patterns automatically. It actually becomes more difficult to program poorly than it does to build a well-structured app.