After writing my greatest practices article about VIPER, I’ve made just a few modifications to the codebase. I used to be taking part in with these concepts in my thoughts already, however by no means had sufficient time to implement them correctly. Let’s me present you the modifications…
VIPER protocols
My generic problem was that I wished to have a widespread interface for each single module part. That is why I created easy protocols for the next:
- View
- Interactor
- Presenter
- Entity
- Router
- Module
This fashion for instance my router objects are implementing the Router protocol, so if I make an extension on it, each single one could have that exact performance. It is a fairly small, however very nice addition that makes my modules far more highly effective than they had been earlier than. Truthfully talking I ought to have had this from the very starting, however anyway to any extent further it is gona be like this. 😬
This transfer implied to prepare my VIPER protocols right into a customized framework, so I made one, with these elements. You could find it on GitHub, it is a actually fundamental one, be happy to make use of it, you simply need to import VIPER in your venture.
Module protocols
Since I used to be utilizing VIPER it had this nice urge to implement a customized module for presenting system default alert messages on iOS. You realize UIAlertController is the one I am speaking about. Truly Robi (my true metallic pal) advised a surprisingly good normal resolution for the issue. His concept appeared like this:
Why do not we create a protocol for the router, so we might implement this on each different router, additionally we might merely name present(alert:) on them?
I beloved this method, so we have constructed it. Turned out, it is freakin superior. So we launched a brand new protocol for the module router, applied a default protocol extension and voilà routers at the moment are able to presenting error messages.
Notice that you should utilize the identical sample for plenty of different (related) issues as properly. The fundamental implementation seems like this one beneath, I hope you get the thought. 💡
import VIPER
class AlertModule: Module {
}
protocol AlertModuleRouter: class {
func present(alert: AlertEntity)
}
extension AlertModuleRouter the place Self: Router {
func present(alert: AlertEntity) {
}
}
protocol MyModuleRouter: Router, AlertModuleRouter {
}In fact this method can work for different VIPER elements as properly, it is fairly straightforward to implment and the protocol oriented method offers us an enormous win. 🏆
Presenter to presenter interactions
I additionally modified my thoughts in regards to the place of the delegate implementations taking part within the module communication circulate. In my final article I advised you that I am storing the delegate on the router, however in a while I noticed that delegation is generally associated to enterprise logic, so I merely moved them to the presenter layer. Sorry about this. 🤷♂️
import VIPER
protocol AModulePresenterDelegate {
func didDoSomething()
}
class AModule: Module {
func construct(with delegate: AModulePresenterDelegate? = nil) -> UIViewController {
presenter.delegate = delegate
return view
}
}
class AModulePresenter: Presenter {
func someAction() {
self.delegate?.didDoSomething()
self.router?.dismiss()
}
}
class BModulePresenter: Presenter, AModulePresenterDelegate {
func didDoSomething() {
print("Good day from module A!")
}
}This fashion you’ll be able to skip your complete router layer, plus all of the enterprise associated logic can be applied within the presenter layer, which needs to be the one solution to go. 🤪
Entities are right here to remain
Aside from the service layer generally it is fairly helpful to have an entity wrapper with some extra metadata for the mannequin objects. That is why I additionally made an Entity protocol, and began to make use of it in my modules. For instance an internet view module that may open a hyperlink can have a WebViewEntity with a title and a content material URL property. 😅
import VIPER
struct AlertEntity: Entity {
let title: String
let message: String
}The pattern alert module from above can use an AlertEntity with some properties that may outline the title, message or the buttons. This fashion you do not actually have to consider the place to place these objects, as a result of these are the actual VIPER entities.
IO protocols
It is a WIP (work-in-progress) concept that I might wish to check out, however the fundamental idea is considerably like that I need to separate enter and output protocols for VIPER module layers. Additionally this IO differentiation will be mirrored on the service layers too (perhaps the entire object “mess” from the service layer goes for use as IO entities sooner or later), by mess I imply that there will be method too many objects within the Service/Objects listing, so which means that these might be additionally grouped by modules (aka. entities).
Anyway, I am considering of one thing like RequestEntity, ResponseEntity for service communication, and for the VIPER layer communication I might think about two separate protocols, e.g. PresenterInput, PresenterOutput. We’ll see, however at first sight, it is looks as if fairly an over-engineered factor (hahaha, says the VIPER advocate 😂).
VIPER vs [put your architecture name here]
No! Please do not suppose that x is best than y. Architectures and design patterns are easy instruments that may be utilized to make your life simpler. If you happen to do not like x, it’s best to attempt y, however you shouldn’t blame x, simply because that is your private opinion.
My present favourite structure is VIPER, so what? Perhaps in a 12 months or two I am going to go loopy in love with reactive programming. Does it actually issues? I do not suppose so. I’ve discovered and tried so many issues through the previous, that I can not even keep in mind. 🧠
I am additionally always attempting to determine new issues, as you’ll be able to see this entire sequence of articles about VIPER is the results of my studying progress & experiences. If you happen to actually need to grasp one thing, it’s best to apply, analysis and check out rather a lot, and most significantly be pleased with your successes and keep humble on the identical time. 🙏
That is it in regards to the VIPER structure for some time. I hope you loved studying the entire sequence. When you have any questions, be happy to ask me by means of Twitter. 💭