https://kotlinlang.org logo
#compose
Title
# compose
b

brabo-hi

12/13/2023, 4:50 PM
Hello guys, is jetbrains working on multiplaform navigation library?
h

Hristijan

12/13/2023, 4:55 PM
Yes
s

Stylianos Gakis

12/13/2023, 4:55 PM
I’ve seen a bulletpoint somewhere that they do want something to make happen there. And there’s also an issue which tracks if/when androidx.navigation will manage to itself become multiplatform https://issuetracker.google.com/issues/214568825 These two things as may or may not be connected with each other, but in any case, JB has said that they want something to be done there.
k

Konstantin Tskhovrebov

12/13/2023, 5:01 PM
b

brabo-hi

12/13/2023, 5:41 PM
that's what we are currently using on some projects, my question was mostly to know jetbrain's roadmap regarding
navigation
and
string resource
management in KMM
is there any plan to develop a native solution? or to use third party libraries
k

Konstantin Tskhovrebov

12/13/2023, 5:43 PM
Why do you prefer one over other solutions? Something is missing there?
b

brabo-hi

12/13/2023, 5:49 PM
Nothing specifically, we are using it on other platforms except android where we still using jetpack navigation. Our decision is to see id we should migrate that part to use voyager instead and keep w single navigation. One thing we haven’t tried with voyager is multiple modules navigation
p

Pablichjenkov

12/13/2023, 6:51 PM
One thing Voyager lacks is platform lifecycles, onCreate/onStart/onStop/onDestroy. These are essentials to build an App. There is a way to integrate platform lifecycle in Voyager but it is not the nicest code. I see many people using Voyager, they treat LaunchEffect as if it was onStart, and this is a big mistake.
So far the closest to reality are Appyx and Decompose but then many complain about their complexity. So at the end it seems people got used to jetpack navigation 🤷🏻‍♂️
I do believe a navigation library is something should be provided first hand. All other UI declarative frameworks provide one solution, swift ui, flutter, react native, jetpack compose so compose multiplatform should offer an off the shelf solution too.
1
💯 1
k

Konstantin Tskhovrebov

12/13/2023, 7:07 PM
The voyager has own screenModel with a life cycle.
1
p

Pablichjenkov

12/13/2023, 8:17 PM
Humm, interesting. Seems that I am outdated. Sounds good then.
h

Hristijan

12/13/2023, 8:36 PM
I've been using https://github.com/Tlaster/PreCompose No issues, similar to Compose Navigation on Android
1
p

Pablichjenkov

12/13/2023, 8:39 PM
I went through the Voyager code and I see it has some lifecycle stuff but as I mentioned this lifecycle by default is tied to the composable lifecycle. There is a sample for Android Integration for a custom lifecycle provider but there is nothing for iOS. And although the integration is not hard, the events don't match one to one.
Yeah PreCompose is the closest you get to jetpack navigation and it has platform lifecycle integration, that is right.
m

McEna

12/14/2023, 3:16 AM
Maybe it is covered by the efforts to make jetpack libraries compatible with KMM?
h

Hristijan

12/14/2023, 3:18 AM
I think that'll be the case as I read somewhere that Google and Jetbrains will be collaborating for this solution
m

McEna

12/14/2023, 3:29 AM
That's logical, otherwise, multiplatform kotlin and compose will compete with Jetpack patterns, and that's detrimental to both
j

Joel Denke

12/14/2023, 6:05 AM
Also curious if JB and Androidx libs aligning, if we will see movement from Googles monorepo AOSP into JB open source or something new. That would make these roadmaps and commitment more transparent I guess. For pure native navigation I recommend using https://slackhq.github.io/circuit/navigation/ for CMP projects. Best library so far I think. Hopefully Slack could help JB and Google, as seems using proper latest androidx APIs. Like predictive back gestures.
b

brabo-hi

12/14/2023, 6:53 AM
@Joel Denke is Circuit multiplatform ?
yes black 2
r

ribesg

12/14/2023, 9:40 AM
I'm also in the "how the hell do you actually do Compose multiplatform" limbo and kinda lost with Voyager, PreCompose, Decompose, Appyx, Circuit, Ballast… Do you just pick one and hope it doesn't die? Wouldn't they basically all die the moment there's a Jetbrains/Google lib?
s

Stylianos Gakis

12/14/2023, 9:43 AM
No why would they die? It’s not like everyone uses androidx.navigation on Android itself even. Many people might just not like the solution JB brings out for navigation. Just pick one and use it, that’s what you should do. After you’ve successfully used one of them you will have a much stronger point to start off of, and you can much better assess what your next one will be, if you are happy with what you chose or if you want to try something else. Before you even pick one of them to use, then all you can do is either guess or hear other people’s opinion about them. But as you can see everyone has their own favorite, there is no “de-facto” nav library because they are all a bit different in various ways. If you really struggle to even just pick one at random, just do something silly like pick the one with the most stars. Or go to previous discussions around them and just hear what people have to say about them.
j

Joel Denke

12/14/2023, 9:45 AM
Even if library deprecated can fork it yourself. Apparently no one likes existing nav solutions and keep adding more 😁
😁 1
r

ribesg

12/14/2023, 9:49 AM
I'm talking more about risk management here. In my case picking the less likely to die lib is more important than picking the coolest or the most user friendly or whatever. It's for an app rewrite, with one strong argument for the rewrite being the current/previous technology isn't future proof… I can't just pick any random lib
👍 1
Important questions would be, which one would be the easiest to migrate from? Or, assuming a potential "official" lib would most likely match android navigation, which of those lib is the closest to android navigation already? If I had to choose based on personal preference I would pick something that more heavily relies on functions rather than classes, but I'm not sure it matters in my case
👍 1
h

Hristijan

12/14/2023, 9:54 AM
Precompose is currently the easier to migrate from, same API surface as the Compose Navigation Component by Google
👍 1
s

Stylianos Gakis

12/14/2023, 10:02 AM
If you are not confident in that if things change that the migration path to the new lib won’t be easy, or that the pick you make won’t be sufficient for use then don’t do it in production until you are confident enough. Do it in a sample project which you are ok with experimenting. Or do exactly that, see which one of the solutions is the least intrusive, aka the one that does not leak everywhere (DI, presenters, inside your UI code etc), so that you know if you need to migrate it’s gonna be easy to do so. PreCompose is indeed the closest one to the androidx API, but that is assuming that you will be migrating to that when it eventually becomes KMP compatible. And that you are willing to wait until that happens. For all we know that could be in 2026, or it could be next month, there’s absolutely no timeline shared with us around this at least as of right now. And we don’t know for sure either that JB will be basically providing androidx.navigation as a KMP lib. It may be that they are only getting inspiration from it but they might provide a completely different API 🤷 It’s all speculation at this point imo.
a

Arkadii Ivanov

12/14/2023, 10:32 AM
Noone can predict when a library will become deprecated. Even Google deprecates things and replaces with newer ones. Of course there will be a replacement and migration guides, but still the API may be completely different. So I would pick one of the libs, or try multiple in a sample project, and then use one. Then maybe migrate to an official one if you find that better.
👍 3
❤️ 1
j

Joel Denke

12/14/2023, 10:35 AM
Make sure decouple your navigation with custom navhost/controller interface. Then doesnt matter if switch. By using that I was able migrate between androidx navigation, circuit, Voyager and decompose very fast. In my case evaluating which one best in my opinion. Impossible evaluate risk. Reduce risk by decouple your code from Android, iOS and library SDKs with good interfaces and architecture and youre fine :)
1
i

Ian Lake

12/14/2023, 10:47 PM
FWIW, in Jetbrains recent roadmap blog post, they did say they are working on a solution for multiplatform navigation: https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/ And that work has included us (the androidx.navigation team) talking with them directly, as mentioned here: https://twitter.com/ianhlake/status/1725225989943464234
🙌 1
thank you color 2
🔥 1
p

Pablichjenkov

12/14/2023, 10:54 PM
Not to say that the 3rd parties aren't great. Indeed they are but as a comment mentioned above, other things like maintainability, licencing, support are to consider. And nothing better for that than a first hand solution.
i

Ian Lake

12/14/2023, 10:55 PM
You'll want to +1 the official issue in the issue tracker for multiplatform support in Navigation Compose if that's something you're interested in: https://issuetracker.google.com/issues/281774647
p

Pablichjenkov

12/14/2023, 10:56 PM
+1 Did it in the past already yeup
i

Ian Lake

12/14/2023, 10:57 PM
But yes, lots of choice. There's absolutely no requirement to use any particular navigation library - that's one reason why it is part of androidx.navigation and not hosted directly as part of androidx.compose itself - it is just one of my totally valid choices to choose from 🙂
👍 1
m

McEna

12/14/2023, 11:01 PM
Are those blockers dependencies on external teams, or is it just a bandwith/priority issue? Also, would you take contributions for those?
b

brabo-hi

12/15/2023, 6:09 AM
I think android compose navigation is the best way to go, it will be easy to migrate web based app. However it needs to review the way it handles argument type, deep linking, the code could be more simpler
👍 1
7 Views