MVP Redefined ~ The Modular design [Part2]
Hello folks, thanks for coming back for the second part, you might have come here only if you liked previous article and you are excited to look more inside it. Ok, so what I will be covering in this part is modularizing your code to take more advantages. And speaking of an advantage, we will make it reusable, for this and your future projects.
We just implemented app with MVP using firebase as a backend. Now I come up with an idea of giving a wearable support for my app. ( ‘I’ is client for clarity… Haha, I am not kidding, right? ).
Ok, we will start adding a wear module and then login module in it…… Ohh! WAIT, why I am doing same thing I did for app module? Why shouldn’t I reuse the core part and complete the task before time and gain profit!!
Yes it is possible, but it needs some modification to our project. Let’s first identify parts of project which can be defined inside the reusable components.
1. All classes from utils package
2. All base classes, including base mvp interfaces
3. All controller classes, well they are independent.
4. All gradle dependency, only the common ones.
It will look something like this =>
A good practice is to manage versions like buildVersion, supportLibVersion etc. in project level gradle, to make it consistence in all modules of your project.
A good practice is to manage versions like buildVersion, supportLibVersion etc. in project level gradle, to make it consistence in all modules of your project.
So let’s add a module named commonmvp. It’s for better understanding, you may name it as your choice. And then add it as a module dependency to both ‘app’ and ‘wear’ modules.
Now if you see ( If you can 😉 ) the core part of your app is going to be managed separately without getting any interference in main modules of your project. Now I defined all required activities to be implemented for wear module (Won’t mention here, you have to look in the code) and deliver the product without that much overhead, adding separation of concerns, make it modular and simplified in terms of adding your functionality.
For Testability of code, as you can see, our common module is managing all controllers, which actually works like repository to other part of code. So that can be tested and mocked easily with any testing approach of your choice.
Towards concluding this part, I enjoyed to make this work for me, hope same for you, too. As I had mentioned in first part, that there is nothing right or wrong in design patters, you may alter it in your own way.
Recent trend shows that MVVM is being a popular one for specifically android project structure, Google also introduced Architecture components at I/O 2017, which is also making me thinking of implementing ViewModel approach.
So, I will leave you guys here to play and tweak your code and give me any useful suggestion or improvement. Meanwhile, I want to dive into arch-components and Kotlin, yes #kotlin is nowadays trending around different communities around the world…
The complete code can be found on Github.
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:
