что для каждого экрана должен создаваться свой координатор + инжектиться в него ссылка на корневой роутер, если из этого экрана можно двигаться дальше по флоу?
а для каких решений подходит подход Coordinator+Router?
Координатор на флоу, а роутер на каждый экран создается. Но вообще мне сказали что вместе не очень их использовать
говорим про разные роутеры с вами, видать в моем случае, роутер хранит в себе навКонтрллер и показывает + скрывает контроллеры, а так же наблюдает за всякими событиями, типа свайпа назад или клика по кнопке назад в навбаре
почему не очень? как аргументировали?
а почему координатор не может хранить в себе навКонтроллер?
Ну у тебя похорошему должно что то одно отвечать за переходы. Есть три вида, навигатор роутер и координатор, у каждого свой рецепт преготовления. Я видела в проектах навигатор через синглтон реализованный и пацанам было ок все)
и какая функция у него вообще
может разделение ответственности
координатор знает что куда может направить текущий экран
@lvbond изначально вопрос был такой, дальше был диалог о поиске проблемы и мы просто отошли от темы, хотя вопрос был именно про связку Coordinator+Router спасибо за диалог, кое что я переосмыслил, в любом случае :)
Координатр создается на каждый “пользовательский сценарий” типа “раздел профиля”, “онбординг”, “экраны оплаты”. Я делал без роутера потому что флоу был не очень сложный. Но если там много логики типа “если А то после Б показать В”, тогда для экрана создает роутер и координатор пишет в роутер типа “дай следующий экран” и роутер сам решает какой именно. Координатор должен сам его показать. Я так это вижу
т.е. к примеру, возьмем абстрактный мессенджер переходя из списка чатов в определенный, создается 1 координатор комнаты и там рулятся клики и переходы от всего функционала экрана? не берем во внимание разделение на несколько координаторов(к примеру действия сообщений(видео, картинки и т.п.), навбар и т.д.)?
Я бы сделал так. Либо сделал координатор на уровне “списка чатов”, там несколько экранов типа “список”, “комната 1” “комната 2”ит.д. Ну допустим юзер нажал на юзерпик пользователя. Тогда там начинается сценарий “профиль пользователя” создается новый координатор для этого сценария, первый координатор передает в него юзер айди и передает управление стартует новый сценарий в нем еще несколько экранов.
понял, спасибо так себе и представлял этот подход
Мы пробовали это интегрировать для большого приложения с переменным успехом. Там были вопросы в основном на уровне “корня приложения” нужно было делать некоторый “рутовый координатор” который передавал управление между координаторами, и этот класс получился довольно массивным.
Обсуждают сегодня