Another architecture?

In recent years, the topic of alternative architectures for creating applications for the iOS platform has noticeably gained momentum. Some strongmen, known as MVP, MVVM, VIPER, are already entrenched on the special honor board. And besides them there are many others, not so common.

Among the strong men, in my opinion, none is a universal pill for all cases:

• if you need to make a couple of small screens with a static data set, then it is quite expensive to enter a full-fledged VIPER;
• if you do not like the reactive approach, then MVVM is more likely to pass by;
• If you run into a Massive problem in a large project, then MVC is no longer suitable.

There is an option to use several architectures, because many allow you to combine yourself with others to varying degrees, but this is also not very convenient for at least three reasons:

• as the module grows, it may be necessary to convert it into another architecture;
• when making changes to the module, you must first figure out what architecture is used for it, and how exactly the changes should be made there;
• the need to add a code adapter in order to share modules of different architectures, because from scratch the code is unlikely to be native for both of them at the same time.

And so, having encountered a lot of projects over the past four years (several projects from the banking sector, several heterogeneous custom projects, as well as several of my own - both applications and games), I formed an architectural approach for myself, which I now try to use as much as possible in Any project that I start.

So far, he did not let me down. At the same time, I do not think that I am a pioneer: for sure, many already use a similar approach. But since in the projects that I personally encountered, architecture was rather difficult, I wanted to share my thoughts.

SILVER in brief

In my formation of this version of the architecture, several key aspects were taken into account:

• it is necessary to apply it equally simply for both simple modules and complex ones;
• you must have the opportunity for wide coverage tests, if any;
• View may be partly active and able to communicate with complex logic, but should not contain its implementation within itself;
• in order not to produce entities in Interactor for the sake of their existence, View, if necessary, can communicate directly with services — logic that is not tied to a specific module;
• over the life cycle of the iOS UI, the central link is the ViewController (View) , which should be used to simplify memory management.

Eventually:

• View allows itself to be a thin controller, communicating as needed with an Interactor , Router and other services;
• dependencies are registered through ServiceLocator ;
• communication with the module from the outside occurs through the Router , but memory management is based on its View .

The main parts of the architecture:

• each module is at the top level of Interactor , Router , View ;
• data for storage and processing represent a separate common layer of Entity ;
• dependencies go via ServiceLocator .

I conditionally call it SILVER : by the first letters.

SILVER by example

We will collect a small illustrative application that will keep a list of countries and cities, which we ourselves will recall, hoping for our own knowledge of geography.

First, let's take a look at the public presentation of any module. In this phrase, the module represents a collective image that can be controlled, and the state of which can be displayed on the screen. So, in any module there are two public parts:

• Router , which allows you to control the module and interact with other modules;
• ViewController , which allows you to display a visual representation of the module.

protocol IBaseRouter: class { var viewController: UIViewController { get } } struct Module<RT> { let router: RT let viewController: UIViewController } 

Here a question may appear why I repeated the ViewController in a separate property of the structure, if they are so connected.

The reason lies in the fact that in order to ensure the most simple memory management, the emphasis is shifted to the fact that the ViewController has strong connections with the rest of the module: when you return back from the current screen, the ViewController is removed from the UIKit hierarchy, and with it comfortably dies whole module.

For the same reason, from the parent module, connections with child Routers are made weak, if they are needed at all.

So, in order not to clog the memory, the ViewController is created for the first time only at the moment when it is accessed. And so it turns out that in order for a viable module to appear, you need to refer to its ViewController . However, to be able to get control, you need to communicate with its Router .

If you get a Router from the module factory, then we will not have a strong link to the module, and it will be destroyed on the next line of code. And if you get a ViewController from the factory, then we will not have the ability to control and configure the module.

This problem is solved by the Module structure, which is filled at the time of the module creation, and allows you to temporarily hold both strong links at once - to Router and to ViewController . As a result, as long as the structure is alive in the local scope, Router can be saved to a weak link, and the ViewController display on the screen where UIKit will hold a strong link to it.

 func InputModuleAssembly(title: String, placeholder: String, doneButton: String) -> Module<IInputRouter> { let router = InputRouter(title: title, placeholder: placeholder, doneButton: doneButton) return Module<IInputRouter>(router: router, viewController: router.viewController) } 

 private func presentCountryInput() { let module = InputModuleAssembly(title: "Add city", placeholder: "Country", doneButton: "Next") self.countryInputRouter = module.router module.router.configure( doneHandler: { [unowned self] country in self.interactor.setCountry(country) self.presentNameInput() } ) internalViewController?.viewControllers = [module.viewController] } 

In general, Router is needed in order to:

• accept incoming parameters required to configure the module (more often - through the constructor);
• take the necessary callback, with which the module can report that the user has performed some actions;
• arrange for receiving a ViewController ;
• store Router child modules, if such are useful.

 protocol IInputRouter: IBaseRouter { func configure(doneHandler: @escaping (String) -> ()) } final class InputRouter: IInputRouter { private let title: String private let placeholder: String private let doneButton: String let interactor: IInputInteractor private weak var internalViewController: IInputViewController? init(title: String, placeholder: String, doneButton: String) { self.title = title self.placeholder = placeholder self.doneButton = doneButton interactor = InputInteractor() } var viewController: UIViewController { if let _ = internalViewController { return internalViewController as! UIViewController } else { let vc = InputViewController(title: title, placeholder: placeholder, doneButton: doneButton) vc.router = self vc.interactor = interactor internalViewController = vc interactor.view = vc return vc } } func configure(doneHandler: @escaping (String) -> ()) { internalViewController?.doneHandler = doneHandler } } 

In case several actions can be performed in a module, the configuration method can contain all possible callbacks. This will allow in case of adding new callbacks in the development process not to forget to register their call, too.

 //      callback, //     , //        . func configure(cancelHandler: @escaping () -> (), doneHandler: @escaping (String) -> ()) //       callback    , //      . func configure(cancelHandler: @escaping () -> ()) func configure(doneHandler: @escaping (String) -> ()) 

In exactly the same way, in the form of a stored module, the start of the application itself can be represented, which is obtained in this way quite concise:

 class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? private weak var rootRouter: IRootRouter! func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool { let window = UIWindow(frame: UIScreen.main.bounds) self.window = window let module = RootModuleAssembly(window: window) rootRouter = module.router window.rootViewController = module.viewController window.makeKeyAndVisible() return true } } 

Dependencies come from the ServiceLocator , which is configured in the RootRouter (although, for the purity of logic, it may be worthwhile to transfer it to the RootInteractor ), and there are two main nuances associated with it:

• it is created in the Root module;
• preparation of services for reuse occurs within itself.

In the framework of SILVER, it is assumed that the Root module is always there, because as part of its responsibility at least:

• switching root screens depending on the state of the application;
• Registration ServiceLocator .

 struct ServiceLocator { let geoStorage: IGeoStorageService func prepareInjections() { prepareInjection(geoStorage) } } func inject<T>() -> T! { let key = String(describing: T.self) return injections[key] as? T } fileprivate func prepareInjection<T: Any>(_ injection: T) { let key = String(describing: T.self) injections[key] = injection } 

 final class RootRouter: IRootRouter { // ... init(window: UIWindow) { let serviceLocator = ServiceLocator( geoStorage: GeoStorageService() ) serviceLocator.prepareInjections() } // ... } 

 final class ListInteractor: IListInteractor { // ... private lazy var geoStorageService: IGeoStorageService = inject() // pretty easy! // ... } 

View the demo project on GitHub