I know from the navigation compose library, the gu...

# compose-android

[agrosner]

I know from the navigation compose library, the guidance is not to use fragments rendered in compose. but the interoperability APIs supply a section on Fragments in compose. what are the downsides of making a composable route using this mechanism (outside of boilerplate)? we have a large app 400 modules where our current navigation is fragment based. We can continue with that, and migrate to regular navigation library. However, we’d love to make use of compose to compose navigation, since most of our customer facing screens will move to compose, and want to eventually make use of shared element transitions.

[Stylianos Gakis]

Wouldn’t it be simpler for you to continue with the fragment based navigation solution for now, continue migrating all of your fragments to compose, and at the point where all of your fragments are only wrappers around a composable you can do a switch all together into using compose instead?
In any case, shared element transitions aren’t there for compose nav yet, and I doubt it’s coming super soon either.

[agrosner]

Yeah that is an option. Also want the actual container of the app (tabs) and content to be composed based as well inside of it

[agrosner]

We have so many fragments that are also legacy ones that won’t be migrated for some time

[Stylianos Gakis]

If they're (realistically) never going to be migrated then I'd say give it a try and use compose navigation with some of them just inflating a fragment. If you do I'd be curious to hear how that goes for you.
Also for the point of shared element you're talking about, how are you planning to make that work? Just wait until the compose apis let you do that?

[agrosner]

Yeah essentially wait until compose has those apis

[Stylianos Gakis]

Then might as well not do anything yet because those apis may come much later and you'll be forced to use whatever exists in the View world atm. Which I've never done myself but I know they exist at least 😅

[Stylianos Gakis]

https://android-review.googlesource.com/c/platform/frameworks/support/+/2989182
Might be your lucky day, better support if you go with the compose nav wrapping some fragments in the legacy destinations

[agrosner]

Oh my gosh!!! Yesss

[Stylianos Gakis]

Just gotta wait a few months for the stable release 😅
But it kinda gives you the go to start that approach if you want to.
And honestly till then you can copy-paste the code into your project until this lands, that way you also avoid alpha dependencies

[Ian Lake]

You beat me to posting that link ha. Note that there's a big caveat there: only the saved state of the Fragments is saved, ViewModels within the Fragment won't survive the AndroidFragment being removed from composition (e.g., like if the composable destination goes onto the back stack)

[Ian Lake]

That's true for the AndroidViewBinding integration now too, so if that's been fine for you, this will be similar in that respect

[Ian Lake]

FWIW, there's also https://issuetracker.google.com/265480755 in which we're looking at for adding composable destinations to your Navigation with Fragment's navigation graph

[agrosner]

Ah thanks Ian. Our app is using viper and fragment scoped dependencies for legacy screens so should be mostly safe 🤗

[Ian Lake]

We are also looking at the other direction too - using that new AndroidFragment to let you write fragment destinations in your NavHost (where it would just use AndroidFragment as the UI of your individual destination)

[agrosner]

Yes that would be ideal. We want to behind a feature toggle swap out our view based tabs screen and fragment pushing architecture with a compatible layer but allow compose first screens to directly render without a wrapper fragment. But legacy screens to also continue to work with fragments

[Ian Lake]

With how completely independent the animation systems between the View and Compose worlds are, you'll need to choose which world you want to fully embrace - hopefully things like AndroidFragment and the Navigation things mentioned above will make it easier to transition between Navigation with Fragments and Navigation Compose when it makes sense for your app

[Ian Lake]

I will note that AndroidFragment is not planning on being part of the currently Fragment 1.7 release, but as part of a future Fragment 1.8 release and it does require new public APIs added to FragmentManager and FragmentTransaction to work, so it won't be something you can necessarily copy/paste - you'll need to use Fragment 1.8 releases in any case

[Stylianos Gakis]

If you do

composable<Destination> {
  val viewModel by hilt/koin/whateverViewModel()
  AndroidFragment()
}

Will you get the right restoration on your VM, since it’s not inside the fragment? Going around this limitation?

[Ian Lake]

Yes, that would work fine

[Stylianos Gakis]

Well, there you have it, I think that’s what I’d do then honestly, sounds like the perfect workaround until this is done

[Ian Lake]

Yeah, really the animations between screens is going to be the tipping point on which one you choose - do you use Fragment/View APIs for your transitions (and the shared elements they support between Views) or do you swap to NavHost and write your transitions in Compose (and lose shared elements between Views forever and not have shared elements between Composables for a bit longer)

[Stylianos Gakis]

Depending on what “a bit longer” really will be is gonna definitely be a big factor in my opinion on this.
I know the team is hard at work and that demos already have been shown with shared elements + compose and so on, but I think it’d make sense if they are doing a big architectural decision now to know if this timeline is < 3 months, < 6 months or 6+ or something like that.

[agrosner]

Yeah I’m hoping we can make use of shared element transitions eventually when they’re ready. Right now we jump between compose and view based screens almost all the time, so we can’t support them anyways in medium term

[Stylianos Gakis]

If I knew it’s 6-12 or more months away for example, and I knew that we want shared elements support now, I’d delay the migration for now

[Ian Lake]

If you don't use shared elements with Fragments and don't use ViewModels in Fragments, then yeah, you don't really have anything to lose, tbh. AndroidViewBinding is still quite good for a single static fragment, just has the cost of requiring you write that one XML file per screen (which will go away when you can use AndroidFragment)