Understanding M-VC in iOS

Posted: January 28th, 2012 | Author: | Filed under: iOS | 2 Comments »
This entry is part 4 of 4 in the series iOS Beginner blog series

MVC in web programming
I also assume that you know enough about MVC, or atleast understand separation of concerns in code structure. For Rails or CakePHP developers, this concept is already at the back of your mind.

So here’s my own simplified definitions of MVC:
Model : Data object classes, entities in your system/app, containing attributes. Eg: BlogPost class
Controller : The ‘director’ of Models, tell them how to move around and interact with others. Eg: A class that updates a BlogPost
View : The result of the interactions. What you see. Doesn’t really matter if you can’t see. The interaction happened anyway. Eg: A class that displays updated message.

M-VC in iOS apps
In iOS app development, Models are still Models, they are still data objects on their own. What’s different is that View and Controller are usually together, in a single class. The reason is that most of the time, the interaction that modifies your data object (by controller) usually followed by a change in UI *immediately*. An even simpler way to put it is that a single function call has to delete a BlogPost object and remove the table row at the same time.

The difference became much more apparent to me after months of learning how to craft great user experience, especially in the case of handling asynchronous remote data. These are the very essential steps of handling remote network connection:

  • Start a network connection
  • Update UI to show ‘waiting’ state
  • … nothing happens, wait
  • Connection finishes, parse and store data
  • Update UI with data

Besides, you also need to consider what to do when connection fails:

  • Why it failed? Should retry or abort?
  • Should update UI to show retrying state or show an error message
  • Can the user re-initiate the connect on UI

There are a lot of steps, the ones in italic are the responsible of a View, while others are handled by Controller.

In web development, you make a request, the Controller decides what to do with Models, then passes result to the View to display the state or changes. It’s not the same in iOS app. The changes to a View happens immediately when properties of Models changed. That is why in iOS app, the ViewController exists. In a broad sense, the lines of codes that should belong to View and the lines of codes that should belong to Controller are intertwine and inseparable.

To put the concept in real life. An application that fetches a number of blog posts from server and display them in a table would likely to have following 4 files


So this post introduced the ViewController way of thinking in iOS app. Take your time to apply the concept, look at some of the examples and try to guess which lines do the job of a View, which lines do the work of a Controller. It will serve as a solid foundation for organising your code.

While this is a good concept to understand. I remember that I did not really bother about it, instead, I wonder why the heck there is (UI)View when there is (UI)ViewController. And then there are stuff created inside a .xib with Interface Builder. As a beginner in a difficult programming language, I’m sure you are more drawn to use IB to create your controls. But then you are left with questions like:
– How to not use .xib?
– How to link a class with .xib you created after, what’s the real connection between them?
– Why some developers are against it, why some use it all the time?

In the next post, I will attempt to introduce the fundamental differences between UIView, UIViewController and how they are related to .xib files, Why Interface Build is good in some case, why it is not in some other.

Thanks for reading. You can now subscribe to my blog via email using the form on the right hand side.

<< PHP/Rails to iOS, what are .h and .m files?

  • I read lot of articles and really like this article. This information is definitely useful for everyone in daily life. Fantastic job.

  • Views and controllers are not together in iOS. Controllers follow the Mediator pattern from Gang of Four. They are mediators between model and views. As such they are allowed to know about both views and models. They are there so views and models don’t have to know about each other.

    Controllers are not views because they can not draw themselves on screen. They just know about views. They can have pointers (outlets) to view objects. Read Cocoa Design patterns by Apple for more in depth discussion of this.