A simple guide for MVC, MVP and MVVM on Android projects

Model View Controller

MVC design pattern splits an application into three main aspects: Model, View and Controller. It forces a separation of concerns, it means domain model and controller logic are decoupled from user interface (view). As a result maintenance and testing of the application become simpler and easier.  

mvc

Model

The Model represents a set of classes that describe the business logic i.e. business model as well as data access operations i.e. data model. It also defines business rules for data means how the data can be changed and manipulated.

View

The View represents the UI components. It is only responsible for displaying the data that is received from the controller as the result. This also transforms the model(s) into UI.

Controller

The Controller is responsible to process incoming requests. It receives input from users via the View, then process the user’s data with the help of Model and passing the results back to the View. Typically, it acts as the coordinator between the View and the Model.

Model View Presenter

This pattern is similar to MVC pattern in which controller has been replaced by the presenter. This design pattern splits an application into three main aspects: Model, View and Presenter.

model view presenter

 

Model

The Model represents a set of classes that describes the business logic and data. It also defines business rules for data means how the data can be changed and manipulated.

View

The View represents the UI components. It is only responsible for displaying the data that is received from the presenter as the result. This also transforms the model(s) into UI.

Presenter

The Presenter is responsible for handling all UI events on behalf of the view. This receive input from users via the View, then process the user’s data with the help of Model and passing the results back to the View. Unlike view and controller, view and presenter are completely decoupled from each other’s and communicate to each other’s by an interface.

Also, presenter does not manage the incoming request traffic as controller.

Key Points about MVP Pattern
  • User interacts with the View.
  • There is one-to-one relationship between View and Presenter means one View is mapped to only one Presenter.
  • View has a reference to Presenter but View has not reference to Model.
  • Provides two way communication between View and Presenter.

Model View ViewModel

MVVM stands for Model-View-ViewModel. This pattern supports two-way data binding between view and View model. This enables automatic propagation of changes, within the state of view model to the View. Typically, the view model uses the observer pattern to notify changes in the view model to model.

model view viewmodel

Model

The Model represents a set of classes that describes the business logic and data. It also defines business rules for data means how the data can be changed and manipulated.

View

The View represents the UI components. It is only responsible for displaying the data that is received from the controller as the result. This also transforms the model(s) into UI.

View Model

The ViewModel is responsible for exposing methods, commands, and other properties that helps to maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself.

Key Points about MVVM Pattern
  • User interacts with the View.
  • There is many-to-one relationship between View and ViewModel means many View can be mapped to one ViewModel.
  • View has a reference to ViewModel but ViewModel has no information about the View.
  • Supports two-way data binding between View and ViewModel.

Android Implementation

For the following segment the term “controller” will be used, but the same component can be applied to all 3 architectural patters as controller, presenter or ViewModel.

android implementation

A common approach in android is to use Activity classes as the Controller and Fragment classes as the View layer. But it reduces the flexibility re-usability of the code. Fragments and Activities also have a limited range of available transition animations.

UI classes (i.e. LinearLayout) for View Layer

The view layer should be implemented in classes which extent android view (ui) elements, such as LinearLayout or ViewGroup.

  • Reuse feature independent of activity / app flow.
  • Reduce number of activities (resource friendly).
  • No dependencies apart from the controller.
(independent) Controller Class

The controller class should not extent any android class. Keeping it decouple it from Activity and Fragments allow us to reuse it

  • Slim controller, behaves as the glue code between View & Model layers. (Single responsibility)
  • Pushes events to other controllers (i.e. analytics)
  • Decoupled from Android classes — reusable.

Available Libraries & Frameworks

The following android frameworks enable the mentioned implementation. We don’t need them at this point, but they might be handy if we want to adapt this strategy in the whole code-base.

Base : a lightweight library that gives you a clean architecture foundation for your Android MVP’s.

Square mortar : A simple library that makes it easy to pair thin views with dedicated controllers, isolated from most of the vagaries of the Activity life cycle.

inloop AndroidViewModel : Separating data and state handling from Fragments or Activities without lots of boilerplate-code. Reducing them to simple dumb views.

sockeqwe mosby : A Model-View-Presenter library for modern Android apps

BARACUS : the BAReknuckle Android Context USher, a tiny framework for android development enabling you to have dependency injection, dynamic context handling and database object relational mapping.