Is it possible for a composable that's always part...

# compose

[Chuck Stein]

Is it possible for a composable that's always part of our UI tree to leave the composition and then re-enter, without the "on resume" lifecycle callback being called?

[Chuck Stein]

Asking because I have a timer composable with an "initial value in seconds" param, that hooks into OnResume to recalculate the current time displayed (using a callback to the ViewModel), whenever it may have left the composition due to process death or activity recreation. We need to ensure the timer always reflects the seconds elapsed since the static start time (which is stored in the ViewModel), but I'm wondering if there are other scenarios in which it could leave and re-enter the composition, but OnResume is not called, in which case we'd lose the current display time (which is local state inside the timer)

[Stylianos Gakis]

Sounds like something that you want to live outside of your UI scope, and simply have the UI orchestrate when it starts/end instead of being the one creating this timer in the first place?
A composable doesn’t really know anything about the Android onResume and such, it may leave composition simply because a recomposition happens where it’s on the non-active side of an if/else statement, or navigation happens and it’s no longer on the tree and so on.

[Chuck Stein]

Yeah, I agree it would be ideal if the domain layer was responsible for increasing the current time in seconds every second, and publishing that as state for the UI to consume. But the time-incrementing loop is already implemented inside a LaunchedEffect in the UI layer, hooking into LocalLifeycle to update this time whenever OnResume is called, by calling back to the ViewModel, which is the source of truth for the start time. So we want to avoid refactoring to move that to the domain layer if possible.