Comments 7
Господи, как же все сложно.
Я у себя сделал некое подобие intent'а андроидовского: все в одном месте и сразу. Делю максимально на различные story board'ы и все прекрасно работает
Спасибо, история со сценариями обернутыми в локаторы понравилась.
UFO just landed and posted this here
В оригинальном видео об этом сказали вскользь. Я постараюсь пояснить.
Если я вас правильно понял, то у вас имеется App Coordinator и, скажем, Feature Coordinator. App Coordinator создает и держит ссылку на Feature Coordinator. Как только пользователь закончит работать с Feature Coordinator и нажмет системную кнопку назад (back button), нам необходимо убрать feature coordinator из App Coordinator.
Системное нажатие назад можно определить следующим образом:
Теперь надо сообщить об этом Feature Coordinator обычным способом, вызвав переданный closure/callback. На этом этапе Feature Coordinator знает, что пользователь уже ушел с активного экрана и дальше уже нечего делать. Теперь надо сообщить об этом App Coordinator. Сделать это можно через delegate, callback или Notification Center. К примеру, на этапе инициализации Feature Coordinator передать callback:
Если я вас правильно понял, то у вас имеется App Coordinator и, скажем, Feature Coordinator. App Coordinator создает и держит ссылку на Feature Coordinator. Как только пользователь закончит работать с Feature Coordinator и нажмет системную кнопку назад (back button), нам необходимо убрать feature coordinator из App Coordinator.
Системное нажатие назад можно определить следующим образом:
override func willMove(toParentViewController parent: UIViewController?) {
super.willMove(toParentViewController:parent)
if parent == nil {
// пользователь нажал назад
}
}Теперь надо сообщить об этом Feature Coordinator обычным способом, вызвав переданный closure/callback. На этом этапе Feature Coordinator знает, что пользователь уже ушел с активного экрана и дальше уже нечего делать. Теперь надо сообщить об этом App Coordinator. Сделать это можно через delegate, callback или Notification Center. К примеру, на этапе инициализации Feature Coordinator передать callback:
init(navigationController: UINavigationController, onFinish: (FeatureCoordinator)-> ()) {} 
Вынести логику из жирных вьюконтроллеров идея не плохая, но дополнительные сущности увеличивают энтропию системы в целом, со всеми вытекающими отсюда последствиями… И в начале статьи упоминалось, что для смены кадров не придется переписывать код, но далее по презентации видно что это не так. Т.е. код править в любом случае придётся, а значит дополнительных преимуществ такой подход не даёт. Быть может я что-то упустил?
Код менять всегда придется, само собой ничего не произойдет. Однако одно дело — править код в единственном месте (в координаторе, максимум — в нем и плюс еще в рутовом, который может удерживать на него ссылку), а совсем другое — во всех местах, связанных с данным контроллером (когда у вас 5 экранов реализуют один и тот же код вызова контроллера — править придется 5 мест).
Это всегда две стороны одной медали. Чем больше разделение ответственности — тем сложнее структура системы, но тем проще ее модификация, сопровождение и тестирование (при условии, что человек разобрался в архитектуре, конечно же, и реализует ее корректно). И наоборот, чем меньше разделение — тем проще ориентироваться в структуре проекта, тем меньше требуемая квалификация (пока багов нет и контроллеры не разрослись выше 1000 строк), однако тем тяжелее и трудозатратнее становится расширять систему. Совместить «лучшее из лучших» не получится, во всяком случае, на данный момент ничего не придумано. Предложенный подход с координаторами — нечто среднее по сложности между MVC/MVP и VIPER, некий компромисс, кроме того, ее сложность можно подстроить под проект, это уже зависит от навыка архитектора. Лично мне подход нравится.
На мой взгляд, «серебряной пули» в виде идеальной архитектуры нет и быть не может, под каждую задачу есть свое подходящее решение. Реализовывать тяжеловесный VIPER в двухэкранном приложении — дико избыточная и нерентабельная затея, но и писать огромное банковское приложение на базе традиционного MVC — тоже так себе идея. Если утрировать, шуруп можно и молотком забить, но лучше все же воспользоваться отверткой.
Это всегда две стороны одной медали. Чем больше разделение ответственности — тем сложнее структура системы, но тем проще ее модификация, сопровождение и тестирование (при условии, что человек разобрался в архитектуре, конечно же, и реализует ее корректно). И наоборот, чем меньше разделение — тем проще ориентироваться в структуре проекта, тем меньше требуемая квалификация (пока багов нет и контроллеры не разрослись выше 1000 строк), однако тем тяжелее и трудозатратнее становится расширять систему. Совместить «лучшее из лучших» не получится, во всяком случае, на данный момент ничего не придумано. Предложенный подход с координаторами — нечто среднее по сложности между MVC/MVP и VIPER, некий компромисс, кроме того, ее сложность можно подстроить под проект, это уже зависит от навыка архитектора. Лично мне подход нравится.
На мой взгляд, «серебряной пули» в виде идеальной архитектуры нет и быть не может, под каждую задачу есть свое подходящее решение. Реализовывать тяжеловесный VIPER в двухэкранном приложении — дико избыточная и нерентабельная затея, но и писать огромное банковское приложение на базе традиционного MVC — тоже так себе идея. Если утрировать, шуруп можно и молотком забить, но лучше все же воспользоваться отверткой.
Sign up to leave a comment.
Application Coordinator в iOS приложениях