simple-stack-compose-integration VS compose-destinations

Yup, that's why we're working on https://github.com/Zhuinden/simple-stack-compose-integration/ to make it as simple as backstack.goTo(SomeScreenKey(arg1, arg2)) instead of this navController.navigateTo("some/screen&arg1=${UrlEncoder.encode(arg1.toBase64())} stuff. If you are working on an Android app that will always be on Android-only, why would you inherit limitations from Kotlin Multi-platform?

We have https://github.com/Zhuinden/simple-stack-compose-integration/ but the fact that I'd normally prefer to use fragments kinda holds it back

Simple-Stack-Compose https://github.com/Zhuinden/simple-stack-compose-integration

However, it's worth noting that thanks to a guy named @matejdro we are working on a pure-Compose version, in which setup has been reduced to

And ,yes, although not being made for Compose, also Simple stack :)

i'd love to recommend simple-stack-compose-integration but i never wrote this missing link

Using any of the 5 prominent community alternatives is a better approach (even though most people hoping to use the docs as if it was like, written for stable code, will muck around with their apps crashing if the user inputs a & symbol). I have this thing but I'd consider taking a look at https://github.com/adrielcafe/voyager or maybe https://github.com/olshevski/compose-navigation-reimagined

If you're deadset on full compose navigation I'd check out Zhuinden`s simple-stack-compose-integration

I'm almost tempted to use multiple ComposeViews, but I'm definitely not using 1 ComposeView N composables any time soon, even though technically I have the code to support it.

Yea I also have https://github.com/Zhuinden/simple-stack-compose-integration but I saw that I really need to put in the work to have the LocalLifecycleOwner etc set up for a given key 🤔

During a mentoring session for my mentee’s Android project a beautifully structured app that just lacked motion personality I introduced her to Ramcosta Destinations. Not because the library itself is magical, but because it provides a clear structure to experiment with transitions without boilerplate. Once navigation felt manageable, I asked her to focus on how the screen should move, not just what it should show.

This time is about navigation, when raamcosta ( https://github.com/raamcosta/compose-destinations) in jetpack compose

The biggest help of all by far was Compose Destinations. It takes away all the boilerplate of maintaining your routes. A simple way to not have to create all those routes yourself with placeholders etc, including deeplink patterns and all. It generates all of that for you in a typesafe way. Just check the basic example on GitHub or the dedicated documentation website.

Here is a great solution for navigation in compose. Actually this is what Google should have done in the first place https://github.com/raamcosta/compose-destinations

Compose destinations is another alternative: https://github.com/raamcosta/compose-destinations

Hey, thanks for sharing here. Do you mind sharing how exactly this library is different from this one https://github.com/raamcosta/compose-destinations and why one would use one over the other?

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.

I can't recommend the vanilla compose navigation from Google, but the community has built others like compose destinations which is pretty good.