MVP It was!
Few years back, MVP was considered as the next big thing as it started to trend more as compared MVC which was widely used at that time. A slight modification in MVC worked wonders for mobile developers, hence MVP was established. Below figure  represents that difference. Initially input was directly handled by controller and which used to manage all the views and each view had a reference of required model. MVP made it easier by replacing controller with presenter and for each view, there will be a unique presenter that will be responsible to engage model if required, and handle all the processing logic.
Fig  MVC & MVP – The Difference
What happened to MVP
With MVP, application will have multiple axis for each screen or UI window. For instance, Login Screen will have its own View, Presenter and Model. Similarly for all modules, there will be a separate axis for each module. For large scale applications, this will increase the amount of complexity and over-complicate it horribly. That happens because presenter has to handle UI Events, UI logic, business logic, networking and database queries.
Another one, which is a big challenge as it removes the ability to manage states in ASP.Net applications. How do you access context-specific information if presenters can’t have a reference to anything downstream (No cache and No use of session) . Now how can VIPER help us to remove these deficiencies? Lets see!
What is VIPER
VIPER stands for View Interactor Presenter Entity Router, which are classes that have a well defined responsibility, following the Single Responsibility Principle.
Taking off some work from presenter, adding couple of layers to handle responsibilities from presenter was the idea. Let UI event handling be catered by presenter along with data representation coming from interactor which is only focused on business logic and fetching data from DB’s or API’s. The other layer is router which is only focused on performing navigation. Fig  represent how these classes would interact.
Fig  How Classes Interact
VIPER It Is
Let’s put all the logic and stuff in some piece of code. I ll be using Movie DB API to fetch a list of movies currently playing and showing it in an expandable recycler view. API is open source, you can find it here. This would also require an API key which will delivered after requesting Movie DB. Fig  and Fig  shows how output will look like.
Fig and Fig  Output Shown on Device
Main Activity (View-IPER)
Fig  shows methods that are used to display items in expandable recycler view. Main activity keeps a reference of Presenter that will be used to attach main activity. All UI events will be passed to Presenter and all UI representation will be made here in main activity. Fig  shows interface methods that are declared.
Fig  Main Activity Methods
All interfaces for complete main screen are defined in MainContract. This interface includes other methods that are of utility purpose like RequestCallbacks or MainInteractorOutput. Moving forward, we ‘ll be referring this contract class methods used VIPER classes. Fig  indicates how View will coordinate with Presenter only so now let’s see what’s happening in Presenter.
Fig  Main Interface for all VIPER Classes
Main Presenter (VI-Presenter-ER)
Presenter takes events from View and handles it with assistance of Interactor. Presenter class contains reference of Interactor and Router class and initializes them in its constructor. Presenter will also listen for output of interactor in case there is some UI event to be thrown to View to render. Fig  shows how Main Presenter class looks like along with its methods.
Fig  Main Presenter Controlling and Passing UI Events to Interactor
Main Interactor (V-Interactor-PER)
As mentioned previously, Interactor is only responsible for business logic and fetching data from DB or API so this class will communicate with movie db server to fetch movie data using retrofit. In response there will be JSON result which will be set in recyclerview but displayed in View class. Fig  shows how Main Interactor is dealing with presenter class.
Fig  Main Interactor methods and members
Main Router (VIPE-Router)
Router is mainly used to perform navigation from one screen to another. This makes complex code more simpler to manage. Besides this, navigation is one thing which gets modified a lot whenever an application comes to a phase of scaling. Presenter normally keeps reference of router since navigation is, most of the cases, dependent on user interaction, whether a click on a button or any other action such completion of progress dialog. In our case there is not too much of code written in Main Router, only navigation to main poster, when clicked on any item of expandable recycler view. You can find all the code from here. Fig  shows Main Router class method representation.
Fig  Main Router class that navigates to Poster Detail Screen
Last but not the least is the simplest of all. We are all aware of models in MVC and MVP. Same applies here with a difference of terminology. In our case, models are dependant on API’s. Fig  shows how models are incorporated and mapped according to API. Interactors are normally contact point for entities. They communicate with each other as it can be seen here as well in Interactor class that we have a list of our model class which gets populated with the response from API.
Fig  Entity based on API from Movie DB
Having developed a project with VIPER and by helping team to develop a full VIPER Android project, I can safely say that the architecture does work on Android and it’s worth it. The classes become smaller and more maintainable. It also guides the development process, because the architecture makes it clear where the code should be written.
Here at VentureDive we are planning to use VIPER on most of the new projects, so we can have better maintainability and clearer code. Of course this is an evolving adaptation, so nothing here is carved in stone. We gladly appreciate some feedback about it!