Snakes , Snakes and more Snakes: An Overview of VIPER.
We’ve had Anaconda(the movie), the black Mamba( RIP Kobe), python the programming language and now we add another slivering creature to the line-up: VIPER.
We’re not actually talking about the animal Viper as in the one in this article’s headline picture. We’re talking about VIPER ,the design architecture commonly used in building mobile apps. From here on out I will be talking about VIPER in context of building mobile apps in swift.
VIPER isn't just a cool name someone decided to give to a design pattern. It ‘s actually an acronym arrange in a cool way to sound like the animal of the same name.
V — View : As the name suggest, the View is the file that will handle all the UI elements/interactions and will relay those interactions to the presenter. Think of the view as the face of the application / what the user sees.
I — Interactor : This file is used to fetch data. All network calls will be held here.
P — Presenter : The middle-man in all of this, the Presenter is in contact with the View. The Presenter receives user interactions from the View and performs its logic. Lastly, the Presenter prepares content to be displayed on the View which comes from the Interactor.
E — Entity : The Entity is a basic data model that holds the data fetched from the Interactor. Usually, it is defined in the Interactor file itself.
R — Router : This file handles the application’s navigation and what Views are shown and hidden. Think of this as the the Air traffic controller for an App.
Above i called the Presenter the middle man, but its more like the MVP. It is the busiest file because it is the only file that interacts with all the other files!
Let’s take a look at the many interactions that the Presenter has.
View to Presenter — Communicates user interaction and request the Presenter to perform the appropriate action.
Presenter to Interactor — Communicates the user action/data fetching actions.
Interactor to Presenter — Communicates the update with the business logic as a result of an action performed.
Presenter to View — Updates the View to make the mandatory UI changes based on the response from the Interactor.
Presenter to Router — Interacts with Router about navigation between pages.
Let’s take a look at some of the advantages of this design pattern.
Separation of Concerns: Because VIPER separates specific logic into 5 files, a file is only responsible for ONE specific task.
Easier to test code logic because of the “single responsibility” nature of the design pattern.
Also easier to to spot and resolve bugs because of the reasons listed above.
Now, VIPER is like a double edged sword. All the advantages mentioned above can easily be flipped around as disadvantages.
Separation of Concerns: Because there are specific files its can be really confusing adhering to proper VIPER principles. For example, all routing must be handled by the Router. Therefore, your actions have to travel all the way from the View to the Router. That can be problematic for those who are more used to MVC architecture.
