Hi ya'll any guess when the Compose support for better lifecycle awareness will drop? I'd eagerly u...

# compose

[Kevin Hester]

Hi ya'll any guess when the Compose support for better lifecycle awareness will drop? I'd eagerly use it (though currently onCommit and misc onStop glue is working fine.

[Leland Richardson [G]]

is there something specific that you’re talking about here?

[Kevin Hester]

sure. In my case, I'm doing stuff with hw so I have 'classic' android type services I need to start/stop based on which views are visible.

I used ya'lls good advice to use onActive, which got me part of the way there. Though even when other screens were visible (and this component was no longer visible) I would see the following line getting invoked repeatedly: https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/ui/BTScanScreen.kt#L69

So I changed to

onCommit(AppStatus.currentScreen)

instead on onActive (on line 68) and that was quite a bit better, though the onCommit closure still gets run after this screen has been deselected (once) which is not really ideal. So ideally I would have some sort of hook so I could get my closure invoked for "onShown" or "onHidden"

[Leland Richardson [G]]

when you say onShown/onHidden, are you specifically referring to actual visibility to the user? like “can the user see this pixel right now?”

[Kevin Hester]

yeah (because when not visible to the user right now, I'd like to stop background services from burning CPU to generate data the user won't be looking at)

[Leland Richardson [G]]

i see

[Leland Richardson [G]]

yeah i think there has been some talk about working on some first-class APIs for this. it’s not trivial though (depending on what you want the guarantees of the API to be). It’s been brought up by some other folks as well

[Leland Richardson [G]]

if you weren’t aware of it already, OnPositioned is an API that can get you part of the way there right now, but it gets called a lot more than you’d want obviously

[Leland Richardson [G]]

in particular, a lot of folks want this for logging infrastructure

[Leland Richardson [G]]

it also makes a lot of sense to use to trigger certain data retrieval operations etc. as well

[Kevin Hester]

yep. also pretty much a requirement for analytics that wants to say "user looked at screen X for 10 seconds then screen Y for 30 seconds after clicking on Z"

[Leland Richardson [G]]

i believe in the use case, but i think there might still be some uncertainty around what the right primitive api to expose would be, and if some of this would be better built in user-land on top of those APIs

[Leland Richardson [G]]

right now onCommit/onActive/etc are all compose-runtime-specific APIs. and the runtime itself has absolutely no notion of what “on screen” would mean. It only knows if its in the hierarchy or not

[Leland Richardson [G]]

but there’s questions like if we should factor in clipping and layers drawing on top of other layers or not, which would make these types of calculations more accurate but also more expensive

[Kevin Hester]

I think that just "is it in the current 'view' hierarchy at all (as opposed to hidden by layers or clipping" would handle my limited case. But I hear what you are saying.

[Leland Richardson [G]]

well “is it in the hierarchy” is what onCommit provides

[Leland Richardson [G]]

but that is different than “in the hierarchy, and bounds are inside the screen’s bounds”

[Leland Richardson [G]]

which is also different from “in the hierarchy, in the screen’s bounds, and not being occluded by any other view”

[Kevin Hester]

especially when a very common use-case is to be underneath something like: https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/ui/MeshApp.kt#L142

[Leland Richardson [G]]

the reason onCommit isn’t working for you there is because Crossfade has an implementation which keeps the “old hierarchy” around while it is animating it out

[Kevin Hester]

oh! this project all began as copypasta from some demo. So if I remove crossfade onCommit will work closer to what I want!

[Leland Richardson [G]]

looks like it

[Kevin Hester]

and it does! thanks.

[Kevin Hester]

also thanks: https://github.com/meshtastic/Meshtastic-Android/blob/master/app/src/main/java/com/geeksville/mesh/ui/Analytics.kt

[Leland Richardson [G]]

just keep in mind the behavior of that component…. if i had

if (x) { Foo() } else { Bar() }

and then

@Composable fun Foo() { analyticsScreen("foo") ... }

This is going to call onCommit every time foo is added/removed from the tree, which will happen every time x changed

[Kevin Hester]

thanks. gotcha!