Is there a hook for when a composable reappears on the screen? Looking for something like `onResume`...

# compose

[zsperske]

Is there a hook for when a composable reappears on the screen? Looking for something like onResume vs onStart in fragment land. Or am I thinking about this completely wrong?

[Adam Powell]

We're evaluating a few different possibilities for recommendations here. What's your use case? It'll help us tune things for you

[zsperske]

User submits a new item to a collaborative list, when we return to the list page, we want to refresh the list with whatever else other users have added

[Ian Lake]

TBH, that sounds like both should be accessing the same shared repository that serves as the single source of truth. Then changes to that source of truth (your new item being added) would automatically trigger a refresh

[zsperske]

what if the user isn't taking action other than navigating backwards?

[zsperske]

but a prior page has been updated by another users action

[Ian Lake]

What is your source of truth? That should be driving state changes. You don't need a refresh action if your list page is already collecting a flow containing the list of items, etc. as that would already be refreshed at the appropriate time when the user returns to that screen

[zsperske]

Each of my composables has a view model which is updated by a controller in response to ui events. those talk to firestore via an interactor (or use case depending on your definition) to perform updates

[zsperske]

i could be using the realtime update functionality of firestore to achieve what you're saying but should everyone have to have something socket-like?

[Ian Lake]

I think the 'state drives your UI' based approach of reactive UI toolkits means that almost every source your view model provides should be a Flow or something else that automatically pushes updates to your UI layer as your underlying data changes

[zsperske]

yup it is, I'm just getting hung up on the events to trigger updates. is there a "back pressed" equivalent? because unless I'm misunderstanding, in order for the UI to respond to external events, I would need a socket (or some equivalent) open?

[Ian Lake]

I thought you said 'the user submits a new item to a collaborative list' - that sounds like you already have an explicit signal from the user that triggers your insert?

[zsperske]

yeah for that use case definitely I do. but I'm also considering how to handle a user doing some unrelated task/not completing a task and hitting back n number of times, and refreshing the pages they return to

[Ian Lake]

If they're all observing whatever their source of truth is, don't they always have the latest view of their world?

[zsperske]

yeah, am I thinking about this wrong? I'm drawing a line in my head between the state which lives on the device and that which lives elsewhere. should I be designing this in a way that there is no line?

[Ian Lake]

If you're using Firestore, then there really is no line as I understand it - it is already a cloud based, locally cached data source

[zsperske]

yeah you have the option of polling firestore or you can listen for updates. up till now I'd only been listening in handful of places and polling elsewhere. guess its time to commit! thanks for your thoughts

[Adam Powell]

Avoid polling for sure, but the need for subscription lifetime control for relevant data streams is heard loud and clear, thanks 👍

[zsperske]

thank you guys for what you're doing! can't fully express how excited I am to be using compose

[Adam Powell]

thanks! 😄 we're excited for it too!