AP
Это будет сильно
Но надо сразу уточнить что у нас и навигационный граф не слишком сложный.
Там было всего пару моментов где пришлось заморочиться.
Size: a a a
2020 November 01
AP
Сколько примерно экранов было?
IG
Сколько примерно экранов было?
34
IG
Плюс 1 вложенный граф из 3х экранов
IG
Кстати, @terrakok а не было идеи сделать
Нам понадобилось сериализовать скрины и сейчас чтоб обойти необходимость наследоваться от
Выглядит так, что ничего не мешает сделать Screen интерфейсом + сделать дефолтную базовую имплементацию с дефолтным screenKey.
Screen интерфейсом?Нам понадобилось сериализовать скрины и сейчас чтоб обойти необходимость наследоваться от
Screen мы сделали собственные скрины + скрин для интеграции с Cicerone.Выглядит так, что ничего не мешает сделать Screen интерфейсом + сделать дефолтную базовую имплементацию с дефолтным screenKey.
ЕК
А для чего сериализовать, если не секрет?
KT
Кстати, @terrakok а не было идеи сделать
Нам понадобилось сериализовать скрины и сейчас чтоб обойти необходимость наследоваться от
Выглядит так, что ничего не мешает сделать Screen интерфейсом + сделать дефолтную базовую имплементацию с дефолтным screenKey.
Screen интерфейсом?Нам понадобилось сериализовать скрины и сейчас чтоб обойти необходимость наследоваться от
Screen мы сделали собственные скрины + скрин для интеграции с Cicerone.Выглядит так, что ничего не мешает сделать Screen интерфейсом + сделать дефолтную базовую имплементацию с дефолтным screenKey.
легко. после переноса на котлин пропустил этот момент :)
я тоже за интерфейсы
я тоже за интерфейсы
IG
А для чего сериализовать, если не секрет?
Ну мы таким образом делаем флоу.
Допустим фича требует аутентификации.
У нас есть
У нас он умеет выполнять Cicerone команды либо открывать Cicerone экраны.
Вместо того чтобы открывать непосредственно экран фичи, мы открываем
Допустим фича требует аутентификации.
У нас есть
AuthFlowFragment, он умеет разрешить данную зависимость и в результате выполнить необходимое действие.У нас он умеет выполнять Cicerone команды либо открывать Cicerone экраны.
Вместо того чтобы открывать непосредственно экран фичи, мы открываем
FeatureFlow который уже открывает фичу после аутентификации. Пример на скрине.ЕК
Окей, я об этом и подумал, что решал бы через какой-нибудь сериализуемый sealed FeatureFlowBundle. Но, раз скоро будут интерфейсы, то не актуально)
IG
Ну я хотел минимизировать человеческий фактор по максимуму
IG
Чтоб не приходилось никаких мапперов поддерживать или чего-то подобного
IG
Собственно сейчас единственное ограничение у нас это то что аргументы экрана должны быть сериализуемы.
Это и так необходимо, так что всё достаточно аккуратно вышло, по факту.
Это и так необходимо, так что всё достаточно аккуратно вышло, по факту.
IG
Да и то, сериализуемы должны быть только аргументы тех экранов, которые задействованы в каком-то Flow
ES
@terrakok Я правильно понимаю, что повесив на роутер дата листенер в одном классе и вызвав сет резалт в другом, колбек дёрнется? Или только при вызове exit() у предыдущего фрагмента? Этот листенер как глобальная лайвдата, у которой можно вызывать пост где угодно?
KT
как глобальная лайвдата - да.
но после отправки результата листенер очищается
но после отправки результата листенер очищается
KT
то есть только сингл шот и все
KT
я не стал делать метод exitWithResult для гибкости, можно не выходить, а реплейсить, завершать цепочку и что угодно
ES
как глобальная лайвдата - да.
но после отправки результата листенер очищается
но после отправки результата листенер очищается
Понял, спасибо. Ну вот у меня такой кейс. В одном из фрагментов я должен перейти на другой (это таб фрагмент) и соответственно поменять выделенный таб на bottom navigation view. Вот думаю как такое сделать.
KT
bottom navigation - не совсем навигация, это просто три (или сколько там у вас) контейнера на экране. переключение между ними - это как смена экрана в вьюпейджере. отвечает за это тот экран, который содержит табы