"Model-View-Controller is not an inescapable law of purity, but a pragmatic principle of effectiveness."
—Anonymous
In this chapter we will learn about Model-View-Controller, popularly abbreviated as MVC, which is a design principle based on the ideas of code reusability and separation of concerns (SoC). This architecture imposes serious constraints on the structure of an application, however, surprisingly these restrictions make it considerably easier to design and maintain the application. In this chapter we will be covering the following topics:
- Understanding the Model-View-Controller paradigm
- Creating a RubyMotion application using MVC
- Connecting to an external API
- Enhancing the application with search and images
- The do-it-yourself exercise
Model-View-Controller (MVC) is a design principle that separates the representation of information from the user's interaction. The main purpose of MVC is to make the code more modular and reusable, which increases the product quality.
Most of the popular commercial and noncommercial application frameworks are created to enforce the MVC design pattern. However, RubyMotion does not force you to use MVC style, but this way of programming is central to a good design for application development. If we make use of MVC while developing our application, it will be beneficial for us later on, as we will be able to add new features more easily.
As the name implies, the application is divided into three distinct parts: model, view, and controller, where model encapsulates application data, view displays and allows editing the data, and controller is the place where logic of the interaction between the two (model and view) resides. Let's understand each of them individually.
The model contains the application data and business rules. The model could just be the actual data store, either in-memory (maybe as an NSArray or NSDictionary class) or to-and-from disk. In a more complex app, you may choose to use a SQLite database or Core Data, and your model would be a simple instance or one piece of data.
A view is that part of an application that outputs information from the model via the controller. The logic should never be written in the view; the sole purpose of the view is only to present information. In iOS, and also in RubyMotion, most views are subclasses of the UIView class that provide the capability for handling touch events and drawings. The UIKit framework contains classes to draw typical interface elements such as tables (lists), buttons, text fields, and sliders.
A controller is a link between the model and view. A controller acts as an intermediary between one or more application views, and one or more of its models. In iOS, the controller is generally a subclass of UIViewController that also manages a view; this class is also responsible for responding to delegation messages and target-action messages.
The Model-View-Controller layers are very closely coupled, as shown in the following diagram:
The View and Controller layers interact through User Action and Update as shown in the diagram. Whenever the View layer creates or modifies data, it is communicated to Controller through User Action. Similarly, whenever Model updates any change it will first Notify the Controller and will then be reflected on the View by an Update .