With `Navigation3`. do you see a way to adopt it incrementally? Or does it have to be an atomic chan...

# compose

[ursus]

With Navigation3. do you see a way to adopt it incrementally? Or does it have to be an atomic change for all of the 100 screens in my app?

[Hristijan]

If you had your previous navigation set-up decoupled from your architecture and made it so that it doesn't pull itself into your UI screens/sub screens, the change should be easy like systematic replacement of the way your screens are rendered.

I have that in my personal apps and work apps, but we're waiting for navigation 3 to stabilize and have deep links since we have those, a lot.

[ursus]

easy sure but it has to be atomically applied everywhere right? no way to have 2 nav libs at the same time?

[Stylianos Gakis]

Yeah, you'd be asking yourself for trouble otherwise I'm pretty sure.
But what Hristijan is saying is important. You should optimally have everything setup in a way where changing the nav lib should be just one sweep of the glue code. The screens themselves should optimally not need to do something themselves.

I am also waiting for deeplink support btw, along with navigateUp etc before I even consider such a migration

[ursus]

Well im coming from Fragments (with comppse as a detail of the screen)

Just checking how to go about it

thanks

[mattinger]

Atomic, no, but mixing xml and compose based navigation comes with a lot of headaches. But you could create fragment destinations in your xml based graph, and within those fragments, have a compose based navigation graph. It gets hairy though how to handle the pop and deep link mechanics if you try to do this though.

[mattinger]

That said, I'm glad Nav3 took a more data driven approach, rather than an imperitive approach (modelling the backstack as data, rather than backstack entries, and having navigation functions).