Notice that the objects in Figure 2.4 are separated into three sections labeled Model, Controller, and View. Android applications are 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.
-
A model object holds 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 on screen, 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 activity_quiz.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, Fragment, or Service. (You will learn about fragments in Chapter 7 and services in Chapter 28.)
GeoQuiz’s controller layer, at present, consists solely of QuizActivity.
Figure 2.5 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 methods.
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.