
Комментарии 6
Почему-то во всех статьях про координатор его делают с методом start(), и координатор таким образом сам решает, как он должен быть показан, что, в моем понимании, неверно - решение должно позволять пушить и презентить (full screen, sheet, как угодно) любой координатор, вот тогда это будет действительно полезно
Название метода - просто сложившаяся и устоявшаяся практика. Просто так привыкли. А если доработать немного метод start() из примера кода, то лекго можно получить желаемое - указывать координатору как отобразить контроллер. Пару слов об этом в статье было. Вы немного забежали вперед. На горизонте еще пара статей с координатором :) А так, вы абсолютно правы - если есть несколько способов отображения контроллеров, то координатор - отличное место для указания способа их отображения. Подписывайтесь, впереди еще много интересного.
Проблема: захардкоженная навигация
в uikit с этим вообще никогда не было проблем.
А вот в swiftui системная навигация между экранами постоянно менялась от версии к версии и до сих пор сломана
Да, есть надежда, что они уже когда-то остановятся на так называемом «развитии» навигации и сообщество уже просто само выработает подходы и не придется вечно костыли писать или переписывать.
А по поводу захардкоженной навигации в UIKit - это не проблема в небольших проектах, где нет десятков экранов, которые нужно вызывать откуда угодно. Когда пользовательские пути прямые как лом, то все нормально. А когда экран успеха транзакции нужно вызвать из пяти разных мест, то тут уже хардкод навигации придется ломать.
И снова соглашусь с первым комментарием. Захардкоженная навигация только у Вас. У меня вот проблем нет. И вся статья дальше тоже теряет актуальность в связи с этим.
Почему нет проблемы? Все просто. Перенесите первый же Ваш код сниппет (с экшеном кнопки) в расширение UINavigationController. Все. Ни один Ваш унаследованный контроллер не знает ни об этом экшене, ни о других контроллерах, ни об их взаимосвязи...
Попробуйте, это крайне просто. Сильно проще, чем координатор. И эстетичнее. Как команды в системном меню...
Я в целом считаю что все эти координаторы хороши для пары-тройки экранов. А потом это становится недодерживаемое и тяжело модифицируемое дерево. И в конечном итоге от них больше головной боли. Все кому требуется сложная навигация и дипликнинг так или иначе в UIKit приходят к библиотекам которые основаны на проходе дерева вью контроллеров. А так как на SwiftUI навигация чаще сломана чем нет - ее тоже часто реализуют через UIKit а значит см выше.
Вот такое вот наблюдение. Я сам лично считаю его анти-паттерном. Но никому не навязываю это мнение.
Coordinator в iOS: как я перестал бояться кнопки «Назад» и полюбил навигацию