https://kotlinlang.org logo
Join Slack
Powered by
What role do Fragments (and to a lesser extent, th...
# compose
z
What role do Fragments (and to a lesser extent, the Navigation Component) play in a 
@Compose
world?
a
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
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
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
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
TBD. Probably something along the lines of 
@Composable (???) -> Unit
function objects as part of the destinations rather than fragment names or factories
👍 2
z
Ah gotcha, I would be curious how observing a `ViewModel`’s 
Flow<State>
would play into that without a 
Fragment
a
so as you construct the destinations in the graph you'd be doing things like 
ComposableDestination(???, ::MyScreenComposable)
👍 1
z
like technically I don’t think we care about 
Fragment
- just the 
LifecycleOwner
of it’s view
a
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
what’s an 
ambient
😆
a
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
10 Views
Open in Slack
PreviousNext
Powered by