https://kotlinlang.org logo
Join Slack
Powered by
Does anyone see a incremental migration from `Frag...
# compose
u
Does anyone see a incremental migration from `Fragment`s to 
Nav3
? (assuming all of the actual ui is already in compose)
e
Migration from Fragment navigation with Nav2? Or just from Fragments? For the latter, you dont need migration, just compose your fragments within your UI using 
AndroidFragment(...)
combined with your fragment manager, that should work. For strategies around moving from Nav2 to 3 I think there is some guidance out there but specifically for fragments, I would say, wrap your old “destination” type in some sort of 
NavKey
and implemnet the entry provider for that NavKey to resolve the destination into the actual fragment class then use 
AndroidFragment
u
Just Frag to Nav3 as written AndroidFragment sure, but what about navigation already there? (frag to frag)
e
What do you mean by frag to frag navigation? If you have places in your codebase where you do 
supportFragmentManager.beginTransaction()...commit()
, of course those need to be removed or changed
u
yes those exactly, do you see an incremental way?
e
There isn’t. You have to change all of them. What I would do, personally, is create some interface that matches the subset of the contract/API of the FragmentManager that I use, then the implementation would delegate to my Navigator/BackStack
u
hm, can you share the shape of it? I'm not sure how would you do away with the target fragment constructors
e
Not at computer atm so I cant really.
Copy code
interface InteropFragmentManager {
  fun beginTransaction(): InteropTransaction
}

interface InteropTransaction {
  fun add(...): InteropTransaction
  fun remove(...): InteropTransaction
  fun commit()
}
u
the issue here is what do you pass into the add function
e
You will also need
Copy code
class FragmentNavKey<T: Fragment>(
  val cls: KClass<T>,
  val args: Bundle = Bundle.EMPTY,
)
> the issue here is what do you pass into the add function The same thing that the android fragment manager takes in today
You want to mirror the API and adapt it to your BackStack
u
well then you need to pass in args, class literal is not enough
e
Yes, I was typing fast so I didnt specify everything.
u
but okay thank you
e
Like I said I’m on mobile
Its not exactly 1 to 1 since with normal fragment manager you are (probably) working with instances meanwhile with Nav3 you are working with keys (essentially factories)
u
i dont think this will work well, as what you propose needs the fragment-ish naventries already registered so the navkey can find them - which means they need to exist, all of them, so its not incremental - and at that point you might as well skip the interop
😕
e
No. Just register one key, which is the fragment key above. The actual fragments will be handled by the fragment manager and 
AndroidFragment
u
hmm interesting
e
image.png,image.png
This is from my mobile platform implementation based on Nav3 (we use our APIs so that we dont depend directly on Nav3) but its the exact thing. This way teams still using Fragments can easily move to our new architecture without much disruption.
u
yes but means I need to drop all the 
newInstance
static functions and make bundle keys public, but that's doable
nice
e
> yes but means I need to drop all the 
newInstance
static functions Yes, absolutely. You dont need to make the keys public. Just add/replace the function with an 
newInstance
that returns a Bundle instead. That way the keys are still encapsulated and the bundle itself is opaque and can be changed later without worry.
17 Views
Open in Slack
PreviousNext
Powered by