Straight to the point: VIP architectural pattern
As part of my Individual Development Program (IDP), I have been dedicated to studying the theory behind the knowledge I have gained throughout my career as an iOS developer. In search of theoretical foundation, I found an amazing book on LinkedIn shared by a colleague from the same Swift developers group I belong to.
In this article, I continue to explore the topic of the previously published article about the MVVM architectural pattern. Despite the similarity between the contents, it’s worth checking out for a detailed evaluation of other architectural patterns and my learning journey.
VIP
The View-Interactor-Presenter (VIP) pattern is a set of three design patterns that clearly define the role of each component in a software project. These components are the View, Interactor, and Presenter, and each has specific usage rules and context to ensure their exclusivity and functionality within the project.
The Interactor is the central element of the VIP architecture that manages View requests. It is responsible for obtaining the necessary data from the Database or Network and passing it to the Presenter. Additionally, the Interactor contains the business logic for each scene and communicates with one or more Workers/Services to obtain data requested by the View. To maintain communication between components, the Interactor keeps a strong reference to the Presenter. Finally, the Interactor must adhere to the protocol defined by the View to send events.
In the Clean architecture, Workers/Services/Entities are represented by Use Cases (Domain), Repositories (Data), and Data Sources (Networking and Storage). Generally, the group consists of objects that parse information, extensions, constants, and helper classes, and these objects can communicate with each other.
On the other hand, the View is composed of interface elements that are visible to the user, such as classes included in the UIKit library. The View is responsible for displaying Model data, obtaining it through communication via the Presenter’s Delegate.
The role of the Presenter is to receive information from the Interactor and transform it into a ViewModel* suitable for representation by the View. The Presenter is composed of presentation and data transformation logic. Additionally, there is a weak reference to the View, which serves as the Presenter’s output. Finally, the Presenter is responsible for translating the results from the Interactor into objects that can be rendered by the View.
To maintain the implementation of the View, Presenter, and Interactor design patterns organized, the author established a set of protocols and objects. In the case of objects, I have supplemented what was presented by him during the VIP discussion, as I consider it makes the implementation more consistent.
Protocols
- InteractorInput (View -> Interactor);
- PresenterInput (Interactor -> Presenter);
- PresenterOutput (Presenter -> View);
Objects
- Resquest (View -> Interactor);
- Response (Interactor -> Presenter);
- ViewModel* (Presenter -> View).
*ViewModel: is used to represent a unique Model to be used by the View. It has no relationship with the MVVM architectural pattern.
Implementation
After absorbing the knowledge acquired through reading the recommended book and applying the development techniques I use in my projects, I have developed an implementation model that fits my reality. In this article, I will share a specific example of implementation of the Interactor, Presenter, and integration with the View, highlighting the techniques and resources I have used.
I would like to share that I have no previous experience with VIP. If there is any missing or incorrect information, please leave it in the comments so that I can correct it.
Scene Model
View
Interactor
Presenter
Thank you for reading this far!
If you would like to contribute so that I can continue producing more technical content, please feel free to buy me a coffee ☕️ through the Buy me a Coffee platform.
Your support is essential to maintain my work and contribute to the development community.
