Опять же, может мне стоит думать по-другому (да и скорее это зависит от случая, который может меняться от множества различных факторов), но пока что когда я видел replace на Android я каждый раз вижу инфлейт и байнд вьюшек и почти всегда это еще без сопровождения какой-либо анимации, просто бамп. И еще нужно восстанавливать состояние, что может быть трудно, а может быть и нетрудно в зависимости от ситуации и опыта, но с add вообще париться не нужно

Используя add сохраняется предыдущий фрагмент в стеке, если везде использовать будут просадки по памяти, потому что фрагменты не дестроятся.
Replace и Forward команды привязаны не к фрагментам а к транзакциям, чтобы можно было перейти назад на предыдущий фрагмент. Использовать add команду где не используется прозрачность или webview мне кажется не особо имеет смысл

Я в курсе про просадки, но если мне нужно добавить по одному-двум экранам (то есть вложенность небольшая)? И как это они не привязаны к фрагментам, вы же в одном месте (к примеру в объекте Screens) описываете AppScreen-ы. Если хочется различное поведение (два случая), то надо в каждой функции возвращающей AppScreen иметь параметр, который мы будем передавать ModoRender и еще в ViewModel говорить Modo, хотим мы сделать forward или replace. Зачем нужно первое?
Получается как-то forward+replacePreviousScreen отличается от replace?

replace внутри Forward сохраняет транзакцию в бэкстеке, чтобы потом вернуться, replace через команду cicerone удаляет её. В первом случае вернуться назад на этот фрагмент в стеке можем, во втором нет

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

кстати что вам мешает вынести replacePreviousScreen в аргументы функции, которая создаёт экран?

@terrakok Приветствую! У меня к Вам и чатику 3 вопроса)).
1) В Cicerone у AppNavigator можно было переопределить метод errorOnApplyCommand, который позволял обрабатывать различные эксепшны, которые к примеру могут выбрасываться, когда нужно было сделать звонок (перейти на ActivityScreen), но пользователь не дал разрешение на него. И у ActivityScreen в блоке можно было обращаться к контексту, сейчас же я могу только вернуть интент, доступа к контексту нет (. У ModoRender доступа к контексту нет да и непонятно где обработка должна быть (в setupTransaction(…)?) Контекст есть у AppReducer, но его нельзя унаследовать, да и поле приватное. Как быть?
2) Помню в пятницу Вам задавал такой вопрос - у меня есть FragmentScreen / AppScreen, в разных местах у меня может быть требование/желание показывать их по-разному (к примеру, с разными анимациями). Сейчас не вспомню точно как Вы ответили, но мы вроде бы сошлись на том, что в месте вызова метода роутера ему нужно передать конфигурацию с который мы бы хотели совершить навигацию, сейчас же кажется нужно в setupTransaction, как и в чичероне по выборке “предыдущий->следующий” навигатору решать как ему обрабатывать транзакцию. А разве это его обязанность? Подскажите, как быть и в курсе ли Вы этого вопроса? Не хотелось бы иметь простыню из ифов
3) Задавал себе этот вопрос и когда чичероне использовал в проекте и сейчас когда переписываю на модо - почему AppReducer / AppNavigator может по команде forward / navigateTo не только добавлять фрагмент, но и заменять его? Причем замена это поведение по умолчанию, у меня как-то не складывается это все в голове. Скорее всего просто потому что в Android предпочитается делать replace, а не add (может это с бэкстэком связано?). Я еще нуб и на этот вопрос пока скрупулезно ответ не искал. Но возник другой вопрос - почему сам экран решает, какой на него переход должен произойти (add / replace), а не роутер?

1) возможно вы правы, и можно навесить разных методов в АппРедьюсер (я подумаю), но  новая архитектура Модо позволяет расширять все очень просто: достаточно обернуть АппРедьюсер вашим редьюсером и ловить эксепшны при вызове метода invoke
2) если это необходимо, то в параметры скрина я бы положил какое-то свойство, отвечающее за вид анимации, а в setupTransaction я бы по этому полю ориентировался как именно настроить транзакцию
3) в плане стека экранов replace и add ничем не отличаются у фрагмент менеджера. названия просто смущают. replace при добавлении нового экрана в стек очищает UI предыдущего, а add оставляет.
поэтому предпочтительнее всегда использовать replace, так как обычно новый экран полностью перекрывает предыдущий, и чтобы не жрать лишнюю память его UI следует выгрузить из памяти.
Add полезен в тех случаях, когда UI тяжелый и важно не тратить время на его восстановление при возврате. Например WebView или экран с картой

1) возможно вы правы, и можно навесить разных методов в АппРедьюсер (я подумаю), но  новая архитектура Модо позволяет расширять все очень просто: достаточно обернуть АппРедьюсер вашим редьюсером и ловить эксепшны при вызове метода invoke
2) если это необходимо, то в параметры скрина я бы положил какое-то свойство, отвечающее за вид анимации, а в setupTransaction я бы по этому полю ориентировался как именно настроить транзакцию
3) в плане стека экранов replace и add ничем не отличаются у фрагмент менеджера. названия просто смущают. replace при добавлении нового экрана в стек очищает UI предыдущего, а add оставляет.
поэтому предпочтительнее всегда использовать replace, так как обычно новый экран полностью перекрывает предыдущий, и чтобы не жрать лишнюю память его UI следует выгрузить из памяти.
Add полезен в тех случаях, когда UI тяжелый и важно не тратить время на его восстановление при возврате. Например WebView или экран с картой

не понял вас.

так у ваc и будет это при вызове: modo.forward(MyScreen(my_animation_params))

разница колосальная. анимация ведь относится к конкретному скрину, а не к библиотеке навигации.

потому что скрин - это не то что у вас будет показано на экране (это фрагмент будет показан), а набор параметров для навигации: ид, фабрика фрагмента, параметры фрагмента, параметры перехода и так далее.