iPhone (and for that matter Android as well) uses MVC or model-view-controller patterns as agents of decoupling and reusability. MVC lies at the core of design patterns and is extremely useful for GUI-based Applications. Mobile Apps are generally GUI-based, unless you are writing a daemon (that means you are working at Apple, in that case you don’t need to read this blog entry) or an Android service (even a service has an interface component and hence the need for a facade which is very similar to a view, remember Ivar Jacobson?), and hence MVC assumes great importance for developers as well as testers who work on these platforms.
These days, almost all frameworks use MVC to a certain extent, but few are as true to MVC as Cocoa Touch.
The MVC Model divides up all functionality into three distinct categories:
Model: The classes that hold your application’s data
View: Made up of windows, controls, and other elements that the user can see and interact with
Controller: Binds the model and view together and is the application logic that decides how to handle the user’s inputs
The goal in MVC is simple and straightforward: Separate the presentation layer from business logic and the classes that represent data (entities) in tables (object store in case of ODBMS). This clear demarcation and separation of view from business logic and data enables maximum reusability of code. The benefits are immense, especially in the presentation layer. Proper usage of MVC pattern cuts down development and testing time by more than 50%.
For example: Say you have an object that represents a button, this object should not contain the code to process data when the button is touched or clicked, this task is delegated to a separate action class (or a method), that can be easily implemented in a controller, similarly a class that represents a “banner Ad” should not implement methods to draw the Ad in a view.
A typical iPhone application starts with an AppDelegate class (the functionality of the app is delegated to this class, thereby it acts as the starting point for the application. Runtime calls this class). The class further initializes the data stores as well as controller classes. The controller classes, when activated load their own respective views (now, views can be drawn or they can be fetched – ah ha .. from .xib files). Though you can create controller classes as pure custom classes (subclasses of NSObject) but more often than not, they will be subclasses of one of several existing generic controller classes from the UIKit framework such as UIViewController, this is the case because you get a lot of view management functionality for free without having to redo these things.
Apple iPhone Docs describe UIViewController as:
UIViewController class provides the fundamental view-management model for iPhone applications. The basic view controller class supports the presentation of an associated view in addition to basic support for managing modal views and rotating views in response to device orientation changes.
The documentation further states:
Subclasses such as UINavigationController and UITabBarController provide additional behavior for managing complex hierarchies of view controllers and views.
Now, lets parse these statements and try to reflect on most of the iPhone apps we have seen. Quite a large number of iPhone apps feature a TabBar at bottom and Navigation bars at the top, if these two types of view controllers manage hierarchies of UIViewControllers, then is it possible to stack up our view controllers (which further load views, thru code or nibs) on these master controllers and invoke them as needed? Thats a simple and straightforward iPhone app right there for you.
– Trigger the AppDelegate
– Initialize the data store
– Invoke the master controller
– Stuff View Controllers in master controllers
– make at least one ViewController visible (this controller will load the view)
– When view is visible, act on the components (and lets all hope you connected the outlets to action methods)
– Optionally, define protocols and delegates (will leave this one for some other day)
– Rest is syntax, factory classes, messaging and semantics (will cover this separately as well)
… and your winky dinky iPhone app is ready to be launched … that is if you have a Product Manager to help you with branding and marketing.
To learn more about ViewControllers click here.