
Member-only story
Architecting with VIPER — The paper of the View in a VIPER scene
I started to play with VIPER around 2 years ago. At first it was a little confusing what each element of that architecture was responsible for. And in fact distribute responsibilities is one of the main keys of VIPER. This post brings a little of my thoughts around the responsibilities of the View. Also, I decided to expose some practical questions, which means applying VIPER in real world situations. I find this type of approach more helpful than just abstract discussions.
According to a post co-written by Jeff Gilbert, the creator of VIPER, the View (1) is the component that display what is told by the Presenter and (2) relays user input back to the Presenter. This gives us a base to start working on what is the actual View’s job. Let’s start with the user inputs.
User inputs
The view is the one responsible to deal with the user inputs. The simplest example that can be imagined is a tap in a button. Whenever that button is pressed, is the view that will be first notified. And then the view will inform the presenter about that event, without any filter, without any condition. The presenter is the one that will decide what will happen after.