VIPER: The clean code architecture

Software Development Architecture(or Design Patterns) is very crucial and one of the very essential & initial steps that ‘one’ has to decide about and take (Here the ‘one’ is referred to a Software Developer 😐😐, a God’s creation that can convert Coffee to Software). Following a Design Pattern while developing a software is very important (When I say this, believe me, I have met some who don’t even know what is Design Pattern but have their apps in App Store. 😶) as it’s not only just a folder structure but much more than that…. To me, when you say you followed a particular architecture you should know at least a few things:

1. You need to know how to define and divide each feature/functionality as a responsibility and assign these tasks to different parts(classes).
2. Stay aware of the proper communication flow between the classes you implement.
3. The code that you write after minutes or hours of thinking is maintainable and can be enhanced by any other ‘person’ (Here the ‘person’ is also a Software Developer).

Being an iOS Developer by profession, I tried out a very recent and famous architecture- VIPER.

VIPER, a design pattern used worldwide today, is one of the cleanest architecture you can refer to while working on a big project. Viper is a protocol-oriented programming along with a modular approach. All the modules are divided into 5 different parts(rather classes) and each has their responsibility. The classes are bound to perform only a particular task and pass on the desired outcome to other (if required).

The 5 different parts or classes in which you break down a module are:

1. View- View contains all your UI elements. Whenever a user interaction occurs, View has the responsibility to pass the information to Presenter.
2. Interactor- The Interactor is the brain of the module. It contains different business logic and uses case implementations.
3. Presenter- The presenter passes on the obtained data from View to Interactor for further processing as per business logic. After further processing, the Interactor passes the data to Presenter and then View to update UI. The presenter also interacts with Router to perform navigation.
4. Entity- Entity are the Data Models which have the natural tendency to be processed and updated as per the app flow. It’s actually the combined effect of the Data Model and View that is visible to the user as UI.
5. Router- The Router is responsible for all navigation-related tasks and passes on any data if required.

This breakdown of responsibilities is called Single Responsibility Principle. Because of this, its very easy to write test cases, unlike others architectures which contain everything like business logic, UI handling, navigation etc. in the same class.

The Communication Flow

The VIPER Flow(Single Responisibility Principle)

In the above image you can see Interactor communicates with two other types of Classes

1. API Data Manager
2. Local Data Manager

These are not other components, but helper methods of Interactor just to segregate the responsibilities more like API Data Manager for making API calls and Local Data Manager for handling data persistence.

Now by looking at the diagram you are pretty much clear about the flow. If not, let me clear it by an example. Suppose you are on the login screen. And after login is completed you have to show dashboard. So, for that, the flow would be something like this:

Login API Call flow diagram

I think the flow diagram is pretty much clear in terms of its purpose(If you still have any doubts, please reach out in Comments section and I will be at your service🙂🙂).

The VIPER Structure.

When I started writing this blog my main concern was to focus on the structure that I am following now(just curious to know whether what I am doing is good or not… with ready to accept any suggestion attitude😎😎).

I have uploaded a simple application in Viper architecture. The application demonstrates a Login Screen, Side Menu, Dashboard and Logout functionality. Here’s the link to the Github repository: https://github.com/manish-1612/ViperSampleApp

Further Reading…..

1. https://www.objc.io/issues/13-architecture/viper/
2. https://blog.mindorks.com/building-ios-app-with-viper-architecture-8109acc72227
3. https://medium.com/@ankoma22/the-good-the-bad-and-the-ugly-of-viper-architecture-for-ios-apps-7272001b5347

Upcoming

In the next blog, I will write about how to create your own Module Template to speed up the development process for a big project(for VIPER architecture).

If you like the blog, please don’t forget to clap. 😊😊😊😊😊