Practically it is not feasible to summaries the MVP pattern here in few lines. But I can assure you that every single line of the following article worth your time. I bet it will give you enough understanding that you can implement it on your own. And still, if you are in a hurry I would suggest jumping at “How does MVP works?” section. Source code of the example.
Whenever any Android developer starts thinking of improving technical skills, the first thing that comes to his or her mind is the Architecture of the App. Not to mention that they already know the pain involved in maintaining the standard code-base after it grows.
I did the same and learned about architectures and later chosen to focus on MVP. After trying it with test projects and later production apps, I moved to learn Kotlin language, and now the latest Architecture Components. But during this transition, I realized that there are very few to none; examples showcasing the implementation of these concepts in Kotlin. So, here I am with these examples showing the implementation of some architectural patterns in Kotlin. I promise you that these examples are gonna be so simple that you can grasp the core of these concepts with ease.
In this series I will target two main architectural patterns: Model -View-Presenter & Android Architecture Components.
1. Android App Architectures: MVP Example With Kotlin (This)
2. Android Architecture Components Example With Kotlin
3. Android Architecture Components: Advancements
Model-View-Presenter (MVP) with Kotlin
While designing the architecture of any software the basic principle to keep in mind is the separation on concerns. MVP is one of the best pattern to separate presentation layer from the business logic. Moreover MVP also helps you easily implement more advanced, complete architecture patterns like Clean Architecture.
Here I am not gonna answer questions like WHAT and WHY but HOW.
How to use MVP? How does it work? and How to implement it using Kotlin?
So in this 1st article we will see the implementation of MVP using Kotlin.
Who: Combination Activity/Fragment/View and its contract i.e. interface.
Purpose: Do all UI related stuff and all that needs Android context.
Job: Whenever it needs to do some action, it should trigger respective function of Presenter using object. It should not have any business logic.
Though the XML layout is part of the view, it is not alone called as View. All necessary functions are added to our Activity/Fragment/View via contract/interface. Adapters are also the part of the View. Activity/Fragment/View directly initializes Presenter including Model indirectly as Presenter initializes Model in its constructor.
- Show/hide progress bar.
- Request data to be shown and later show received data/error.
- Get LayoutInflater, Resources, Android System Services.
Who: It is a separate class which should not have Android context.
Purpose: Act as a mediator between two main layers of the architecture View and Model.
Job: Trigger respective function of Model depending on the request made by View.
Presenter has the objects of View and Model. It should not have any business logic. Moreover, it should not have direct access to any UI elements.
Who: Database, models (schema), API calls and all other business logic is part of this layer. This is where all business logic will be located.
Purpose: To separate business logic so we can test it in isolation without View. This also helps us to reuse code-base across platforms.
Job: Get/calculate data or error to shown on the UI.
This is where we should make API, Database calls, and other calculations.
But to make it more solid, we can add one more layer inside Model:
Decides the source of the data to be shown depending on the predefined conditions. It means it will get the data from offline or online sources depending on the conditions like network availability.
(To keep things simple, the included app does not have repository layer.)
This way our Model will get the data to be shown irrespective of the network conditions.
Recently, I have published an article on Coroutines, check out-
In brief words: View calls functions of Presenter, Presenter transfers it to Model, Model requests the data to be shown. After Model gets the data, it passes it to Presenter and Presenter passes it to View where View shows that data on the screen.
Direct Communication of:
View ==> Presenter ==> Model
Indirect Communication using contract/interface:
Model =/=> Presenter =/=> View
Here is the simple workflow diagram of MVP in Android. I request all to spend a few minutes with the following illustration, it will help you a lot to understand MVP in Android.
Note: Model is referred to as Interactor.
I hope I was clear enough to make this understandable.
Here is the complete source code of the example.
Thanks for reading!
If you liked the article, clap clap clap 👏👏👏 as many times as you can.
LIKED SO MUCH! Medium allows up to 50 claps.
Also post a Tweet on Twitter.
Create your free account to unlock your custom reading experience.