VIPER Clean Architecture : Make App Easily Scalable

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 [1] 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 [1] 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 [2] represent how these classes would interact.

Fig [2] 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 [3] and Fig [4] shows how output will look like.

Fig[3] and Fig [4] Output Shown on Device

 

Main Activity (View-IPER)

Fig [5] 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 [6] shows interface methods that are declared.

 

Fig [5] 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 [2] indicates how View will coordinate with Presenter only so now let’s see what’s happening in Presenter.

 

Fig [6] 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 [7] shows how Main Presenter class looks like along with its methods.

 

Fig [7] 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 [8] shows how Main Interactor is dealing with presenter class.

 

Fig [8] 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 [9] shows Main Router class method representation.

 

Fig [9] Main Router class that navigates to Poster Detail Screen

 

Entities (VIPEntity-R)

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 [10] 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 [10] Entity based on API from Movie DB

 

Conclusion

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!

Leave a Reply

Your email address will not be published. Required fields are marked *