Как стать автором
Обновить

Комментарии 12

Не совсем понятно, куда выносится логика по обработке «сложных» случаев, когда пришел push
и нам например нужно открыть определенный чат, а пользователь в этот момент где-то в глубине settings экранов или в соседнем чате.
Или например еще вариант — приходит тот-же push, а аппка не запущена и нужно сначала запуститься, пройти аутентификацию(провалидировать токены и тому подобное), а уже потом
перекинуть пользователя в соответствующий чат
Она никуда не выносится. Остается в цепочке.
1. Вы сами решаете в начале как вы хотите обрабатывать когда приходит пуш когда пользователь в глубине сеттингов. Если сеттинги в другом табе, роутер переключит таб, потому что он знает что список чатов в другом табе. Если сеттинги показаны модально, зависит от вашей конфигурации, роутер может закрыть сеттинги (простой вариант), показать альтернативно час с этим пользователем модально над сеттингами, цепочка может иметь ветвления или вы можете подменить конфигурацию в момент входа пользователя в сеттинги (менее красиво)
2. С этим вообще нет проблем, LoginInterceptor или отрабатывает или нет. Так что этот вопрос даже не стоит.
Оба примера более менее охвачены в Example app. Первый в ProductConfiguration.swift, 2. Любая навигация закрытая LoginInterceptor. Приложение-пример также поддерживает простейший диплинки. Вы можете проверить интересующие вас сценарии имитируя пуш через мобайл сафари.
Спасибо, буду пробовать, потому как диплинкинг в текущих проектах уже превратился в боль :)
Не за что. И если будут еще вопросы — не стесняйтесь. Как я написал выше. Там не все сразу очевидно.

Выглядит круто, пользоваться ею вроде не сложно.


Однако поддерживать это стороннему человеку будят тяжко, если потребуется какая-то особенность.


Также сильно возрастает входной порог в проект.


Я бы не рискнул взять это в проект ибо кода достаточно много.


Так же есть вопросы к производительности и кастомным анимационным переходам(не успел еще найти их).


Однако как сделать лучше я тоже не знаю.

Попробую уточнить каждый пункт.
1. Входной порог в любой проект возрастает, если вы используете что то отличное от Massive View Сontroller.
2. Любая особенность расширяется или новой фабрикой, или фаиндером. Роутер лишь выполнит их по очереди.
3. Кастомные переходы остаются на вас и выполняются по всем тем же правилам, которые прописаны в UIKit. Делаете своего делегата презентации и, вперед, как по учебнику. Библиотека ничего не закрывает и не содержит кастомных оберток. Она лишь выполняет шаги по очереди и умеет решать какие из них нужны, а какие нет. По этой же причине не может быть вопросов к производительности. К тому же, итератор дерева вынесен в отдельный компонент и может быть заменен кастомной реализацией в любой момент не затрагивая основную функциональность.
4. Мы адаптировали ее поверх проекта который к тому времени был уже 3 года в релизе именно по причине полнейшей каши в диплинках. И еще в этот момент надо было сделать A/B тест гамбургер меню против таб бара. Тут, как говорится, попробуйте руками. Можно адаптировать по одному экрану или по экранам которым требуется диплинк, а потом все остальное. У нас до сих пор не все 100% покрыты, просто потому что есть куски которые никто не трогал, потому что и так работает. Но все новые скрины автоматом навешиваются на библиотеку. Сейчас в работе A/B/C тест, где и как разместить поиск и подход показывает себя с лучшей стороны.
5. Какой то совсем нестандарт (я не могу себе представить правда), в самом крайнем случае, вы можете исключить роутер и сделать этот переход руками. Прелесть подхода в том что он работает не зависимо от текущего состояния приложения.
6. Риск оправдан опять же тем что библиотека изымается и вы все снова делаете руками при желании. Только вам надо будет самому принимать решения о том показан пользователю экран и как его показать.

Надеюсь, я смог дать однозначный ответ по всем пунктам.

Да, спасибо!
Хорошо, что уже оно в в реальных проектах работает.


Входной порог в любой проект возрастает

Ну использование Rx сильно повышает порог, а стандартный GCD нет. я об этом.


Massive View Сontroller

Это люди так пишут, можно писать нормальный MVC, но не будем этом тут :)


A/B тест гамбургер меню против таб бара

Интересная задача на самом деле. Одна если нет переходов из любого места в них) ибо много чего придется оборачивать, что по идеи у вас и делается.


У вас интересные подходы, возможно когда-то на досуге разберусь.
Все таки хочется найти чего-то более простого, более легковестного.
Чтобы было easy to learn hard to master как UIKit :)

Даже MVVM повысит :) Но, впрочем, это уже совсем другая история.
Удачи в этом нелегком поиске.
Malum consilium est, quod mutari non potest
Хотел поинтересоваться, а каким образом можно используя RouteComposer использовать кастомные анимации для UINavigationController (UIViewControllerAnimatedTransitioning)?
Нашёл только возможность использования кастомных анимаций для модальных презентаций (UIViewControllerTransitioningDelegate).

Да, этого нет в приложении-примере, но по идее таким же образом как и с модальными. RouteComposer только выполняет шаги, и не закрывает никакие объекты и все их свойства доступны наружу. Вам нужно назначить ответственный объект делегатом UINavigationController-а, например используя NavigationControllerFactory.init(delegate: UINavigationControllerDelegate?...) и дальше действовать согласно документации. Если что то не получится — напишите.
Если у вас все сложнее, напишите

Спасибо большое! Буду пробовать!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории