https://kotlinlang.org logo
#compose-android
Title
# compose-android
a

agrosner

03/12/2024, 3:22 PM
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.
s

Stylianos Gakis

03/12/2024, 4:47 PM
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.
a

agrosner

03/12/2024, 8:59 PM
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
We have so many fragments that are also legacy ones that won’t be migrated for some time
s

Stylianos Gakis

03/12/2024, 9:27 PM
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?
a

agrosner

03/12/2024, 9:48 PM
Yeah essentially wait until compose has those apis
s

Stylianos Gakis

03/12/2024, 10:08 PM
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 😅
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
a

agrosner

03/13/2024, 10:02 PM
Oh my gosh!!! Yesss
🦜 1
s

Stylianos Gakis

03/13/2024, 10:03 PM
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
i

Ian Lake

03/13/2024, 10:30 PM
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)
🏃 1
That's true for the
AndroidViewBinding
integration now too, so if that's been fine for you, this will be similar in that respect
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
2
a

agrosner

03/13/2024, 10:37 PM
Ah thanks Ian. Our app is using viper and fragment scoped dependencies for legacy screens so should be mostly safe 🤗
👍 1
i

Ian Lake

03/13/2024, 10:39 PM
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)
a

agrosner

03/13/2024, 10:43 PM
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
i

Ian Lake

03/13/2024, 10:47 PM
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
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
👍 1
s

Stylianos Gakis

03/13/2024, 10:49 PM
If you do
Copy code
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?
i

Ian Lake

03/13/2024, 10:49 PM
Yes, that would work fine
s

Stylianos Gakis

03/13/2024, 10:50 PM
Well, there you have it, I think that’s what I’d do then honestly, sounds like the perfect workaround until this is done
i

Ian Lake

03/13/2024, 10:51 PM
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)
s

Stylianos Gakis

03/13/2024, 10:54 PM
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.
a

agrosner

03/13/2024, 10:55 PM
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
s

Stylianos Gakis

03/13/2024, 10:55 PM
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
i

Ian Lake

03/13/2024, 11:00 PM
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
)
👍 1
4 Views