Developing for iPhone - Part 3, (Bad?) MVC
In this post, I’m going to dive into the inner workings of Apple’s UIKit for iPhone, and see how they handle the MVC (Model-View-Controller) design pattern.
Well, what exactly is MVC? A design pattern that should help you organize applications while keeping code re-usable at the same time.
It breaks down applications into three distinct layers: Model, View, and Controller. The WPF equivalent is MVVM (Model-View-ViewModel), which I may go more into detail with a future post.
Let’s break it down:
Model – Your application’s model (or sometimes called domain) contains all business logic behind your application. It should not know anything about the UI, and should be completely re-usable from project to project. Anything talking to a database, web server, etc. needs to be in this layer. In reality, nothing should stop you from using identical model classes in a WPF windows application and a MonoTouch iPhone app (with the exception of missing features from MonoTouch).
View – This is the UI and only the UI. Little to no logic of any kind should be here. In reality the only bug that could possibly be present in your View should be: “that doesn’t look right”. This makes writing automated tests a breeze, since your View can be kept out of it.
Controller – This is the majority of all the work done in an MVC application. Events from the View (button presses, etc.) are taken and translated to the Model layer and the results are used to update the View.
So step by step:
- User clicks a button in the View
- Controller gets the button press event and coordinates the correct operation to perform on the Model
- Model does its underlying job: talks to server, database, etc. and returns the result
- Controller takes the result and updates the View
- Cycle continues when the user does something else with the UI
(Note: for some implementations of MVC, in step 4, the Model directly updates the View. I consider this a bad idea in general, as it breaks the re-usability of the Model between multiple applications.)
What does this gain us?
- Organization – this is huge, as a larger problem is broken down into layers where any developer should be able to look at the code for a particular screen and figure out what is going on.
- Code re-usability – models can be completely re-used between applications as well as the ability to completely revamp the UI without disturbing the inner workings of the Controller or Model.
- Focus on Object Oriented Programming – applications are forced to be OOP, since each View has a Controller dividing the application into classes screen by screen at the bare minimum.
- Testability – your Model and Controller layers can easily be unit tested without a UI at all. Test driven development (TDD) is luckily starting to become more and more popular, and the MVC pattern helps in this regard.
- Divides the work – Model, View, and Controller can be given to 3 different developers. Also gives you the benefit to leverage the capable graphic designer to create the View when possible. Now graphic designers can program!
Well, what does UIKit look like?
MonoTouch exposes UIKit exactly as you would see it in Objective-C (with the exception of adding strong typing where Objective-C uses weakly typed messaging). I’m sure they did this for simplicity, and to not step on Apple’s toes by abstracting away their framework. It also enables MonoTouch developers to seek out answers to issues with UIKit within the Objective-C community as well as the MonoTouch community. MonoTouch's 1-to-1 mapping of UIKit doesn’t exactly help the design-pattern-conscious C# developer, however, since UIKit’s MVC gets a little messed up as you dive in deeper.
When developing an iPhone app with MonoTouch, you use Interface Builder (IB) for building your View, the same as you would with XCode and Objective-C. IB has a nice little UI to build your various screens on the iPhone and can wire actions to your desired controllers. From here, you write your code in the Controllers and Models as you would expect in MonoDevelop (the C# IDE for MonoTouch).
By default, Apple’s UIKit breaks down MVC as such:
- View – Drag/drop UI pieces in IB such as UIView, UIButton, UILabel, UITableView, etc.
- Controller – Referenced in IB, you wire “Actions” from the View to each controller. Base classes for controllers are appropriately named UIViewController and UITableViewController.
- Model – Left completely up to the developer, as it should be in my opinion.
Next time I’ll go over what I feel is bad about Apple’s version of MVC, and ways to make it better.