Easy VIPER Architecture on Playground for busy people
You don’t have time, the iOS interview will be tomorrow or you need to deliver a new module. It’s fine, don’t panic 👍, here’s your boy Ulises ready to help you.
What’s VIPER and Why
It’s a set of layers that communicate data, it make projects stable and less stressful to work on by setting one responsibility to each layer.
There’s a ton of trash google VIPER arch images out there, ignore them and look at this one I made for you ❤ , it’s simpler and englobes everything.
💚 Green or dashed lines are layer outputs (handshake your friend and leave).
❤️ Red lines are layer inputs (handshake your friend and stay talking).
💙 Blue Squares, the layers (you and your friends).
This diagram will be important in the entire walkthrough of this post, you’ll see why…
The Code Plan
iOS Apps requires delegates and libraries to work, it uses “UIKit”, but to render at Playgrounds program, you also need “PlaygroundSupport”.
We will create a table with a list of activities to do if we are bored…
A protocol it’s basically a set of rules that the class will implement. Note the Output ones extends from “: class” . This instruction help us to make our output handshakes be dispatched by a “weak reference”, also, it will make each layer inmutable.
TL DR: Imagine if you don’t make a weak reference, it’s like keep handshaking with the entities as long as the app it’s running, even if you close the module 💀. The app will leak memory and maybe lead to a potential crash.
Presenter Layer
It’s like the brain of our bodies 🧠 for 2 reasons:
- - Receives inputs from view layer to fetch data (Interactor responsibility) or just go to other modules or services (Router responsibility).
- - Deliver outputs to view layer or make new request’s to router from fetched and treated data.
Our BussyPresenter class now can communicate with the Interactor and Router to make requests, or deliver stuff to the view with the presenter output weak reference.
The Interactor Layer
Imagine if you are asked to fetch only learning activities. ¿Where will you put that instructions?
Business logic goes to Interactor, mate. (Toby Maguire, 2003)
As our beloved 🕷 spiderman actor never said, logic requirement goes here, which allows to treat and the deliver the data to the brain of the module.
Note for more experienced readers: Yes, here we can add more complex layers like DataManagers, but that will be covered in other post😄.
View Layer
Since this layer it’s the responsable for render an UITableView, you may find complicated to understand at the start.
Look at the extension, there’s our presenter output refreshing the table with models that passed the Interactor-Presenter communication.
Also, look at the “viewDidLoad” function (which is triggered when your controller begin to work) how is requesting to the presenter to get the data source for our table, it looks so cool and on point of what the method and layer will do.
Router Layer
We’re almost done, the last layer it’s the responsible to make all the handshakes our module needs, also, it handle the route to other services like open a web page.
Remember, it can return the controller, but internally, every layer has now the communication of the diagram.
The Final Touch
The final touch are two lines of the PlaygroundSupport library that aids you to have a live preview and there’ you go.
Check it out the final implementation by clicking here. Copy and paste it in your Playgrounds program and have fun 🤘.
Remember, interactor handles the logic of how the data it’s delivered, so, you can play adding more rules or just pass all the data.
And that’s it folks, now, go and do some VIPER architecture 🐍 !
