Что такое паттерн Coordinator и используете ли его
Что проверяют
Понимаете ли вы, какую проблему он решает, и знаете ли его слабые места.
Как отвечать
Приём выносит навигацию из контроллеров экранов в отдельные объекты. Контроллер перестаёт знать, какой экран следующий: он сообщает о событии, а решение принимает координатор.
Проблема, которую это решает: в обычном подходе экран сам создаёт и показывает следующий. В результате экраны знают друг о друге, переиспользовать их в другом сценарии нельзя, а логика переходов размазана по всему приложению. Особенно больно, когда один и тот же экран нужен и в регистрации, и в настройках, но с разным продолжением.
Что даёт:
- экраны становятся независимыми и переиспользуемыми;
- сложные потоки описаны в одном месте: регистрация, оплата, вход по ссылке;
- глубокие ссылки обрабатываются естественно, потому что есть объект, умеющий построить нужную цепочку экранов;
- навигация тестируется отдельно от интерфейса.
Минусы называть обязательно:
- больше кода и лишний уровень косвенности. На приложении из пяти экранов это чистые накладные расходы;
- передача результата назад требует отдельного решения: замыкание, делегат или общий объект потока;
- время жизни дочерних координаторов это главный источник утечек. Дочерний координатор надо удалить из родителя, когда его поток завершился, иначе он и все его экраны останутся в памяти. Этот момент забывают чаще всего;
- синхронизация со стеком навигации: пользователь может уйти назад системным жестом, и координатор об этом не узнает, если не подписан на события навигации.
Про SwiftUI стоит сказать отдельно: там навигация уже описывается состоянием, и путь хранится отдельным значением. Идея та же, но отдельный объект-координатор обычно не нужен, его роль играет модель, владеющая этим путём.
Где спотыкаются
Не удаляют дочерние координаторы и получают утечки.
Не обрабатывают возврат назад системным жестом.
Применяют приём на маленьком приложении.
Оставляют переходы в контроллерах, называя это координатором.