One Off the Slack: Fragments and Compose
On 13 April 2020, Zak Taccardi asked:
What role do Fragments (and to a lesser extent, the Navigation Component) play in a
@Composeworld?
While in the long term fragments may or may not be necessary, they are a useful piece in the short term, as Google’s Adam Powell noted:
Fragments make a pretty good host for a larger chunk of compose UI, you get lifecycle management and coarse-grained integration next to other fragments
it’s an easy way to integrate with the navigation arch component until a compose-specific navigator exists for it
When Zak asks about the relevance of the Navigation component, Adam points out that the plan is for Navigation to support Compose:
yeah our intention is to provide a compose Navigator for the navigation arch component. It was designed to not be fragment-specific. There’s a lot of tooling work that we’d like to have around it in android studio to call it a product on par with the current experience, so it’s probably going to be a post-compose 1.0 thing, but nothing should stop you from writing your own in the meantime if you don’t need that tooling integration yet.
until then though, you should be able to use some very thin fragment wrappers for the screens and call straight into compose from there. This being pretty straightforward is part of the reason the direct navigation component integration is not top priority just yet.
Adam hints at a possible compose-fragment artifact that might standardize
an approach for this, “sooner rather than later”, so we’ll need to keep an eye
out for that!
Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!