Conductor VS BottomNavChildFragmentExample

I don't have much experience with conductor, so I'm curious what your concerns about lifecycle is lacking compared to fragments? But if your team already knows that framework I might just stick with views over fragments. I see there is a compose integration if you do ever plan on picking that up with conductor. Otherwise compose makes fragments obsolete and your team already knows conductor. I do agree the navigation story in compose is not mature especially after jetpack compose navigation. But there are other 3rd party libraries like compose destinations or decompose, but would be nice to see something better 1st party.

We aren't doing anything specific for Compose. The majority of our screens are still written in Views and we need to ensure we have interoperability to navigate to and from screens written with either UI layer. All of our screens, whether based on Views or Compose, use the same navigation library, Conductor.

I don't know how common/popular it actually is, but it's definitely not uncommon. Square has been doing this kind of home-made navigation for quite a while as far as I know (most recently in the form of workflow-kotlin), Lyft (Scoop) as well, and more (e.g. Conductor).

Pretty sure it's native and they were mentioning they use Conductor instead of official activity/fragment solutions in some post.

So the bottom nav should be managed like in this snippet: https://github.com/Zhuinden/BottomNavChildFragmentExample/blob/40d7b87ee77e96eae2b559b3b727609fb015198e/app/src/main/java/com/zhuinden/bottomnavfragmentexample/RootFragment.kt

are you looking for this too?

Like, I'm not even joking, you just need to use child fragments instead of letting Jetpack Navigation do it

See https://github.com/Zhuinden/BottomNavChildFragmentExample/blob/1ddb584b43e647e7a79d3cf3c56e9e003acd1298/app/src/main/java/com/zhuinden/bottomnavfragmentexample/RootFragment.kt#L13