Best practices MVP in Android

Working with GUI applications is a lot of fun for a developer. We get to influence design and user experience as well as the end product for any given feature. This can be fun until a designer comes over and shows you something you know will be entirely custom or better yet, it is a complete redesign but you haven’t spent any time building an architecture in your company’s app. Uh oh! Get ready to cancel all your prior engagements, late nights and long days await. It doesn’t have to be like this though.

In most of my apps, I prefer to use the Model View Presenter (MVP) pattern although MVVM is basically the same idea (I am not talking specifically about the ViewModel from architecture components… but you can read more about that in my previous blog post). Okay, so what am I talking about.

Well, in the MVP pattern we have our three layers again:

  • Model – controls how we access and manage the data in our application
  • View – controls how we display that data in our user interface
  • Presenter – acts as a middleman between the view and the model

Alright great! Now we know what the three pieces are but how do we go about making this a real thing in our app? We are going to build out a simple tip calculator application using the Kotlin programming language and the MVP pattern.

Okay, so we see that when an action is performed via the user interacting with the view, the presenter uses its knowledge of the model to have it perform an operation, return the result and then display it back in the view. Let’s take a look at how we can adapt our code base to this pattern more closely though.

When designing the MVP pattern we should really consider what does our application need to do in terms of functionality. Since we are building a tip calculator this will be relatively simple to figure out.

With our Model we want to allow the following functionality:

  1. Set check amount
  2. Set a tip amount
  3. Compute the total price of the check including the tip

With our View we want to display the following:

  1. A TextInputEditText to collect the check total
  2. A ChipGroup with Chips to allow the user to choose a tip percentage
  3. A FloatingActionButton for the user to press to compute the total with tip
  4. An AppCompatEditText to display the total
  5. An AppCompatEditText to display the tip amount

And finally, with our Presenter we want to:

  1. Setup the initial View state
  2. Pass the tip percentage to the model when a Chip is checked
  3. Pass the check amount to the model and compute the cost of the total check with tip
  4. Tell the view to display the total and the tip amount

Now that we have the important stuff laid out we can start building out the different layers of the application.

The View is comprised of our MainActivity. Since we are developing a testable architecture though we will use interfaces to define the contract for the View and the Presenter. This may seem unnecessary now but in a later post, we can see how this architecture allows us to test our app on a JVM. We can start with the following Contract interface which wraps these two other interfaces like so:


Now let’s implement the interface and add the code for all the widgets to display the data from our presenter layer in our View.

Now since the MainActivity creates the Presenter lets look to see how it manages the View and Model as a middleman:

Finally, we can look at our Model code which handles the business logic of our application:

And that’s it! We have an app that uses the MVP architecture in the Kotlin programming language. As you can see the View is pretty dumb in that all it handles is displaying things to the user based on our presenter interacting with our mode. The best part about this architecture is that you can test it very easily which I will show in an upcoming blog post!

Please comment or share on social if this was helpful!