MVP Redefined ~ A Reusable Base [Part1]
You might have come across different architecture/design patterns and advantages of using it. Yes, there are. But when it comes to implementing them, in a considerably large project and you also need to take care of given tight timeline, I guess, you might say: “Ahhh.., not possible, will see that later !!”
In general, speaking of mobile application development with android, there are three major patterns are put in practice: MVC, MVP and MVVM. You may find many articles and tutorials to implement them in a pure format, still there is no thumb rule defined for which should be used and in which pattern, it may vary with many underlying factors of a project.
Never think what you are implementing is correct or wrong way, you can alter it as per you need and convenience
I am going to discuss about specifically on MVP pattern, BUT in my own defined way with considering below points :-
✔ Development speed
✔ Coding overhead
✔ Defining Independent modules
✔ Focus more on defining logic rather than structure
✔ Reusability of base structure
OK, enough TALKING. Let’s dive into it. I shall be using below tools & technologies for making a better demo
📐 MVP architecture pattern
📐 Data Binding
📐 Firebase (As back-end)
📐 Wear support (To understand module support)
If you don’t know data binding, you may go to my blog series here:
If you don’t know MVP patterns, just take a look at this for basic understanding.
For a fresh start let me show you diagram below, which explains a pure implementation of MVP.
Main focus is on the controller part which allows us to separate business logic with better testability. As you will go through examples of MVP, you may see many classes & interfaces to be created for just a single module of your project, let’s take example of login module.
Below is project structure for only login and signup module implemented with pure mvp pattern:-
Not saying that, But yes that will make you uncomfortable while using it for entire project. Also it will make difficult to handle that many files, even with working in a team you need to take care of many things as well. So what if we can reduce this overhead and make it simple.
Hmmm, looks better but what happened inside of it? Use of Contractor class will allow you to bind mvp interfaces at a single place. Let’s see what is inside of it.
Don’t look at generic part for now. WHAT NO! , it’s important actually :P . So to understand it, Let’s first take a look into base mvp package:
1. View
2. Presenter
3.Callback (Controller Interface)
The base package will contain interfaces which will define very common methods that are generally used in a typical android application. BaseView will have methods for views e.g. showing and hiding progress, BasePresenter will have methods connecting with controllers with passing the ICallback instance (Which is also going to be generic type). You don’t need interface for controllers which can be created as per need later on.
So why the generic type? See BaseView class. My concern was to make it simpler when binding views to activity or fragment, I hope you might have looked into data binding. It will allow to define generic way to access binding. It’s also useful when controller returns the result, you might don’t want to define different callback interfaces for each result models. OK don’t find it complex it will be useful when you actually implement it.
The main purpose behind the abstract methods was to make all part of your class in defined structure, only make required calls and pass everything to controller via presenter. E.g. See initView(). This method is taking only resource id as argument, doing binding stuff in the base class and provides a binging object which can be accessed via getBinding() inside your class. Generic type comes into the picture now to allow dynamic nature of your implementation here.
Let’s see how login flow will look like. A Contractor class has interfaces for MVP part of give module, A LoginActivity for user interaction, LoginPresenter for communication and LoginInteractor for actual login call to server, here we are going to use Firebase Authentication.
On other hand in the HomeActivity, list of items are being fetched from firebase database where a helper interface IFirebaseCallback allows controller to pass data via it to the view. Due to the realtime nature of firebase, data will get reflected in UI with no more efforts.
Code is available on Github. But yes, as I had mentioned before that I will be dividing the project in modules to provide a broader perspective of applying design pattern what I have tried, so look into the ides, and move to the second part as and when you are READY!!.
Add comments if you don’t get any part of it OR you have any suggestions, Keep Learning 👍
If you enjoy reading you can also visit my other blog posts:
