#theRealMVP
Discussing the use of the Model View Presenter design pattern and its advantages for Android development.
As I mentioned in A Quick Dive into Kotlin for Android, my next project was going to be a simple fire simulation view using OpenGL ES on the Android platform. Sadly, I’ve been swamped building a few apps, both Android and iOS. (But not so sad, because they actually pay me and making money is cool.) That has drained allot of the time I’d spend on side fun stuff like making FIRE!
In the meantime, I asked my buddy John Shelley to come and help me write a piece. We’re currently working on a few projects together and he’s been structuring his Android projects in an MVP design pattern. He’s been doing this for a while and I must admit its a pretty good way of doing things. With
So here’s how this will work. From now on, bold is me asking a question, or making a comment, and the regular text is John’s answer. If this works out well we hope to do several in the future right John Shelley?
Introducing the real MVP.
Why was the MVP design pattern created?
The basics of MVP stem from the idea of separating out concerns in your applications so each piece can be as modular as possible. This allows the code to be more extensible, easier to read, and easier to test. I won’t be able to articulate it as well as others have though so I urge people to research it for themselves. It became fairly popular when Microsoft started using it in their .NET examples and documentation. For clarity it’s always easiest to start with Wikipedia.
What roles does each module have?
- Model — The model is the data to be displayed to the end user or to be acted upon from the user. For example in a note taking application, the underlying model would be a “Note” object.
- View — The view is pretty straight forward, it is a literal view or user interface that the end user will see and interact with. There are variations of the MVP pattern but the most common allows the View to be completely passive which means it forwards all interactions to the presenter to handle. As dumb as a box of rocks.
- Presenter — The presenter is the glue that holds the model to the view. It retrieves the model if possible and displays it in the view. If the view is interacted upon it communicates this to the presenter to allow it to handle all the logic that should happen.
How should we structure a simple Activity?
The best way to look at your application through MVP eyes is to start going through Google’s many code labs. MVP allows for extreme testability, so what better way to show its structure then a testing code lab.
An Activity in MVP is fairly plain, it just adds our Fragment to the screen.
The key to this defined structure is the “Contract”. You create one for your “View” and “Presenter”. A Contract is an interface that both should respectively adhere to.
Our Fragment is our view and thus implements our “Contract.View”. Likewise our Presenter will implement our “Contract.Presenter”. Naming is irrelevant, whatever makes sense to you.
The golden rule, is that your Presenter shouldn’t have any Android related code residing inside it. It should be pure java so that it can be Unit Testable, because we all know that Unit Tests should be our number 1 priority.
Why should Android be a real MVP?
Why did you switch to the MVP pattern?
I think there were two big reasons for making the switch for me. The biggest reason was for testing. Including Unit Tests in your Android projects is extremely difficult even when using tools like Roboelectric. However if you take out the Android SDK you’re left with pure java which is extremely testable. Throw in some Mockito and you have yourself a party.
The second reason was purely from an internal struggle I (and many other android devs) had. The Code was keeping me up at night. And if I could sleep I would dream of code, and not good code, the kind of code that strangles you. We’ve always been taught to make sure our code is modular, easy to read, and extensible. I’ve tried looking into other ways of doing this for Android projects, and MVP makes sense to me.
When should a team consider making the switch?
Yesterday! No, in all seriousness, if you have a specific pattern you currently adhere to and it works for you, then don’t switch. Everyone has their own way of working. However a lot of people don’t have a solid foundation yet. Working in Android, you can easily create a god Activity or Fragment and that doesn’t separate concerns well enough. The MVP approach is validated by Google and easy to understand.
How long do you expect MVP to be the preferred way to structure Android projects?
I don’t know if we’ll ever see MVP being the “preferred” way because everyone has their own opinions. If you want clean code you should use some design pattern, but a lot of developers have to move fast. They don’t care about the structure let alone the testing aspects. With that being said, Google has been pushing it in their dev summits and code labs so I expect its usage to increase for sure.
Whats next?
Just me again, no more bold questions now. If you liked this please give it a recommend so more people know the joys of #theRealMVP. Also please notice that I didn’t say any of the smart stuff, so please give John Shelley a follow and tweet at him, @jpshells, if you have anymore questions, or just want to tell him he’s really smart.
I’ll keep working on that FIRE project, though sadly it might not be out before spring. In the meantime, I have actually been doing allot of iOS stuff and decided to use an iPhone 5 for the whole month of December. Since then, I decided a post about iOS UX vs Android UX and Branding vs Platform norms for multi-platform apps might be a good next post. (Where do tabs even go these days, top or bottom?)
Thanks for reading!
Hope you all had a great Holliday season!
Edit: Example Code!
I finally got around to making a project of my own using #theRealMVP! Feel free to look over this project and let me know what you think! I’ll publishing a full post on it here in a few days.
Keep On Learning
#devPunk
