Да, спасибо, не подумал про чайлд фрагменты. получается у нас активити должно отвечать за сплеш экран, если такой есть, аналитику и за открытие первого фрагмента. А вообще немного странно что google говорит одно активити хорошо, и выкладывает io18 в котором их 7 штук

как по мне iosched больше используется как пример для UI/UX, а с multiple Activity меньше работы нужно сделать, чтобы создать более сложный UI/UX.

А как же проблемы с can not show dialog fragment after onSavedInstanceState ? Или на простом диалоге?

Это правильная ошибка. Так делать нельзя. И с чичероне вы так и не сделаете

За транзакции после onStop нужно бить по рукам, если такая ошибка падает, значит вы на 120% делаете не так.

Забавно но оно до onStop м после onCreate валится

Отдельная активити для пина проще в реализации и минимизирует выстрелы в ногу

Это не всё, что гугл говорит про активити. Достаточно подумать о использовании приложения извне. Но вот что-то не вспоминаются примеры не гугловых приложений, которые предоставляют свои части\активности как полноценные компоненты, которые можно использовать извне. Сходу на ум приходит только пример с парсером QR кодов, когда аппе нужен распознанный qr код, и мы "просим" другое приложение распознать qr код и отдать результат нам.

Так Гугл предоставляет схожую функциональность во фрагментах, относительно чего-то другого думаю проще свои костыли написать

Не после онСтоп, а после онПауз

Ничем не проще. Все получается совершенно одинаково по коду, а вот проблем там десяток.

Один лишь запуск активити - асинхронная операция. Никто вообще не гарантирует, что она отобразится

интересно ваше мнение, так делать плохо или нет? если да, то подскажите best practices

class NavigationHelper @Inject constructor(
       val mainRouter: MainRouter,
       val rootRouter: RootRouter
)

[AppComponent]
@Provides
@Singleton
fun provideNavigationHelper(mainRouter: MainRouter, rootRouter: RootRouter) = NavigationHelper(mainRouter, rootRouter)

[SomeComponent]
@Provides
@SomeScope
fun provideSomePresenter(navigationHelper: NavigationHelper): SomePresenter {
       return SomePresenterImpl(navigationHelper)
}

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

с чего вы взяли, что "не камильфо"?

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

а если инжектить какую-то сущность и дергать оттуда нужный мне рутер? слишком накладно? У меня также как в примере выше и я думаю как бы покрасивее сделать

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

в итоге сделал так

Можно убрать скобки и return поставить вместо них =