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

Cody Engel

10/24/2019, 5:32 AM
Ah gotcha,
+observe
isn’t quite I was hoping for, making the entire ViewModel observable with
@Model
was more what I was hoping for. I don’t think
+observe
currently exists as part of the Canary build either? Android Studio at least can’t recognize it on my end. I’ll try to stop by the office hours tomorrow to talk it through a bit more. Thanks again for all of the help and sorry for bugging ya at 10:30 at night 😅
l

Luca Nicoletti

10/24/2019, 7:43 AM
At the end of the gits 🙂
Came out long time ago on Twitter in a thread between me & @Leland Richardson [G] https://twitter.com/luca_nicolett/status/1134150695400157185
a

Adam Powell

10/24/2019, 12:52 PM
That version of observe is probably fine for this super early phase but a more production grade version would need to tie into either the real host lifecycle or window visibility or similar as a proxy for it. It's really easy to get subscriptions that keep running when your app is in the background but the process container is still active
l

Luca Nicoletti

10/24/2019, 12:53 PM
Well, that observe is bound to the
viewModel
a

Adam Powell

10/24/2019, 12:56 PM
Where, did I miss it in the gist elsewhere? It looks like it's an observeForever in the commit/dispose of the effect
l

Luca Nicoletti

10/24/2019, 12:56 PM
My bad
would it be better to use
observe
on
LiveData
providing the correct
LyfeCycleOwner
?
a

Adam Powell

10/24/2019, 1:04 PM
Yeah. We're probably going to have a standard ambient hold the most local LifecycleOwner but it's just not there yet. There was some related work planned to have both fragments and jetpack's ComponentActivity base class stash the LifecycleOwner in a root view tag similar to the way the navigation library does with the navigation controller, which would give a natural onboarding point for compose to expose it as an ambient
And then it could be consumed by effects like this one
l

Luca Nicoletti

10/24/2019, 1:06 PM
So, from what you said above:
onCommit
,
onDispose
are not bound in any way to the
Activity
lifecycle, are them?
a

Adam Powell

10/24/2019, 1:26 PM
I don't recall the exact implementation offhand. iirc it'll be disposed when the activity is destroyed if you use the
setContent {
helper but it won't stop and restart subscriptions based on started/stopped state
Some of that still has a big
TODO
on it 🙂
And it'll be a lot easier once we can have suspending effects and just
Flow.collect
in one without worrying
👍 1
l

Leland Richardson [G]

10/24/2019, 4:58 PM
that implementation uses the lifecycle of composition, so when the Composable using the
+observe
call is removed from the hierarchy, so will the subscription
right now you need to call
disposeComposition
at the activity level if you want compose to properly clean up after itself though
but i’m confident that this will go away as a requirement
l

Luca Nicoletti

10/24/2019, 4:59 PM
Would my solution posted above:
use
observe
on
LiveData
providing the correct
LyfeCycleOwner
work as well?
Instead of
observeForever
l

Leland Richardson [G]

10/24/2019, 5:11 PM
sure.. that would work just fine, but you still want to make sure to unsubscribe explicitly in onDispose
since the LifecycleOwner does not know when the composable using observe gets removed from the tree
l

Luca Nicoletti

10/24/2019, 5:11 PM
Sure, I didn’t plan to get rid of the
onDispose{}
, just change the
subscribeForever
l

Leland Richardson [G]

10/24/2019, 5:11 PM
yep
l

Luca Nicoletti

10/24/2019, 5:11 PM
👍🏼
l

Leland Richardson [G]

10/24/2019, 5:12 PM
that’s fine. if you call
disposeComposition
in the right places, then it would do the same thing and wouldn’t be needed.
3 Views