One of the early concepts that I learn from CS193P iPhone Development Course by Stanford University is MVC (Model, View, Controller). MVC is not a programming language. MVC is not a platform. It is a Software Architecture Design Pattern.
When you want to build a house, you will need to hire a construction architect to plan and design the blueprint of the house. The proper planning and designing is very important to make sure that the house will not collapse, to make sure that the resources are used properly and to make sure that the cost is within the budget.
It is the same with any software application development. If you want to build a great software that will not crash frequently, small in size, user friendly and good response time, lesser lines of codes, easy to debug, easy for other programmers to understand, then you will have to develop the software by following a good programming architecture pattern. So, MVC is the Blueprint of a software development project.
Objective-C is built upon Model, View, Controller (MVC) Design pattern. Apple expects all the iOS programmers to follow this programming architecture pattern. If you want to build a simple mobile application, you can easily get away with it without following the exact MVC patterns. But, when you are building a complex app with many features that needs frequent updates, you will run into a lot of trouble. At the end, you will be wasting a lot of time when trying to convert Non-MVC code to MVC code.
So, before starting a new mobile application development project in iOS, you will have to plan properly using MVC.
What is MVC (Model View Controller)?
Like Professor Professor Paul Hegarty mentioned in the lecture. We can consider MVC as 3 different camps.
Model – What your application is about? (Data, Logics, Rules)
Controller – How you present your application (model) to the end users?
View – The interface which the end users see
A Short Explanation on MVC
Controller always sits in between the Model and View. View does not own the data that it displays. View and Model can not have direct interaction with each other. View gets the data from Controller when the Controller implements itself the datasource of the View. The controller normally will get the data from Model before passing it to View. Only Controller have the freedom to initiate the direct communications to View or to Model. View and Model can communicate with Controller using some indirect methods explain below.
View can inform Controller for a certain events in 3 ways:-
a. Target-Action (eG: buttons)
b. Delegate (Will, Did, Should)
c. Data Source (data at, count)
Model can communicate with Controller only through:-
b. KVO (Key-Value Observing)
MVC Real Application Examples
Example 1: Creating a Simple Calculator App.
a. The logics of calculating the equations is the Model.
b. The number buttons, arithmetic buttons, the result displaying text are the Views.
c. The View Controller sits in the middle of Model and View.
The Simple Flow: The View Controller gets the inputs (via buttons) from the users and send the inputs to the model. The Model will calculate and send the result back to Controller. Lastly, the controller will present the result on screen via a Display view.
Example 2: Building a University Final Exam Result Application.
a. The Model is the database of the results
b. The View is the Table View/List View that shows the name of students, student ID, Grade, CGPA, total marks, Credit hours.
c. The Controller gets the data from database and shows it on the Views.
For this Exam Result Application, we do not need input from the users, we only need to present the data to the users. So, the model is slightly different comparing with the Calculator App. For View and Controller, they are always the same. View handles the interfaces for the end users and Controller handles the interaction between Model and View.
You might ask, why can’t we just show the data directly from Model to View? Why do we have to go through the hassle to create Controller? Answer: It is to make the programming in a simple and manageable way. When we want to troubleshoot a simple bug, we will know exactly where the bug is (either Model, View or Controller). From there, we can easily find the appropriate classes and find the bug from there.
Here is the example MVC Design vs Non-MVC Design:-
As you can see from the following graph,
When MVCs are Working Together:-
The above diagram show how the MVCs working together. You can see that the MVCs have simple and manageable flows. Each of the pointers are obeying the MVC rules.
When MVCs are Not Working Together/ Non-MVC:-
MVCs are not working properly on the above diagram. I just simply call it as Non-MVC. From the diagram, the flows of the pointers are everywhere. It is not a good design. When there is a bug, you do not know where to start the debugging.
For more details on Model, View and Controller, you can read from wikipedia: MVC (Model View Controller).
Understand the 4 Layers of iOS
As per the course in Standford, Professor Paul divides the iOS into 4 different layers. Core OS layer is the closest to the hardware while Cocoa Touch Layer is the closet to the user Interface. In most simple iOS projects, we probably will spend 90% of the time on Cocoa Touch layer. But, if you are building some specific location based mobile apps, then you probably will spend more time on the Core service Layer.
The following are parts of the frameworks/features for each of the layers:-
– Power Management
– Keychain Access
– File System
– OSX Kernel
– Address Book
– File Access
– Core Location
– URl Utilities
– Core Audio
– Core Animation
– Audio Recording
– Quartz (2D)
– JPEG, PNG, TIFF
– OpenGL ES
– Multi-Touch (Gesture)
– View Hierarchy
– Web View
– Map view
– Image Picker
Most of above information and source of images are taken from Stanford University iPhone Application Development course.