https://kotlinlang.org logo
#compose
Title
# compose
z

zak.taccardi

04/13/2020, 3:38 PM
What role do Fragments (and to a lesser extent, the Navigation Component) play in a
@Compose
world?
a

Adam Powell

04/13/2020, 4:30 PM
As much of one as you would like, especially depending on whether you're introducing compose into an existing codebase or writing more green field code
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
and it's also an easy way to mix compose and existing navigation destinations
you don't strictly need fragments though; if they aren't helping you solve a problem, don't use them
👍 2
z

zak.taccardi

04/13/2020, 4:33 PM
I’m looking in the context of a fresh app (no legacy code) and looking for general best practices
I’ve heard the Compose obviates the need for fragments entirely, but I haven’t used Compose yet so I can’t put that test to claim
more context: my team is looking to leverage Navigation Component and possibly introduce it into our codebase and I want to know if that would still be worth the investment once
@Compose
is out
a

Adam Powell

04/13/2020, 4:39 PM
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.
👍 2
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.
👍 1
we might do a compose-fragment artifact sooner rather than later just to have a standard version of this out there, kind of like how we just added LiveData/RxJava2 integrations
👍 3
z

zak.taccardi

04/13/2020, 4:42 PM
oh gotcha. So usage of
NavigationComponent
would not change all to much then?
Though if we aren’t using `Fragment`s anymore, how are different
@Compose
UI’s (navigation destinations) isolated from one another?
a

Adam Powell

04/13/2020, 4:49 PM
TBD. Probably something along the lines of
@Composable (???) -> Unit
function objects as part of the destinations rather than fragment names or factories
👍 2
z

zak.taccardi

04/13/2020, 4:50 PM
Ah gotcha, I would be curious how observing a `ViewModel`’s
Flow<State>
would play into that without a
Fragment
a

Adam Powell

04/13/2020, 4:50 PM
so as you construct the destinations in the graph you'd be doing things like
ComposableDestination(???, ::MyScreenComposable)
👍 1
z

zak.taccardi

04/13/2020, 4:51 PM
like technically I don’t think we care about
Fragment
- just the
LifecycleOwner
of it’s view
a

Adam Powell

04/13/2020, 4:54 PM
right. You may or may not strictly need it; composables have their own commit/dispose lifecycle that is easy enough to get at, but that doesn't give you the visibility implied in start/stop.
I think the LifecycleOwner as exposed by
ViewTreeLifecycleOwner
is available in current builds though
👍 1
or if it's not there yet it will be soon enough via an ambient
👍 1
z

zak.taccardi

04/13/2020, 4:56 PM
what’s an
ambient
😆
it's a composition tree-based service locator, or in other words, a tree-scoped hash table that's always available.
👍 1
kinda like a react context, but that term is a bit overloaded on android 😄
same mechanism that's used for the
MaterialTheme
properties
👍 1
2 Views