I need help in understanding MVC model in iPad/iPhone environment. Somehow I can’t understand it even after reading several times.
Let’s say I want to build a small application that store image location, and the comment for each image. I will possibly create a “SZImage” class that store these information. Aside from setter and getter, do I need to implement other methods? What is the role of model, what methods can it implement and what it can’t do?
After that, I will need to setup the interface for displaying image. So I need to create another class with name “SZImageView”. What is the role of this class? Does it draw on the iPhone window or I leave it to the controller to do the job. If I leave to the controller to draw, then why should I create this class?
And if I need to have controller to be the bridge between the model and view, then a class with name “SZImageViewController” should be created. What should this class do?
Last, this is the one that have been confusing me for a long time. How can I use the method in other class to add window to the AppDelegate? How does the interaction between instance within class be done. Because I see that the AppDelegate is usually very short and simple.
Model-View-Controller Class Categories and Examples
In Model-View-Controller (MVC), every class should be designed to fit into one of these three categories. In doing so, you can avoid class coupling and create much more flexible code.
Model Classes.
Classes of this category should represent the application’s data model. If the application is a game then classes that represent the player, enemies, level layouts, saved data (such as scoreboards) and so on. But these classes should be restricted only to holding the data that represents these objects and the logic behind them. For example, if it’s a racing game, the class ‘Car’ should be part of the model, and it should represent all the properties of a car (for example it’s speeed, acceleration, turning etc.). This class should also include all the necessary logic for the car, for example logic that determines how the car should move (such as acceleration and breaking, turning), and what should happen in the event of a collison and so on. This ‘Car’ class should note define how the car is presented to the user. Nor should this class involve any application logic. It should stick completely to describing what it is to be a car.
View Classes.
Classes of this category should represent the way in which the application presents the model to the user. Keeping with the previous example, examples of classes that fall into this category would be a ‘MainMenu’, ‘ScoreBoardView’, and ‘RenderingEngine’. The ‘MainMenu’ class knows exactly how to display a list of options to the user and how to look really beautiful. It also knows that when one of the options is selected, it should change its visual appearence slightly, such as a button appearing “pushed in”. However, this class doesn’t know what logic to do when a button is pressed. This is the job of the controller classes. So the view classes simply let the relevant controller know that the user interface has been interacted with by the user (by either calling some controller method or sending a notification out). More on this in the controllers section.
“ScoreboardView” also knows that when it’s passed a dictionary (model class) of strings and numbers (player names and scores) that it is to present them in a particular way, perhaps in a table. It doesn’t know how to update the dictionary, nor how to calculate the average score. If it want’s more information then it needs to ask the controller for it. It’s then the controller’s job to figure out a way of getting the information.
Finally for this section, a “RenderingEngine” is a view class because it takes a model and produces visuals for it. And that’s it. The RenderingEngine is programmed to know how to display a car, and that if the car is set to be in a particular location then it should be drawn in this location, or if the car has collided then it needs to be drawn with buckling. But again, it doesn’t know how to update the position of the car, nor the speed and so on.
Controller Classes.
Finally, and as I’ve already previously slightly alluded to, controllers are the classes that bring everything together, and provide the flow and control for your application. People have refered to the controller classes as the “brains” of the application because they make decisions based on the user’s input (which is channeled through the view classes) and the data model (which is accessible through the model classes).
The controller classes control the application’s flow. They take the user from the “main menu” to the “car selection screen” to the “race track” to the “race” to the “scoreboard screen” and so on! They make changes to the model through the classes and they provide the feedback of changes to the view classes so as those classes can present the current state of the application to the user. Controllers effectively link the model and the view together, while at the same providing application logic and program workflow. This program workflow can also include handling issues where the input that is taken from the view does not fit correctly with the model. The view has very little knowledge of the model and can’t provide the necessary checks – this is one of the jobs of the controller. For this reason, it’s generally considered bad practice to directly link the view classes with the model classes. Of the three types of classes, the controllers are generally the classes that are the least interchangeable, but in practice it is the view and model classes that you would want to interchange the most.
Conclusions. The model-view-controller design pattern allows developers to logically organize their work and the components of their applications. When the model-view-controller paradigm is used it maintains flexibility because any of the three components can be replaced, so long as the replacement module keeps to the same protocol that the other two components expect to be able to intereact with. (When I say “protocol”, this can design can either be implemented using inheritence, or for some cases, it’s better to use an actual protocol declaration and ensure that classes confirm to the appropriate protocols.) A perfect example of this is that many applications written for the Mac can easily be moved over to iOS because the only major difference between the two platforms is at the user interface level, which is completely understandable given that the interface for the Mac is traditionally a large screen that the user interacts with via a keyboard and a mouse, on the other hand, the interface for iOS consists of a much smaller screen that the user touches to interactive with.
Further reading. The wikipedia page (of course!), MVC in the Apple Developer Documentation, ‘Cocoa Design Patterns’ by Erik M. Buck.
I’ve tried to keep this explanation fairly generic to all platforms, frameworks and languages. In iOS development, the MVC design is considered so paramount that you would have to work very hard against the frameworks to avoid using MVC. There is a clear distinction between the view classes (UIView, UITableView, UIAlertView, UIImageView etc.) and the controller classes (UIViewController, UITableViewController, UINavigationController etc.) and the rest of the model classes (NSString, NSDate, NSManagedObjectContext, UIImage etc.). Every class clearly resides in one of these three categories which allows for code reuse and hugely flexibility as you’re developing your app.
More specificly relating to your question, your AppDelegate will fall into the controller classes category. It provides the control over the key events of your application. When the application is launched, when it will quit, when it will enter background mode and so on. Your program needs to have a place where the thing to do at these events is handled and this is where it should be implemented.
I hope this helps. I’d also strongly recommend checking out the free WWDC2010 Session Video on the Model-View-Controller paradigm.