самое простое: закомментить весь блок, связанный с публикацией

окей, спасибо

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

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

или я что то не так сделал?

просто у меня фрагмент растет в геометрической прогрессии

вот эти две роли мой фрагмент выполняет

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

@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), а не роутер?

Вот тут должна быть обработка по идее? Intent же я должен не нуллабельный вернуть, можно было пока в месте создания ExternalScreen-ов обрабатывать исключения и возвращать null в блоке catch а в Reducer-е делать проверку и запускать колбэк с контекстом. Сейчас хз как и что делать

Вот касательно 3 вопроса, почему перенесли replacePreviousScreen в конструктор AppScreen, а не оставили в Modo?

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

Ммм ну хз, у меня айосовский бэкграунд и там мы обычно пушим в стэк и делали реплейс не помню даже когда) наверное когда легче было на window какую-нибудь супер-пупер анимацию сделать а-ля вращение в 180 градусов. Да и мне кажется этот аргумент слабым, разве не по бизнес-логике мы должны определяьть в каком месте как и хотим мы показывать экран? Может мне стоит немного изменить свое мышление по поводу фрагментов, но для меня они просто представляют контейнер для лейаута со своим жизненным циклом. В идеале я бы хотел извне указывать, захочу я добавить фрагмент, заменить им текущий или показать снизу диалогом или еще как-то. Я пока придерживаюсь мнения что это не обязанность экрана решать как на него переходить

Согласен, что это не обязанность экрана, я лишь предположил почему так может быть сделано.

А вы можете придумать конкретный случай, когда для одного и того же экрана вам в одном случае был бы нужен add, а в другом replace?

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

Ну представьте я хочу показать экран с новыми плюшками в приложении. При старте приложения я его к примеру показываю диалогом, а в *месте приложения, где обычно у нас настройки, инфа о лицензии, сторонних библиотеках, “о приложении” и т.д.* хочу вот делать add / replace.

Окей, возможно. Видимо это все к старой дискуссии, является ли диалог навигацией)

хорошо, не диалог. Но не надо меня заставлять придумывать ситуации). Для replace есть команда replace, для add есть команда forward, не понимаю зачем еще в forward проверка нужна