Take a look at this image, it shows how an iOS work on an iDevice. Numbered steps are explained below.
1. The user taps the Wages icon to launch the application on a device.
2. Code in the main.m file is executed, which triggers code in the AppDelegate’s didFinishLaunchingWithOptions: method.
3. Code in the didFinishLaunchingWithOptions: method loads the view, DemoAppViewController.xib in the iPhone simulator window.
That’s pretty much how any app you create for use on Apple’s hand held device works.
The Model-View-Controller (MVC for short) is nothing more than a software architecture Xcode use to separate an application into three components or layers: Model, View, and Controller.
It manages the application’s data. The model informs the controller of any changes made to the application’s data, which the controller pass to the View. The Model never communicate with either the View or Controller. For small and simple applications, you can set up the model in the controller. For medium to large applications you can set up the model in either the AppDelegate class or a custom class you create, using Xcode’s Object-Class template.
It display the application’s data in various UI objects (table rows, text fields, sliders). The view also accepts user’s action and pass it to the Controller. The view never communicatie with the Model, only the Controller. In Xcode, a nib file is the view.
It executes the user’s action, update the model, and ultimately presents the view to the user. The Controller also handles data validation and formatting before passing it to the View. For example, a Model may store data in an array object, but the Controller may sort the array’s elements before updating the View. For every view an application contain, there’s a controller for managing its data. If an iPhone application contains five views, you’ll have five Controllers, managing each each View. Think of a controller as the application’s work horse. A controller communicates with both the Model and the View.
Communication Between Components of The MVC Architecture
This diagram shows how components of the MVC software architecture communicate with each other, in an Xcode project.
Notice how the Model and View never communicate with each other; only with the Controller. The important thing to remember about the MVC architecture is this; it takes the user into account, it begins with him or her. It is the user who taps a button on the View, scrolls the View, or enter data in a text field. It’s the Controller that monitor this event and take the appropriate action, such as notifying the Model and updating the View.
How Xcode Uses The MVC Architecture
When you use these templates to create a new iOS application, Xcode separates the application’s logic (Controller) from the user interface (View) for you.
For example, when you used the Single View Application template to create a project, Xcode creates only two components of the MVC software architecture, as illustrated in this image.
You can use the Objective-C Class template to create the app’s Model or use the AppDelegate class file to set up the app’s Model.
In summary, an iOS application created using the MVC architecture to :
- manage the application’s data (Model)
- present data to the user (View),
- enables the user to manipulate the app’s data (Controller).