Большое спасибо, что поделились опытом – интересно!
Не могли бы вы чуть подробней рассказать о проблемах, с которыми столкнулись при реализации диплинков при участии координаторов? Дело в том, что у нас в приложении они успешно (кажется) сосуществуют. Но я не исключаю, что что-то могло быть упущено!
Спасибо за хорошие вопросы! Постараюсь прокомментировать максимально подробно и по порядку пока хотя бы все, что смогу.
«не совсем понимаю плюсов от его использования» / «Какие именно удобства предоставляет координатор?»
Лично мне координаторы приглянулись своей линейностью: один координатор – один шаг навигации. Шаг вперед – инициализация и start(), шаг назад – это, условно, onFlowFinished().
«Почему логику навигации не оставить в Router (я его понимаю в контексте VIPER модуля)?»
В данном приложении у нас до этого все было на роутерах, и все довольно быстро превратилось в клубок (понятно, что тут не столько роутеры виноваты, сколько люди их писавшие, но все же). Но VIPER-ом у нас не пахло: были MVC-/MVP- и MVVM-модули с навигацией по ним на роутерах.
«есть UITabBarController» / «Насколько удобно будет восстанавливать состояние навигации при перезапуске приложения?»
У нас основной режим приложения – это экран с таб-баром как раз. Мы написали MainCoordinator, который, условно, внутри start() определяет состояние приложения и запускает тот или иной координатор. Есть некий AuthorizedStateCoordinator, который порождается MainCoordinator и открывает таб-бар с контроллерами. С этого момента у нас пока действуют в основном старые принципы навигации, поэтому я не смогу поделиться опытом, можно ли и удобно ли использовать координаторы для навигации по вкладкам. Но многие составляющие модули, которые дописывались в последнее время, «запечатаны» внутри координаторов (например, у нас есть вкладка с меню – там сам бог велел).
Это, кстати, был один из пропагандируемых плюсов координаторов: начинать их использовать можно с любого места. Хотя бы чтобы просто понять, нравится или нет.
«Насколько гибкими могут быть координаторы и как сильно инкапсулировать в себе логику различных видов навигации и их сочетания? „
Все внутри и все hardcoded. Например, в start() может быть что-нибудь вроде navigationController.push(...), а в onFlowFinished() – очистка стека и передача управления другому координатору, который добавит свой контроллер в стек, и тот станет новым root. Грубо говоря, что угодно, но, к сожалению, только заранее определенно.
Сочетания навигаций, как я себе вижу, можно как-то осуществлять с помощью сочетаний координаторов. По изначальной идее, координатор инициализируется под определенный способ навигации (с экземпляром UINavigationController, как у меня тут, например). Но модули (UIViewController или, скажем, какие-то группы UITabBarController) могут и переиспользоваться в разных координаторах – они прямо точно не должны зависеть от навигационных принципов.
“могут быть модули не владеющие UIViewController, например, ячейки коллекций»
Это дело у нас все в «представлении» и управляется контроллером. Но у контроллеров есть некий навигационный делегат – то, что у меня названо Route – интерфейс, который реализуется порождающим координатором и получает обратные вызовы по событиям от контроллера (нажата кнопка, выбрана ячейка и т.п.) По выбору ячейки, например, может быть порожден другой, дочерний, координатор, в который будет передан принцип навигации (например, наш UINavigationController) и по start() произойдет push соответствующего контроллера.
В общем, мысли возникают какие-то такие. Но я буду стараться делиться и реальным опытом, когда что-то из этого буду пробовать на себе!
О, мне только в удовольствие, если найдутся читатели!
Подсветки синтаксиса именно для Swift нет (или я что-то не понял). Можно включить для другого языка, и что-то станет покрасочней, но не все. Решил не сбивать с толку частичной подсветкой.
Если честно не совсем понял главный посыл статьи (с точки зрения разработчика).
Apple выпустили «бету», нам нужно потестить, что приложение не сломалось – звучит логично. Предположим, мы нашли какой-то баг и к тому же выяснили, что это не дефект приложения и не какой-то misuse обновившихся API. Что с этим нужно делать? «Костылить» заплатки для операционной системы изнутри приложения? Звучит уже не очень. Но если я понял верно, то что будет, когда (и если) Apple исправят этот дефект? «Раскостыливать» заплатку обратно и проверять все заново? И при этом нужно понимать, что «закостыленные» и «раскостыленные» версии приложения будут установлены у обоих групп пользователей – с дефектными версиями ОС и с исправленными (или даже до-дефектными).
Как справляетесь с этим? Лично я для себя ничего лучше, чем долгое я мучительное раздумье по поводу названия цветовых констант не придумал: делить элементы на группы, подгруппы и т.д. и называть их в духе materialized path.
А как предлагаете сделать? SchemeColor в данном случае же и предназначен, чтобы принимать в себя возможные цвета определенного элемента и возвращать нужный в зависиомсти от используемой цветовой схемы.
Это да, действительно либа была раньше на Objective-C, но это, можно сказать, была и не она вовсе – было уже проще написать новую, чем пытаться менять старую. Для новой выбрали Swift с прицелом на будущее и, конечно, соблазнившись скоростью и простотой написания и поддержки – немаловажные плюсы, на мой взгляд. Без ABI – это, безусловно, минус, но пара десятков Мб в современных реалиях – на мой взгляд, не критично. (Telegram X на 40 Мб тяжелее старого приложения еще даже не догнав его по функционалу – кажется, это мало кого волнует. Меня – точно не очень.) Зато Swift и работает потенциально быстрее. В общем, я бы сказал, что у каждого подхода есть свои плюсы и минусы.
Все верно, только изначальные обстоятельства диктовали обратоное.
Ну, предположим, все хотят писать и пишут на Swift. А тут кто-то всплыл с legacy-проектом на Objctive-C. И ему надо тоже эту либу, которая на Swift. И надо примерно сейчас. Писать новую либу на Objective-C? Да, это самое правильное. Да только либа на Swift уже занисает примерно 10 тыс. строк, а на Objective-C займет все 20. На это может не оказаться ресурсов и времени. А потом еще придется тянуть две версии (баги там исправлять, фичи новые добавлять) – тратить на каждую новую задачу в два раза больше времени.
Описанный опыт не претендует на то, чтобы называться хорошей практикой (понятно, что такого плана оберки – это костыли), а просто представляет собой один из путей существования в описанных обстоятельствах. Или, скажем, вовсе академический эксперимент.
Пока что прочитал по-быстрому, некоторые пункты обязательно надо обдумать!
Не могли бы вы чуть подробней рассказать о проблемах, с которыми столкнулись при реализации диплинков при участии координаторов? Дело в том, что у нас в приложении они успешно (кажется) сосуществуют. Но я не исключаю, что что-то могло быть упущено!
«не совсем понимаю плюсов от его использования» / «Какие именно удобства предоставляет координатор?»
Лично мне координаторы приглянулись своей линейностью: один координатор – один шаг навигации. Шаг вперед – инициализация и start(), шаг назад – это, условно, onFlowFinished().
«Почему логику навигации не оставить в Router (я его понимаю в контексте VIPER модуля)?»
В данном приложении у нас до этого все было на роутерах, и все довольно быстро превратилось в клубок (понятно, что тут не столько роутеры виноваты, сколько люди их писавшие, но все же). Но VIPER-ом у нас не пахло: были MVC-/MVP- и MVVM-модули с навигацией по ним на роутерах.
«есть UITabBarController» / «Насколько удобно будет восстанавливать состояние навигации при перезапуске приложения?»
У нас основной режим приложения – это экран с таб-баром как раз. Мы написали MainCoordinator, который, условно, внутри start() определяет состояние приложения и запускает тот или иной координатор. Есть некий AuthorizedStateCoordinator, который порождается MainCoordinator и открывает таб-бар с контроллерами. С этого момента у нас пока действуют в основном старые принципы навигации, поэтому я не смогу поделиться опытом, можно ли и удобно ли использовать координаторы для навигации по вкладкам. Но многие составляющие модули, которые дописывались в последнее время, «запечатаны» внутри координаторов (например, у нас есть вкладка с меню – там сам бог велел).
Это, кстати, был один из пропагандируемых плюсов координаторов: начинать их использовать можно с любого места. Хотя бы чтобы просто понять, нравится или нет.
«Насколько гибкими могут быть координаторы и как сильно инкапсулировать в себе логику различных видов навигации и их сочетания? „
Все внутри и все hardcoded. Например, в start() может быть что-нибудь вроде navigationController.push(...), а в onFlowFinished() – очистка стека и передача управления другому координатору, который добавит свой контроллер в стек, и тот станет новым root. Грубо говоря, что угодно, но, к сожалению, только заранее определенно.
Сочетания навигаций, как я себе вижу, можно как-то осуществлять с помощью сочетаний координаторов. По изначальной идее, координатор инициализируется под определенный способ навигации (с экземпляром UINavigationController, как у меня тут, например). Но модули (UIViewController или, скажем, какие-то группы UITabBarController) могут и переиспользоваться в разных координаторах – они прямо точно не должны зависеть от навигационных принципов.
“могут быть модули не владеющие UIViewController, например, ячейки коллекций»
Это дело у нас все в «представлении» и управляется контроллером. Но у контроллеров есть некий навигационный делегат – то, что у меня названо Route – интерфейс, который реализуется порождающим координатором и получает обратные вызовы по событиям от контроллера (нажата кнопка, выбрана ячейка и т.п.) По выбору ячейки, например, может быть порожден другой, дочерний, координатор, в который будет передан принцип навигации (например, наш UINavigationController) и по start() произойдет push соответствующего контроллера.
В общем, мысли возникают какие-то такие. Но я буду стараться делиться и реальным опытом, когда что-то из этого буду пробовать на себе!
Подсветки синтаксиса именно для Swift нет (или я что-то не понял). Можно включить для другого языка, и что-то станет покрасочней, но не все. Решил не сбивать с толку частичной подсветкой.
Apple выпустили «бету», нам нужно потестить, что приложение не сломалось – звучит логично. Предположим, мы нашли какой-то баг и к тому же выяснили, что это не дефект приложения и не какой-то misuse обновившихся API. Что с этим нужно делать? «Костылить» заплатки для операционной системы изнутри приложения? Звучит уже не очень. Но если я понял верно, то что будет, когда (и если) Apple исправят этот дефект? «Раскостыливать» заплатку обратно и проверять все заново? И при этом нужно понимать, что «закостыленные» и «раскостыленные» версии приложения будут установлены у обоих групп пользователей – с дефектными версиями ОС и с исправленными (или даже до-дефектными).
А первый не вполне понял. Это о struct ButtonAppearanceLight и struct ButtonAppearanceDark?
Ну, предположим, все хотят писать и пишут на Swift. А тут кто-то всплыл с legacy-проектом на Objctive-C. И ему надо тоже эту либу, которая на Swift. И надо примерно сейчас. Писать новую либу на Objective-C? Да, это самое правильное. Да только либа на Swift уже занисает примерно 10 тыс. строк, а на Objective-C займет все 20. На это может не оказаться ресурсов и времени. А потом еще придется тянуть две версии (баги там исправлять, фичи новые добавлять) – тратить на каждую новую задачу в два раза больше времени.
Описанный опыт не претендует на то, чтобы называться хорошей практикой (понятно, что такого плана оберки – это костыли), а просто представляет собой один из путей существования в описанных обстоятельствах. Или, скажем, вовсе академический эксперимент.