Another MVP article (A Quick Android tour)

“Another one! — DJ Khaled” Photo by Safar Safarov on Unsplash

TL;DR

Model-View-Presenter or MVP was developed to enhance the separation of concerns in a business logic. It’s a variant of Model-View-Controller or MVC architectural pattern. One key difference of MVC to MVP is that in MVP the Model doesn’t directly communicate with the View component, as all communications is handled by the Presenter component.

MVP has three components:

  • Model — responsible for the data of your app.
  • View — responsible for displaying data and redirecting user actions to the presenter. Regarded as a “dumb” or a passive component, no business logic should be perform here.
  • Presenter — the “brain” of the app. All logical operations are contained and perform here. It fetches data from repositories (aka the Model)

Contracts — is an abstract type where methods to be used through out the app are defined with the use of interfaces. This component is what allows the components to communicate and perform operations.

Presenter and View components have a one-to-one relationship

Also MVP like other architectural patterns is open to a plenty of various implementation and experimentation, so implementing this pattern can be ambiguous.

So what is MVP exactly?

MVP stands for Model-View-Presenter, it is an architectural pattern used in software development to achieve but not limited to flexibility and maintainability in a project. Please note that MVP is not a design pattern but is an architecture built on design patterns and its implementation varies depending on the requirements. According to wikipedia , it builds upon the concept of another architectural pattern called MVC, for an overview of MVC please refer to this article. One of the key differences between MVP and MVC is that in MVP the Model and View components doesn’t communicate directly with each other, they communicate using the Presenter — this component can be look upon as the “middle man”. So how do they all work together? Read on.

How does MVP work?

The pattern essentially has three core components Model , View and Presenter and has an additional one that ties them all together, we’re going to call it — Contracts , let’s go through each them.

Contracts

Let’s talk about Contracts first , in this component you will define the methods to be used in your application, these methods are inside a specific component interface. You may think of these methods as actions that can be performed by Model, View and Presenter, allowing them to communicate. Contracts are inherited thus enabling the methods defined inside of the interfaces to be overridden by the child class(the inheriting class) because abstract type classes cannot be directly instantiated in a child class. It’s a normal sight for a Contract component to be ridden with methods.

Here’s a simple example of a Contracts component implementation written in Kotlin.

For the full reference , go to this repo.

Model

This is your data centre, this is the component responsible for fetching the data for your app, may it be from an http response or from a local database such as SQLite. The Model communicates with the Presenter directly and with the view only through the Presenter. This approach makes it possible to easily handle changes inside Model components without changing any or minimal lines of code in the View component as the View does not handle any logical operation and is made to be a “dumb” component thus making it easier to maintain your codebase.

“Exactly”

Here’s a simple example of a Model component implementation written in Kotlin.

For the full reference , go to this repo.

View

The component whose responsibility should be — is only to display information or update the state of the app and redirect user actions such as the tapping of a button to the Presenter component. The View needs to only know about the presenter so that it can makes use of its methods when redirecting actions or displaying data. It can be said that the dumber the view, the better implementation. The View should contain less logic as possible but actually the View may contain logic for visual display. The View can be your Activity or a Fragment.

“Chill”

Here’s a simple example of a View component implementation emphasizing communication with the Presenter, written in Kotlin.

For the full reference , go to this repo.

Presenter

I cannot stressed this point enough, this component is the “brain” of your app or the “middle-man”when implementing MVP. All business logic operations are kept here and it’s responsible for keeping the View and Model in contact when each other while effectively separating them.This component acts as an intermediate for both the model and the view, so it’s required that the Presenter knows about both.When the model is changed instead of updating the view directly, the presenter will be notified and will update the view accordingly.Note that in Android Development it’s better to handle intents or Android specific component like Contexts, Activity, Fragments etc. inside the View because it makes testing difficult when handled by the Presenter.

“Just don’t”

Here’s a simple example of a Presenter component implementation written in Kotlin.

For the full reference , go to this repo.

Closing Remarks

Thank you for reading! I hope you had take aways and I welcome any helpful comments or additional source of knowledge regarding this specific topic.

Happy coding!

Code-reads

Read On.

John Christopher Columbres

Written by

Avid book worm and a neophyte Android Developer. I love to write, read, code and I also have a profound passion for discovering new stuff!

Code-reads

Read On.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade