Yet another MVP article — Part 1: Let’s get to know the project

Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern methods and libraries

I found some unanswered questions about using MVP on StackOverflow which encouraged my strong interest to write a series of articles, providing a sample project (i.e a practical experiences of my own…)

Last year I get familiar with MVP, a tuxedo development, and looked at samples and tutorials. I spent a long time processing and connecting different parts of this unknown big puzzle. The most useful website which I can mention was caster.io which is always full of new Android video tutorials.

Explaining about MVP itself might look odd! cause there are many articles explaining how it works and how to break layers and so on, but there are few samples with enough comments which help newer in this methodology.

How change begins…

It all begins with SOLID (object-oriented design principles), thanks to dear Robert C. Martin.

according to the SOLID article on Wikipedia, it stands for:

- S (SRP): Single responsibility principle

- O (OCP): Open/closed principle

- L (LSP): Liskov substitution principle

- I (ISP): Interface segregation principle

- D (DIP): Dependency inversion principle

MVP somehow try to follow all the five principles. I would try my best to pinpoint one by one in my sample project to make it more transparent.

according to this perfect MVP article, it stands for:

- The Model is the data that will be displayed in the view (user interface).

- The View is an interface that displays data (the model) and routes user commands (events) to the Presenter to act upon that data. The view usually has a reference to its Presenter.

- The Presenter is the “middle-man” (played by the controller in MVC) and has references to both, view and model.

Model?!!!

Please note that the word “Model” is misleading!!!

It should rather be business logic that retrieves or manipulates a Model.

For instance: If you have a database storing User in a database table and your View wants to display a list of users, then the Presenter would have a reference to your database business logic (like a DAO) from where the Presenter will query a list of Users.

Would you explain a little more about MVP?

Noooooo!! just google and you will find all theories about this new method (or at least take a look at this article.)

What’s this sample project about?

This application is a Marvel’s characters searching app which is a simple Android client for the Marvel.com. This application was created by me, as a part of the technical assessment by the smava GmbH technical team.

Marvel Android Application screenshot

The app must search character, view information and cache last searches.

This project implemented using MVP and contains modern Android development concepts and libraries which can really change your professional life!

I will try my best to explain everything in different parts of this continues article namely: Dagger, Retrofit, RxJava, and Tests.

The project also had Continues Integration(CI) using Circleci.com & Travis-ci.org and code coverage reports using Codecov.io and also using google new Firebase service which you can study by yourself and it is off topic for this article somehow.

You can get more familiar with the project by reading README and Task files before getting start.

Okay, Show me what you got:

mohsenoid/marvel_marvel - Marvel Characters Android Application Assigned by smava GmbH_github.com

Let’s take a look at the project’s structure.

I personally enjoy working on a clean code, so I really enjoy breaking a project into some meaningful parts that help me and the whole team with keeping more clear with tasks.

Modules:

Project consist of two main and a java console sample modules:

1. app (marvel-app): Android Application module
2. core-lib (marvel-core): Core Library module
3. console (marvel-console): a java console sample module

The app module contains the Android View layer of MVP, while the other layers (Model & Presentation) are all placed in the core which is pure java and after compile it would be a jar library.

What’s the use of breaking code into modules?!

• First of all, separating the Android Application module reminds you that you should not pass Context or any Android related objects to Presenter or Model! …so please stop doing it!!!
• Secondly, you can make sure that the core part is that much complete that you can use it with even another UI (namely: Java Console sample, Web Applet or as a prediction even someday in near future an iOS app using java!!)
• Finally, I and our team really enjoy developing Applications like this! and whole team members benefit from having core apart, and even we put the core in a git submodule and use it in different projects with the same core and different UI.

The result of java console sample module which works the same as Android Application with the core

A little module’s name cleanup:

to make modules look more convenient and nice you can edit settings.gradle file like this:

which gives you this clean look:

and also cause a relevant name for output APK file.

How to avoid version conflicts and redundant in different modules?

using a Gradle feature could come handy for a clean build.gradle file and avoiding version conflicts and redundant in your project’s modules.

First of all, place all your project’s dependencies inside a Gradle file like libraries.gradle:

then add it to your project main build.gradle file (take care of the last line):

and finally, use it like a charm in your app module build.gradle file (take care of dependencies part):

and your core module build.gradle file:

What’s going on inside the core module?

core module’s files structure

• base package: holds all base interfaces which contain general methods for all Interactors, Presenters, and Views.
• character package: holding the main feature of the application which is searching and caching Marvel characters info.
• database package: Caching characters data is done using OrmLite in this sample which I will not explain too much about it, because it is off topic, but you can take your time looking all codes!
• domain package: contain codes to connect to network API using retrofit2 and RxJava library.
• util package: full of useful classes which are required for the project, namely: Constants which holds all core const variables, HashGenerator which is being used for Marvel’s API calls hash parameter and SchedulerProvider which is a Scheduler interface that helps with RxJava and RxAndroid multi-threading (I will explain more in this article’s relevant parts).

“You wouldn’t wire a lamp directly to your house”, — Novoda

Referencing to Dependency inversion principle of SOLID, “one should Depend upon Abstractions and Do not depend upon concretions” or reference to this fantastic article by Novoda “You wouldn’t wire a lamp directly to your house”!, all links between two modules (app & core) are implemented using interfaces and wired up with dagger.

, and what’s going on inside app module?

app module’s files structure

• activity package: holds 3 activities that are the back bone of the Android Application UI.
• base package: holds 2 base abstract classes of Activity and Fragment which contain general methods for injection and could be used for other general methods.
• character package: is holding the main feature of the application which has been implemented using two Search & Cache fragments.
• database package: contains Android-side database codes using OrmLite which is off topic!
• util package: full of useful Android-side classes which are required for the project, namely: AppConstants which extends core’s Constants class and contains Application const variables, AppSchedulerProvider which implement core’s SchedulerProvider and provides RxAndroid Schedulers, CustomBindingAdapter which helps with new Android DataBinding plugin for loading images using Picasso library and GridSpacingItemDecoration which helps with RecyclerView grid item spacing. (It was a brief information which I will explain more in this article’s relevant parts).

That’s it for now…

Please clone the project repo from GitHub and get more familiar with it because in next part I will explain more about dagger and how it helps with wiring up modules and layer’s different objects.

I look forward to your comments and helping for more improvements with this article.

Share this article if you think it is useful, and follow me for more articles Mohsen Mirhoseini.

To be continued…

Yet another MVP article — Part 2: How Dagger helps with the project_Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com