да, это аргумент про то, что не будет ситуации, как с exitTo - когда предыдущий экран в качестве параметра отдаешь

я уже не говорю, про инжект репозитория во фрагмент. Это может отпугнуть гугла от серьезного восприятия статьи, тем более что они проповедуют вьюмодель с более подходящим жизненным циклом. Плюс есть ВМ  с аргументами (которая еще в альфе)

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

у тебя компоненты так же устроены

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

Retrofit API и Room DAO - уже есть репозитории

это да, но я про конкретную сущность  из гайда гугла

https://developer.android.com/jetpack/guide

P.S. это уже оффтоп к навигации, предлагаю на этом остановиться

Добрый, у кого есть туториал для работы с новым чичероне. С доками не соответсует нынешняя

Там отличия минимальны, что именно не понятно?

Добрый день, использую cicerone:5.0,
у роутера нет методов для передачи аргументов,
как передать аргументы?

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

Тоже когда писал легаси и пересл на 5ую версию несколько негодовал.

Правильно передать в конструктор Screen и передать во фрагмент аргументами ручками. Из удобного, советую иметь с companion object'e метод newInstance(/*params*/): Fragment и внутри фрагмента константы ключей.

Спасибо.

Вчера переписал проект на Cicerone. Полет нормальный, удобно. Но есть момент, который кажется странным.
Если в SupportAppScreen переопределен метод getFragmentParams(), то getFragment() уже не вызывается.

Как при таком коде правильно передавать Сallback'и в фрагменты? Ведь если нужно передать и Bundle и Callback, то getFragment() не вызовется. Или я туплю и можно запихнуть Callback в Bundle?
Если же переопределять createFragment() в Navigator'e то это и не красиво и все равно не будет вызвано, если getFragmentParams() был переопределен.

Код выглядит примерно так:

class UserScreen(
   private val bundle: Bundle,
   private val callback: (value: Value) -> Unit,
) : SupportAppScreen() {

   override fun getFragment(): Fragment? {
       return UserScreenFragment().apply {
           this.callback = callback
       }
   }

   override fun getFragmentParams(): FragmentParams? {
       return FragmentParams(
           UserScreenFragment::class.javaclass.java,
           bundle,
       )
   }

}

Получается можно не использовать getFragmentParams() и вместо его переопределения передавать и Callback и Bundle в getFragment(). Тогда наличие getFragmentParams() в SupportAppScreen выглядит странным.

не нужно использовать оба метода
getFragmentParams - для создания фрагмента через FragmentFactory, в этом случае можно передавать колбэк в конструктор
getFragment - для создания фрагмента руками в этом методе, здесь нельзя передавать колбэк в конструктор. сериализовать колбэк тоже нельзя.

🤔
А чем FragmentFactory в связке с Cicerone будет лучше?

ничем, просто разные варианты создания фрагментов
например, есть возможность передавать зависимости через конструктор

(пожалуй, это все приятные функции такого подхода)

А откуда FragmentFactory возьмет аргументы для передачи их в конструктор фрагмента, если эти аргументы были переданы в SupportAppScreen?