Ah gotcha, `+observe` isn’t quite I was hoping for...
# compose
c
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
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
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
Well, that observe is bound to the
viewModel
a
Where, did I miss it in the gist elsewhere? It looks like it's an observeForever in the commit/dispose of the effect
l
My bad
would it be better to use
observe
on
LiveData
providing the correct
LyfeCycleOwner
?
a
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
So, from what you said above:
onCommit
,
onDispose
are not bound in any way to the
Activity
lifecycle, are them?
a
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
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
Would my solution posted above:
use
observe
on
LiveData
providing the correct
LyfeCycleOwner
work as well?
Instead of
observeForever
l
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
Sure, I didn’t plan to get rid of the
onDispose{}
, just change the
subscribeForever
l
yep
l
👍🏼
l
that’s fine. if you call
disposeComposition
in the right places, then it would do the same thing and wouldn’t be needed.