Случайно у кого-нибудь есть пример работы fragment factory вместе с  cicerone?

что именно не понятно? реализовывать экраны - так:
https://github.com/terrakok/Cicerone/pull/110#issuecomment-587083794

Спасибо, смотрел просто реализацию библиотеки под kotlin, а там подобного не нашел. Спасибо большое!

Ребят, извините, что отвлекаю. Еще один вопрос. У нас есть метод setupFragmentTransaction(command: Command, currentFragment: Fragment?, nextFragment: Fragment?, fragmentTransaction: FragmentTransaction), в котором можно было настраивать анимацию, в моем случае shared Transition. Мы могли понять в нем с какого экрана и на какой экран мы переходим с помощью currentFragment и nextFragment. Все было окей. Но когда начинаешь использовать fragment factory, то nextFragment == null, так как мы используем fragment params. И мы не можем достать экземпляр fragment (Fragment fragment = fragmentParams == null ? createFragment(screen) : null;). Есть идеи как можно это настроить?

единственное что приходит на данный момент в голову, это от наследоваться от Navigator и переопределить методы, и сделать вот такой метод setupFragmentTransaction(command: Command, currentFragment: Fragment?, nextFragment: Class<?: Fragment>?, fragmentTransaction: FragmentTransaction) и вызвать его

это норм идея 👍

Спасибо🙂

а еще норм идея выкинуть фрагмент фактори в мусорку

там все равно придется сервислокатор впялить, т.к. аргументов не дают при инстанциировании (про это и говорится в статье, но очень размазанно)

бекТу  тоже требует знаний про другие экраны, например, когда скринИд определяется в рантайме (префикс + ид, например экран трека в музыкальной аппке)

кста с мультивызовами роутера нужно аккуратно быть, т.к. там под капотом executePendingTransactions, который ломает оптимизации (reordering)

т.е. exit + navigateTo не тоже самое, что и replace

надо не аккуратным быть, а не делать так

для этого и есть роутер

аргумент - аргументы, мы их не трогаем
зависимости - передаем через конструктор в контейнере, который потом переживает пересоздание

из плюсов только то, что фрагмент не знает, куда идти за зависимостями и просто получает их извне, и рантайм ошибки, если не добавил создание фрагмента в фабрику)

я обычно в презентер отдаю координатор
и тогда знания о переходах хранятся в родительском модуле, который вполне знает о соседних экранах одного сценария

это если зависимости всегда одни и те же, а у автора статьи предполагаются разные  имплементации, что, как по мне, косяк его архитектуры, но тем не менее факт остается фактом, в кейсе, когда зависимости зависят от инфы из аргументов - фабрика бесполезна

это ведь работает и для нескольких exit

да, я тоже не понял этот момент
тип связь между аргументов и зависмостями - стрем

в том же чичероне - два разных экрана с разными реализациями фрагмента
но у Аркадия подход такой, что фича максимально изолирована от всего и может сразу несколько имплементаций для одного экрана давать
и ты извне просто открываешь профиль с айдишником, а профиль уже сам решает, какие ему зависимости нужны для айдишника (свой/чужой)