I’ve been looking for a way to create cleaner Android application code for ages, studying reams and reams of articles on the topic until finally my persistence paid off. I’ve found the best way to do it! The answer MVP. After litres upon litres of coffee and many sleepless nights my first MVP project was ready and after a little more coffee and 2 more weeks of insomnia our application had been rewritten with the MVP pattern.
To be honest, after the first release of our new version with MVP I found myself thinking “Had I made a mistake, there were more lines of code and the application was working just like it had before.” I was really questioning whether all those sleepless nights had lead to nothing new, but all my doubts were dispelled after the first feature was integrated. I expected to spend a minimum of one week on it but I spent only 3 days on getting it up and running. I’m sure you can imagine I was a happy guy!
This success has driven me to share what I’ve learnt and over a four-part series, I will be discussing the world of MVP. In this article I’m going to do my best to explain the following:
- What MVP is exactly
- Why you should use it for your projects
- What are the key benefits and outcomes you can expect
Subsequently, we will delve deeper into Android development using MVP pattern in varying parts. So without further ado 😉 let’s get started. I do hope you find value in what I have to share because I believe even if you are an experienced developer with a wealth of knowledge this is a relatively new space and worth learning a little more about.
What is MVP?
Model-View-Presenter (MVP) — is an architectural pattern which is mostly used for building user interfaces. In this pattern Presenter is the “middleman” between Model and View. It takes care of all interface events, like clicking on the buttons, moving the mouse, etc. If we look at the history of this pattern, we’ll find that it is a derivation of the Model-View-Controller (MVC) pattern. MVP and MVC are very similar however, the main difference is that in MVC, all user interactions are circular, users interact with View, then View passes this action to Controller, it will be manipulated over Model and finally Model will fire events on View.
While MVP has a completely different logic. As you can see in the diagram above, Presenter is the “middleman” between View and Model. It takes calls from View, manipulates them with Model and returns a result to View.
Now it’s time to understand those three little magic words a bit better: Model, View, Presenter:
- Model -is the data that is displayed in View.
- View -is just an interface that displays data (our Model) and delivers events from user to Presenter.
- Presenter -our “middleman” between View and Model, stores all the business logic.
As Android development is key to our subject matter I’ll show a few examples of what it looks like on Android. Model, as I mentioned before is our data that will be displayed. For example, our application has a screen for user data display. This screen allows for multiple actions: load users, add user, delete user.
From there we need to write a model like below:
Now we need to create our View, this will show a list of users and add or delete users from the list. In this case it is an Android Activity, but it also could be a Fragment or even a View (Android View):
Then finally we need to develop our Presenter class. Our Presenter should have our View and Model objects and methods to get all users, add or delete user.
Now you should be able to see how this ‘middleman’ works. It includes all the needed business logic. It should be noted that, unfortunately, in our example, we aren’t able to see all the hard logic we would have in a real project — but I assure you it is there. However, I’m sure you’ll agree that it’s quite easy to understand how it works and what I meant when I called it the “middleman”. Hopefully you’ll also have seen why it’s pretty important to use these kinds of patterns in your own Android projects.
Let’s assume for a moment that the task was a little bit harder. As an example, imagine that, not only did you want to load a list of users but you also wanted to sort the list, remove duplicates and generally just end up with a clean list. Added to that you don’t just want to add or delete a user from the list but you also would like to check (via network call) if you have the permission to do any of these actions. And once you’ve written all the logic, your View (Activity or Fragment) becomes a “god object” with hundreds of lines of code — urgghh. It’s able to do all these extraneous tasks like sorting, removing duplicates and so on but in ideal world View shouldn’t have to do all of this stuff, it really only wants to get the data from Presenter and simply show it to the user. That’s all that View really wants to and should do and this is what MVP allows for, taking more complex actions and simplifying them.
While I’m talking about the benefits of using MVP pattern for Android projects I’d like to mention what’s been most valuable for me:
- First of all we’re able to split our code into logical parts. All business logic moves from our Activities / Fragments to Presenter. All future changes in logic will only be affected on Presenter.
- All of our UI code will stay in Activity or Fragment and we no longer need to rewrite code after any changes in business logic.
- No more “god objects” with hundreds lines of code.
- Now it’s easy to integrate new features, just add / update Model, View and connect all the new stuff through Presenter.
- Testing becomes easier and faster because we don’t need to always think about Context and other Android specific classes, you just use Presenter with all the business logic and test! it’s an absolute pleasure.
This is just a condensed list of benefits you will experience after integrating MVP pattern. Trust me there are more and while I’d love to share all the positives, we’d be here all day! You really should go out and try it yourself. I’m sure you’ll find something that will benefit your needs perfectly.
See you soon for Part 2!