In Readme is written Coordinatable, the example Coordinator:

protocol Coordinatable: class { func start() func start(with option: DeepLinkOption?) }

correct it if mistake.

Андрей, приветствую!

Посмотрел Вашу версию реализации данного паттерна, все очень здорово, спасибо!

Однако, у меня есть 2 вопроса:

1. Почему за состояние авторизации пользователя в приложении отвечает ItemsListController? (собственно, свойство authCheck). Более того, переход к модулю авторизации происходит в переопределенном методе viewDidAppear (т.е. показали список айтемов на миллисеекунду, потом поняли, что "нет, чувак, ты не авторизован", и дернули опциональный метод authNeed). Я понимаю, что это пример, но все же (по моему скромному мнению) именно координатор отвечает за состояние приложения, причем конкретно за авторизацию - ApplicationCoordinator.

2. Утечки памяти. Собственно, на днях, в очередной раз рассматривая различные реализации сего паттерна, отметил для себя удивительную вещь: паттерн неимоверно увеличивает риск утечек памяти. В каждой реализации я видел утечки. Собственно, и у Вас тоже :) Пруф:

Последовательность была такая: Auth -> SignUp -> Terms -> Check -> SignUp -> Auth, и собственно, за 5 итераций убежало 2 МБ. Понятно, что 2 МБ при нынешних ресурсах - это ничто, но там и на экранах по одному UILabel, и будь это что-то посерьезнее, то утечки бы исчислялись уже в десятках, а потом и сотнях мегабайт.

Так вот, вопрос, как вы с этим справляетесь? - я не имею ввиду процесс оптимизации работы с памятью (с Instruments->Allocations наперевес) :) я имею ввиду, что ссылки на UINavigationController'ы захватываются всеми, кому не попадя, например, при прокидывании последнего во вложенные координаторы (2го, 3го порядка, и т.д.). Т.е. как правильно останавливать работу координатора, чтобы после этого не оставить нерелизнутые объекты?

Спасибо!

After I've played with this solution in local I've found that the TabbarCoordinator leaks because of the handler blocks. After I've found that the removeDependency only clears the top level parent if it has children.

ps.: Thanks for the opportunity to be my first pull-request ;)

@AndreyPanov

RouterMockImp does not confirm to protocol Router, so I implement setRootModule(_:hideBar:) and it pass the Test.

And your sample app is very helpful for me. Thank you.

Firstly definitely one of the best article series on Coordinator Pattern topic!

Secondly I have one question. Why does not the router maintain the navigationStack? I think if you keep the stack view you can test your RouterImp more easy.

• все взаимодействие через протоколы
• у координатора появился отдельный роутер
• фабрики помимо создания инжектят данные и возвращают tuple с нужными протоколами

If you summon a flow as a modal, and dismiss it by swiping down, the view and its corresponding coordinator remain in memory. In your app, if you click them + button to Create Item and then swipe down to dismiss that screen, instead of tapping "Hide", and do that several times, and then inspect the Object Graph, you'll see that you have multiple ItemCreateCoordinator/Controller/View open.

You have to adapt Route to UIAdaptivePresentationControllerDelegate somehow.

Kudos for putting together. (This is not an issue but a recommendation per say)

I think it would be useful if the following methods were part of Router's default implementation. It becomes vital when presenting new flows on top of existing flows.

func presentOnVisibleModule(_ module: Presentable?, animated: Bool) {
      guard let controller = module?.toPresent() else { return }
      rootController?.visibleViewController?.present(controller, animated: animated, completion: nil)
}
    
func dismissFromVisibleModule(animated: Bool) {
      rootController?.visibleViewController?.dismiss(animated: animated, completion: nil)
}

Hey! It seems that ApplicationCoordinator's func start(with option: DeepLinkOption?) is a source of memory leaks in case when we have some coordinators tree and some DeepLink action triggers this start function. No one child coordinator (and view controllers it holds) will be released, but the new ones will be created.

In your RouterImp, you store a Dictionary of completions with the ViewController as the key. I think that there is a potential leak here.

The leak will occur when you're using a Navigation Bar's back button instead of programmatically popping the view controller. The Router's dictionary still maintains a reference to the view controller because the back button is not hooked to the router.

Hi, I want to create a nice architecture for a project I'm working on and I found your example on the use of coordinators.

I just started as a Junior Developer and I have some questions if you have the time to answer them:

• Why not include in the BaseCoordinator the router, coordinatorFactory and moduleFactory as optionals? This way you can inherit them in all coordinators, use the ones you need and leave the others with nil value.

This is an example of the implementation I suggest:

Coordinator protocol:

protocol Coordinator: AnyObject {
    
    var router: Router? { get }
    var coordinatorFactory: CoordinatorFactory? { get }
    var moduleFactory: ModuleFactoryImp? { get }
    
    func start()
}

BaseCoordinator class:

class BaseCoordinator {
    
    private(set) var children: [Coordinator] = []
    
    var router: Router?
    var coordinatorFactory: CoordinatorFactory?
    var moduleFactory: ModuleFactory?
    
    init(router: Router?, coordinatorFactory: CoordinatorFactoryImp?, moduleFactory: ModuleFactoryImp?) {
        self.router = router
        self.coordinatorFactory = coordinatorFactory
        self.moduleFactory = moduleFactory
    }

    open func start() {
        fatalError("This function must be overriden")
    }
    
    final func add(child: Coordinator) {
        ... [Implementation]
    }
    
    final func remove(child: Coordinator) {
        ... [Implementation]
    }
}

Then, all coordinators would be simplified because they don't need initializers, they just inherit the one from Coordinator. Finally, an example on how to initialize a Coordinator from the CoordinatorFactory:

AuthCoordinator(router: router, coordinatorFactory: nil, moduleFactory: ModuleFactoryImp())

ItemCoordinator(router: router(navController), coordinatorFactory: CoordinatorFactoryImp(), moduleFactory: ModuleFactoryImp())

ItemCreateCoordinator(router: router, coordinatorFactory: nil, moduleFactory: ModuleFactoryImp())

For the special case of the TabBarCoordinator:

class TabbarCoordinator: BaseCoordinator {
  
  private let tabbarView: TabbarView
  
  init(tabbarView: TabbarView, coordinatorFactory: CoordinatorFactoryImp) {
    self.tabbarView = tabbarView
    super.init(router: nil, coordinatorFactory: coordinatorFactory, moduleFactory: nil)
  }

  [...]
}

// Initialization:
TabbarCoordinator(tabbarView: controller, coordinatorFactory: CoordinatorFactoryImp())

I would appreciate if you could explain me the advantages of doing it your way instead of this way. Thank you in advance!!