Design Patterns for Android

Model–View–Controller (MVC) Foundation

MVC Fundations
  • The original pattern for applications with a UI
  • The innovation that the pattern introduced was a guarantee that the view—what was rendered on the screen—was always consistent.

Process

  1. User, see something on the screen (the View) and, in response to what they see, take some action. They touch the screen, type something, speak, whatever. They do something that will change the state of the application.
  2. Their input is fielded by the Controller.The Controller has two responsibilities. First, it orders the user’s input. For any given user event—say, tapping the “stop” button—all other user events happen either before that tap or after it. No two events are ever processed at the same time.
  3. The Controller’s second responsibility is to translate user input into operations on a Model.
  4. The Model is the business logic of an application. It probably combines some kind of persistent data store and perhaps a network connection with rules for combining and interpreting the input from the Controller.

Android Patterns

⭐ In Android, regardless of the pattern, an Activity object, and Fragment—takes the role of the View.

In Android, regardless of the pattern, an Activity object, and Fragment—takes the role of the View.

Model–View–Intent

  • One of the oldest versions of MVC adopted by the Android community
  • The pattern decouples the Activityfrom a Model by using Intent and their payloads.
  • It can be quite slow and the code for constructing the Intents quite bulky

⛔ Deprecated for new patterns.

Model–View–Presenter

  • A goal for all of these MVC-based patterns is to loosen the coupling among the three components and to make information flow unidirectionally.
  • One of the earliest refinements replaces the View and Local Model references to each other with references to interfaces.
  • Extremely thin views and testable Presenters lead to much more robust applications.
  • The Local Model might hold no references to the View at all.
  • all.

📌 The most important attribute of this architecture, however, is that the Presenter (this architecture’s name for the Local Model) can be unit tested.

The most important attribute of this architecture, however, is that the Presenter (this architecture’s name for the Local Model) can be unit tested.

Process

  • The Local Model holds a reference, not to the View Activity, but simply to the implementation of some interface.
  • The View proxies user input events to its Presenter.
  • The Presenter, responds to the events, updating Local Model and Model state as necessary.
  • It then notifies the View that it needs to redraw itself. Because the Presenter knows exactly what changes have taken place, it may be able to request that the View update only affected sections, instead of forcing a redraw of the entire screen.

Model–View–ViewModel

  • Google, with its introduction of Jetpack, supports an architecture called Model–View–ViewModel (MVVM)
  • It is the most common and most discussed pattern for modern Android apps.
  • An Activity or a Fragment takes the role of the View
  • The View code will be as simple as it is possible to make it, often contained entirely within the Activity or Fragment subclass.
  • Complex views will need separate classes for image rendering or a RecyclerView. Even these, though, will be instantiated and installed in the view, directly by the Activityor Fragment.

📌 The feature of this pattern is that a single interface, Observable, is used to transmit changes in the state of the Local Model to the View.

Process

  • The ViewModel is responsible for wiring together the commands necessary to update the View and the backend Model.
  • Instead of the multiple Presenter interfaces used in the MVP pattern, the ViewModel represents viewable data as a collection of Observables.
  • The View simply registers as an observer for these observables and reacts to notifications of changes in the data they contain.
  • The Jetpack library calls these Observables LiveData
  • A LiveData object is an observable data holder class with a single generified interface that notifies subscribers of changes in the underlying data.