Home
MERLin' is a reactive framework that aims to simplify the adoption of an event-driven architecture within an iOS app. It emphasises the concept of modularity, promoting an easy to implement communication channel to deliver events from producers to listeners.
If you are not new to iOS development, you know how important is to correctly decouple app components for testability and overall flexibility. Each feature should work independently from the others. Ideally, each feature should be easily replaceable with another component providing the same functionality. To achieve this result we embrace protocol oriented development and dependency injection. Most importantly, we formally structure our apps following well-known architectural design patterns.
In an events-driven architecture it is important to have a solid events structure and a solid event dispatch mechanism. In iOS, unfortunately, none of this is available out-of-the-box. The only out-of-the-box events dispatch mechanism available to devs is the NotificationCenter that lacks in type safety and events are basically strings.
MERLin uses RxSwift to establish a communication channel between producers and listeners.
In MERLin a Module is a framework that exposes a specific functionality; an app feature. It’s independent or it has very limited dependencies, It should not know about other modules and does not expose implementation details. Any module can be a producer of events of a specific type and it must be contextualised (it needs a context to be built).
An Event is a message sent by a system to notify of a change happened in its domain. They are named and unique within the same system domain and can have payloads describing the change that happened in the domain.
Different systems offering the same service will emit the same events.
In MERLin, Modules can be events producer and emit events to signal a change of state or that an action was started/finished.
In MERLin, events are enums conforming the EventProtocol protocol.
Some events might cause routing to another module of the app. The Router is the object that makes the connection possible in terms of UI.
In an event-driven architecture, events consumer are listening for events coming from events producers.
In MERLin an events consumer is called Events Listener.
An events listener reacts to a module’s events; It can listen to specific types of events, or to any event. Some events listener can produce routing, in that case, we will call them Routing Events Listeners. These special listeners have a router to make routing to new modules possible.
Each listener should have only one responsibility. There is no limit to the number of listeners that can be listening to a specific module event channel, so it is possible to have a specific listener for each analytics provider, for each module.
I must say that all of this was not possible without my team. They gave me trust, patience, they helped me identifying weak spots in this framework, repetitive tasks and gave me crucial feedbacks and suggestions to take MERLin' at today's state. I've been very lucky as each one of my team members if they spot a problem usually present it along with a possible solution, rather than just complain about it. This attitude made the Team Gaudì the best team I've worked with.
I started MERLin' alone, I might have written most of the code but really, it's teamwork.
Chris La Pat, Fabio Felici, Nikita Korchagin, Niloy Chakraborty (in alphabetic order), thank you.