Ah gotcha, `+observe` isn’t quite I was hoping for, making the entire ViewModel observable with `@Mo...

# compose

[Cody Engel]

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 😅

[Luca Nicoletti]

Here’s the +observe you’re looking for https://gist.github.com/lnicolet/b34ad41ef4a06b1161e1eb77cfb1163f#file-mvijetpackcomposeactivity-kt

[Luca Nicoletti]

At the end of the gits 🙂

[Luca Nicoletti]

Came out long time ago on Twitter in a thread between me & @Leland Richardson [G] https://twitter.com/luca_nicolett/status/1134150695400157185

[Adam Powell]

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

[Luca Nicoletti]

Well, that observe is bound to the viewModel

[Adam Powell]

Where, did I miss it in the gist elsewhere? It looks like it's an observeForever in the commit/dispose of the effect

[Luca Nicoletti]

My bad

[Luca Nicoletti]

would it be better to use observe on LiveData providing the correct LyfeCycleOwner?

[Adam Powell]

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

[Adam Powell]

And then it could be consumed by effects like this one

[Luca Nicoletti]

So, from what you said above: onCommit, onDispose are not bound in any way to the Activity lifecycle, are them?

[Adam Powell]

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

[Adam Powell]

Some of that still has a big TODO on it 🙂

[Adam Powell]

And it'll be a lot easier once we can have suspending effects and just Flow.collect in one without worrying

[Leland Richardson [G]]

that implementation uses the lifecycle of composition, so when the Composable using the +observe call is removed from the hierarchy, so will the subscription

[Leland Richardson [G]]

right now you need to call disposeComposition at the activity level if you want compose to properly clean up after itself though

[Leland Richardson [G]]

but i’m confident that this will go away as a requirement

[Luca Nicoletti]

Would my solution posted above:

use observe on LiveData providing the correct LyfeCycleOwner

work as well?

[Luca Nicoletti]

Instead of observeForever

[Leland Richardson [G]]

sure.. that would work just fine, but you still want to make sure to unsubscribe explicitly in onDispose

[Leland Richardson [G]]

since the LifecycleOwner does not know when the composable using observe gets removed from the tree

[Luca Nicoletti]

Sure, I didn’t plan to get rid of the onDispose{}, just change the subscribeForever

[Leland Richardson [G]]

yep

[Luca Nicoletti]

👍🏼

[Leland Richardson [G]]

that’s fine. if you call disposeComposition in the right places, then it would do the same thing and wouldn’t be needed.