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

угу

Всё, тоже понял. А если мы вызываем условно navigateTo(), я могу сразу после этого метода кидать колбек?

куда кидать? и куда navigateTo?

Другими словами, методы navigateTo, replace синхронные? Я если кину колбек после них, могу быть уверенным, что экран реплейснулся?

Кидать вплане вызвать callback.invoke()

Расскажу ещё кейс, который может кому-то помочь. Задача - в сложной иерархии экранов из внутренних экранов одного таба управлять стеком другого таба. Либо из диалогов. Если без шин, то на каждый таб можно создать отдельный роутер и забиндить его с помощью Qualifier. Не знаю, как с даггером это будет дружить, с Toothpick всё ок.

И где-нибудь в презентере:
@FirstTab val firstTabFlowRouter: FlowRouter
...
...
firstTabFlowRouter.navigateTo(...)
viewState.close()

А вслучае mvi навигация будет во фрагменте же?

navigateTo в роутере, а мы про навигатор)

Я это к сообщению выше

А это я верно понимаю?

у знаю как в 6 версии, но в 5 там commit у транзакции использовался

А коммит асинхронный же

Он вообще на ui потоке вызывается?

да, но табики ты переключаешь то как, не через commit

Видимо мой вопрос не совсем понятен. Такой псевдокод:

navigatoTo(Screens.Main())
callback.invoke()

Что вызовется первым?

Если учитывать, что navigateTo вызывается через комит, а не commitNow.

ну да, тут не всегда они будут вызываться друг за другом.... но navigatoTo ты будешь делать на роутере таба, а колбэк на роутере табов)

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

И у него листенер