Notice that the objects in Figure 2.3 are separated into three sections labeled Model, Controller, and View. The Android APIs were originally designed around an architecture called Model-View-Controller, or MVC. In MVC, all objects in your application must be a model object, a view object, or a controller object.
-
Model objects hold the application’s data and “business logic.” Model classes are typically designed to model the things your app is concerned with, such as a user, a product in a store, a photo on a server, a television show – or a true/false question. Model objects have no knowledge of the UI; their sole purpose is holding and managing data.
In Android applications, model classes are generally custom classes you create. All of the model objects in your application compose its model layer.
GeoQuiz’s model layer consists of the Question class.
-
View objects know how to draw themselves on the screen and how to respond to user input, like touches. A simple rule of thumb is that if you can see it onscreen, then it is a view.
Android provides a wealth of configurable view classes. You can also create custom view classes. An application’s view objects make up its view layer.
GeoQuiz’s view layer consists of the widgets that are inflated from res/layout/activity_main.xml.
-
Controller objects tie the view and model objects together. They contain “application logic.” Controllers are designed to respond to various events triggered by view objects and to manage the flow of data to and from model objects and the view layer.
In Android, a controller is typically a subclass of Activity or Fragment. (You will learn about fragments in Chapter 8.)
GeoQuiz’s controller layer, at present, consists solely of MainActivity.
Figure 2.4 shows the flow of control between objects in response to a user event, like a press of a button. Notice that model and view objects do not talk to each other directly; controllers sit squarely in the middle of everything, receiving messages from some objects and dispatching instructions to others.
An application can accumulate features until it is too complicated to understand. Separating code into classes helps you design and understand the application as a whole; you can think in terms of classes instead of individual variables and functions.
Similarly, separating classes into model, view, and controller layers helps you design and understand an application; you can think in terms of layers instead of individual classes.
Although GeoQuiz is not a complicated app, you can still see the benefits of keeping layers separate. In a moment, you are going to update GeoQuiz’s view layer to include a NEXT button. When you do that, you will not need to remember a single thing about the Question class you just created.
MVC also makes classes easier to reuse. A class with restricted responsibilities is more reusable than one with its fingers in every pie.
For instance, your model class, Question, knows nothing about the widgets used to display a true/false question. This makes it easy to use Question throughout your app for different purposes. For example, if you wanted to display a list of all the questions at once, you could use the same object that you use here to display just one question at a time.
MVC works great for small, simple apps like GeoQuiz. In larger, more complicated apps, the controller layer can get very large and complex. In general, you want to keep your activities and other controllers thin. Thin activities contain as little business and setup logic as possible. Once MVC no longer lends itself to thin controllers in your app, you should consider alternative patterns, such as Model-View-View Model (which you will learn about in Chapter 19).