Skip to content

App architecture

Jump to bottom
Kaushal Dhruw edited this page Apr 17, 2018 · 2 revisions

App Architecture

This app follows Model-View-Presenter (MVP) architecture pattern. MVP is one of the widely used architectural patterns for android apps and offers the following advantages:

  • Readable and maintainable code
  • Clear separation of concerns
  • Modular code which provides high degree of decoupling
  • More testable code
  • Code which is fun to work with

That is exactly what we want. An android app that has clean, maintainable, testable and robust code.

Model-View-Presenter basics

Model-View-Presenter (MVP) is a derivation of Model-View-Controller (MVC) architectural pattern and is mostly used for building user interfaces. It consists of 3 components

  • Model - Responsible for maintaining state of the data in the application. It is usually an interface that acts as abstraction between actual data (from remote or local) and presenter. There is usually one model layer per android app.
  • Presenter - Acts as a bridge between Model and the View. Responsible for retrieving data from Model, formatting the data and passing it to the View. Ideally presenter should not contain any android dependencies to enable isolated unit testing. Presenter is also responsible for accepting actions from view and taking actions on model accordingly.
  • View - View is passive. View should be kept as dumb as possible. Meaning it should not contain any business logic and should act based on Presenter's instructions. Responsible for displaying data passed on by presenter and routing user actions to presenter.

View is kept independent of business logic. Basically view acts as an obedient slave that follows Presenter's instruction.

MVP architecture

Model, View and Presenter communicate with each other via interfaces to keep implementation logic separate. This makes the components loosely coupled and makes the code maintainable. Testing each separate layer becomes very easy with MVP, as the components talk to each other via interfaces. To test View, presenter can be mocked, to test View and Presenter, data or model layer can be mocked. Yes, it takes a little extra effort to implement this in apps, but the benefits we get surpasses the effort required by a huge margin.

Implementation

In Android, activities and fragments are Views. Activity and fragment implement the View interface and contain a reference to Presenter. Presenter instructs the view what data to be displayed based on interaction with Model. Many a times Model is confused with Model class or POJOs, Model signifies model layer, whereas Model class and POJOs are simple classes that represent the structure of the data.

  • Model - In this app, we have a single interface that represents data or Model Layer (DataHandler.java). This is the single point of interaction for the layer. The implementation of this layer (AppDataHandler.java) is responsible for communicating with various data sources like remote database, local SQLite database, Shared Preferences etc. This encapsulates all the app data and state behind the model layer.
  • View & Presenter - There is one view and one presenter interface per screen, there is one contract that keeps related interfaces together. For example, for Sign In there is a contract called SignInContract.java that has 2 nested interface View and Presenter. SignInActivity.java, implements SignInContract.View interface while SignInPresenter.java implements the SignInContract.Presenter interface.

Here is the visual representation of Quiz App Architecture

App architecture

Data flow

As clear from the above picture, the state is hidden inside the Model layer. Data transfers from Model layer to Presenter and eventually View. Presenter should not care whether the data is coming from internet or from local cache, neither should View. This business logic (Where data should come from?), is a part of Model layer.

Backend

For quiz app we are using firebase as backend. User information, quizzes, discussions etc. are all part of firebase realtime database. None of the firebase dependencies propagates beyond model layer. So the View and the Presenter need not know where the data is coming from.

Clone this wiki locally