Прочитайте свой изначальный пост. Там явно указано про комментарии и решения. Я, между прочим, с вами сразу согласился на тему того, что комментарии неактуальные и поставил под сомнение лишь слово решения и привел довод, где описанное в публикации решение будет работать. И после того, как я вами согласился на тему неактуальности комментариев автора, вы опять упрекнули меня за игнорирование комментариев.
1. Может вы что-то другое имели ввиду под словом решения?
2. Может вы думали, что я ваши комментарии назвал неактуальными?
Публикация решают одну конкретную задачу, с которой, как вы уже сами сказали, вы сможете справиться не всегда используя Storyboard. Думаю вам следует смириться с тем, что не все используют Storyboard. И, наверное, вам следует радоваться тому факту, что люди пишут интерфейс кодом, тратят на это больше времени и пишут подобные статьи завлекая других в этот омут программирования кодом. Вы используете более современный подход и будете более востребованы как специалист и сможете зарабатывать больше $. Ну я бы точно этому радовался
Получается, что приведенные в публикации решения могут использоваться в таких ситуациях, в которых Storyboard не подойдет по какой-либо причине. Поэтому назызвать неактуальным можно только коментарий.
Вдруг получится так, что один и тот же класс созданный при разных условиях должен будет себя вести по разному при одинаковом типе перехода. Тогда придется вводить дополнительный флаг, который будет отвечать за тип инициализации. А если делать через type, то можно сделать что-нибудь типа . transport_in_navigation, . transport_presented_modally и легко развести логику.
Но на самом деле, как и было сказано в публикации: Можно добиться адекватного сопоставления UIViewController и перехода разными способами. Предложенный вами один из таких. И, если для ваших задач его будет достаточно, то можно пользоваться и им. Тут любой подход будет оправдан если вписывается в рамки поставленной задачи
1. Карта переходов. Если перейти в публикации к словам: "Введя новый параметр type у UIViewController можно детализировать функцию routing, в которой будут собраны все вызовы переходов между экранами приложения и разбиты по типу вызывающего UIViewController", то код приведенный под ними является той самой картой всех переходов в приложении. Ну и вроде как это достаточно наглядно.
2. Ограничение доступа. Вызвать переход с любого экрана на любой можно (но только вызвать). Если в карте переходов не будет прописано для конкретного типа контролера конкретного действия, то просто ничего не произойдет. Поэтому просто так перейти куда угодно не получится. В публикации, если вы вызовете для контролера с type = .navigation переход с параметром selectedCityTransport, то ничего не произойдет, т.к. этого нет в карте.
3. Передача параметров. Проблемы с передачей параметров и так нет. Внутри enum Routing можно передавать что угодно
В публикации ни слова о том, что кастомная анимация должна быть в чистом виде реализована в роутинг слое. Приводятся примеры лишь анимации «из коробки». Роутинг слой здесь представлен как набор стратегий переходов собранных в одном месте. Как вы распорядитесь переходами это уже совсем другой вопрос
Если вы откроете Storyboard, то Segue это в чистом виде роутинг между двумя UIViewController. И ручной вызов этого происходит именно в UIViewController и Segue с ним тесно связано. Так сделали в Apple. В этой публикации по сути говорится о том же, только об удобной группировке всех вызовов переходов.
Чаще всего в проектах кто-то один составляет палитру цветов при общении с заказчиком (enum или что-то вроде этого). Далее, все остальные используют лишь саму палитру и в большинстве случаев даже не знают реальных цветов. Удобно ли будет составителю палитры использовать color literal? Скорее всего да, а может и нет! Самым важным моментом будет возможность просмотреть текущий цвет и, при несовпадении с требованиями заказчика, быстро его поправить. У нас цвета представлены hex кодом. Вы пишете о возможности просмотра цвета RGB, а можно ли посмотреть hex?
Вы использовали анимированное применение стилей? Поделитесь примером?
1. Может вы что-то другое имели ввиду под словом решения?
2. Может вы думали, что я ваши комментарии назвал неактуальными?
Но на самом деле, как и было сказано в публикации: Можно добиться адекватного сопоставления UIViewController и перехода разными способами. Предложенный вами один из таких. И, если для ваших задач его будет достаточно, то можно пользоваться и им. Тут любой подход будет оправдан если вписывается в рамки поставленной задачи
1. Карта переходов. Если перейти в публикации к словам: "Введя новый параметр type у UIViewController можно детализировать функцию routing, в которой будут собраны все вызовы переходов между экранами приложения и разбиты по типу вызывающего UIViewController", то код приведенный под ними является той самой картой всех переходов в приложении. Ну и вроде как это достаточно наглядно.
2. Ограничение доступа. Вызвать переход с любого экрана на любой можно (но только вызвать). Если в карте переходов не будет прописано для конкретного типа контролера конкретного действия, то просто ничего не произойдет. Поэтому просто так перейти куда угодно не получится. В публикации, если вы вызовете для контролера с type = .navigation переход с параметром selectedCityTransport, то ничего не произойдет, т.к. этого нет в карте.
3. Передача параметров. Проблемы с передачей параметров и так нет. Внутри enum Routing можно передавать что угодно