Your first iOS App (III): Model View ControllerFebruary 4, 2017 in
Welcome back! In the previous episodes of “Your first iOS App”, we learned the basics for downloading and using Xcode. Now, we need to understand some basic concepts that serve as the de-facto standard for the design and development of applications in iOS: The MVC paradigm, or Model View Controller. We will approach this concept in the less theoretical, more practical way possible.
The Model View Controller paradigm
In the Model View Controller (MVC from now on) paradigm, there are three main elements: the model, the controller and the view.
- The model: the model is the data representation and associated knowledge of the context or area of the application. It’s usually a data model and the logic that defines how data entities relate between them.
- The view: the view is the visual representation of a part of the model, and a set of controls that allow the interaction of the user with this data. Think on a view as a screen with a set of buttons, textfields and images that are showing some of the data from the model.
- The controller: the controller is the link between the model and the view. It’s where the logic to display the data and how to react to the interaction of the user lies. The model doesn’t know anything about the view, so it won’t be able to display any data, it’s just concerned about keeping and giving access to the information. The view, on the other hand, knows nothing about the model. Its only concern is visualize the information when told and report back of the user interaction with its controls. The controller is where the magic happens. Its duty is telling the view which data to show and how to show it, and transform the interaction of the user into valid actions and operations for the model to perform.
As an example, imagine that our application is a film or movie. The model will be the script for the movie, containing all the scenes, the plot and how the different elements (furniture, costumes, scenarios) relate with the characters. The view will be, of course, the scene being recorded, where all the visual elements take the form of concrete actors, attrezzo, movements on stage, etcetera.
The controller will be the director of the movie. He or she will be in charge of translating the script to a concrete, real scene. He has to control how the actors represent the script, and make sure the characters, furniture, visual elements, scenography, sound, etc follow the script and the spirit of the work. From this example, you may get the impression that the controller is probably the most important part for the success of an MVC application, just as the director is considered the most important piece in a movie, and you are probably right.
MVC is widely used as the standard de-facto paradigm for building applications today, not only on iOS, but also on Android, web applications and desktop software. The main reason is that MVC allows for a clear separation between the model and the view, which helps make the code more maintainable, and the views more reusable.
By making the model a separate, self-contained entity, it’s not subjected to how the model is represented, and thus the same model can be used for different views, different operating systems, and even different applications sharing the same model.
On the other hand, making the views data-agnostic, they are probably easier to re-use for different parts of the application. As an example, imagine a view that just displays an image gallery, and another view that display one of the images you pick up in the previous view full screen. Now think about the apps on your iPhone or iPad… how many of them have views like these? probably a lot, and you can have multiple different occasions in your application in which you will make use of this views to represent completely different data.
For this paradigm to properly work, there needs to be a strict separation between its three elements, the more strict, the more reusable and maintainable the final code will be.
The view is supposed to be logic and behaviour agnostic, meaning that it shouldn’t contain any functionality that dictates how the application behaves. It’s there merely to show the data and react to user’s interaction. This, unfortunately, ends up not being true for a lot of applications, but ideally the view should be limited to visual representation and stimuli reaction.
MVC in iOS
In the iOS world, the MVC paradigm heavily focuses on the controller. To summarize, every “screen” that you see is a subclass of UIViewController (or view controller). This view controller contains a view, that is the main visual component of the view controller. This view will later contain other views, labels, buttons, etc.
There is a strong pairing between the view controller and its view. You can think of it as if the view controller is the “code” portion, whereas the view is the “visual representation”. The view controller will usually be a .swift file with swift code, and will contain a “view” property that will link it with the visual representation.
The figure below may make this structure clearer. When you create your project, Xcode will create a class called “ViewController”, that inherits from UIViewController. This is the main view controller of your application, and it’s basically a swift code file.
If you click in the ViewController.swift file, it will take you to a swift code file similar to the one depicted in the figure, at the left. Xcode also creates a main storyboard, that is a graphical representation of the screens of the application and the flows between them. When first created, this storyboard only has one element, the view controller that corresponds to the class ViewController you just saw in code.
If you click on Main.storyboard, you will see it as a white rectangle with an arrow pointing to it, and a bar at the top with three small icons. This is a visual representation of your view controller, completely filled by a white frame, that is the view controller’s view. This view is accessed by means of the “view” property in our view controller’s code file.
Apple does not clearly define the model in its adaptation of MVC. Usually, the model will be a set of .swift classes containing the data model as a relationship of classes. This gives us a big deal of flexibility when defining our model.
Don’t worry if these concepts might seem too abstract. You will get a closer acquaintance with them as you develop your apps, in a natural way. For now, it’s just enough if you clearly understand the three main concepts of model, view and controller.
One of the main problems to avoid in a MVC project is the controller becoming a “super controller”, containing most of the code, and incorporating part of the logic of the model, and some visual representation duties that should belong to the view.
This is specially true in iOS, where is sometimes easy to overload the view controller and loose the separation between it and the model or the view.
However, MVC still stands one of the most used approaches for designing and coding applications, and rightly so. When properly applied, it allows for a nice modularity and separation between its components that makes the code reusable and maintainable.
Where to go from here
In this episode, we delved into the MVC (Model View Controller) paradigm, learned about how to apply it to an iOS project, and understood why it’s so important and useful for software development when properly applied.
In the next article, we are going to start adding visual elements to our application, and learn how controls and visual elements can be added and configured for our views.