Revisiting Model-View-Controller (iPhone) App programming!

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:

The 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.




17 thoughts on “Revisiting Model-View-Controller (iPhone) App programming!

  1. Sakthivel says:

    * MVC pattern makes us to think in broad aspect like instead of concentrating only for result . It helps to keep our pieces in appropriate places. In future if there are any modifications in view or modal objects then we no need to worry.
    * If we follow the MVC pattern strictly and carefully , we can also increase our design knowledge.

    • mobisynth says:

      I agree with you Shaktivel, If you understand how to separate Presentation layer from Controller and Model classes, it makes you think in terms of architecture. Rather it enforces a well thought out architecture in your design.

      All platforms including Silerlight, Adobe Air, Web Tech, Android, Java, iPhone and other Application markup languages are starting to follow the paradigm. This is not new to Java world though.

      By the way: “Gang of Four” is a good read on design patterns.

      If you want to understand messaging then Ivar Jacobson’s work is a good read. Interaction models for Centralized and Decentralized controls.

  2. Abhimanyu singh says:

    ->MVC which divides our application functionality into three parts which help us to save our time and resources.

    ->Our view, code and data are in dilfferent section ,so we can very well change any part of the any section without effectiing other section.

  3. Vikrem Sheker says:

    Very interesting article. Would be more informative if a person not exposed to Iphone MVC tries a hands on exercise.

    I have worked with Servlets and JSPs. Understanding an MVC framework thoroughly enables us to write structured code in the most optimized way. However, at times tradeoffs need to be made (based on the requirement, one could write scriptlets in JSPs itself than using servlets)

  4. Vikrem Sheker says:

    Very interesting article. Would be more informative if a person not exposed to Iphone MVC tries a hands on exercise.

    I have worked with Servlets and JSPs. Understanding an MVC framework thoroughly enables us to write structured code in the most optimized way. However, at times tradeoffs need to be made (based on the requirement, one could write scriptlets in JSPs itself than using servlets).

  5. Its always a good design to seperate the presentation layer from the domain logic. Any change in view or controller does not necessarily require a change in model. However, if frequent updates require changing the domain logic then its a bit cumbersome.

  6. Siddhesh Naik says:

    MVC is a good design pattern that helps in product development, testing and improves maintainability of the code. As there is proper division between the views, models and controls, updates can be easily done on one part without much affect to other parts.

  7. Ravi Joshi says:

    View of an application is the first place where the user interacts with the application. The View unit receives input from an external event or a method call. This invokes the master controller which executes the business logic, updates the state of the model. The controller notifies the View of this update then the View unit gets updated version of the Data Model. This design pattern allows the application components to be built independently and then orchestrate them to obtain an application founded on sound architectural principles.

  8. Venkatesh S.R says:

    The article is very effective and Informative. The MVC talks about the applications and framework. It is used for product development, testing

  9. Yatin says:

    A very nice article on MVC and iPhone UI, especially useful for first timers like me……
    MVC looks similar in concept to the layered OSI communication model where different objectives are achieved at different layers. Mention of AppDelegate, UIViewController motivates me to dig deeper with additional reading. Using the existing controller classes surely hints towards relative ease of development.

  10. Vidhya says:

    MVC patterns are used in general because its more extensible and reusable, we are targeting on the app of iphone and if we just want to change the UI and not the the business logic. Its better to change the view and maintain the model and the controller.
    Everytime the an event is created the it is being notified in the model and a different design pattern can be used to update the state changes and provide an acknowledgement to the event. And hence it helps to reduce work. Specially when it comes to apps which has to be constantly upgraded.

  11. Aswath says:

    It is important for developers to understand the MVC design patterns..before developing any application the developer should think the better design pattern..this MVC architecture helps us to understand the flow of the application data and control..

  12. Sasi says:

    Cocoa Uses the Model-View-Controller Design Pattern

    Cocoa uses the Model-View-Controller (MVC) design pattern throughout. Models encapsulate application data, Views display and edit that data, and Controllers mediate the logic between the two. By separating responsibilities in this manner, you end up with an application that is easier to design, implement, and maintain.

    The MVC pattern means that Interface Builder requires no code to be written or generated while you focus exclusively on the View of your application. Cocoa bindings on the Mac eliminate most of the glue code, making the connection between Controllers coded in Xcode and the Views designed within Interface Builder a simple matter of graphically “wiring” the two together. Interface Builder works with Cocoa to make localizing your application easy so you can quickly enter entirely new markets.

  13. Sasi says:

    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.

  14. Venkata Mukkavilli says:

    Thats an educating blog post. I know for sure that there are many people like me out there who know the semantics of MVC architecture, but suck when it comes to implementing it for the first few times. Like Tarun said, its more about the separation of concerns at the architectural level, rather than at the class level. It is this thin layer of difference which, when understood correctly, makes you do wonders with MVC Design Patterns.

  15. jisna says:

    The main aim of the MVC architecture is to separate the business logic and application data from the presentation data.The main advantage of MVC is reusable.When problem occurs,no need to change the entire solution.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s