https://kotlinlang.org logo
Join Slack
Powered by
Hi ya'll any guess when the Compose support for be...
# compose
k
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.
l
is there something specific that you’re talking about here?
k
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
Copy code
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"
l
when you say onShown/onHidden, are you specifically referring to actual visibility to the user? like “can the user see this pixel right now?”
k
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)
l
i see
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
👍 1
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
in particular, a lot of folks want this for logging infrastructure
it also makes a lot of sense to use to trigger certain data retrieval operations etc. as well
k
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"
l
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
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
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
k
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.
l
well “is it in the hierarchy” is what 
onCommit
provides
but that is different than “in the hierarchy, and bounds are inside the screen’s bounds”
which is also different from “in the hierarchy, in the screen’s bounds, and not being occluded by any other view”
k
l
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
👍 1
k
oh! this project all began as copypasta from some demo. So if I remove crossfade onCommit will work closer to what I want!
l
looks like it
k
and it does! thanks.
l
just keep in mind the behavior of that component…. if i had
Copy code
if (x) { Foo() } else { Bar() }
and then
Copy code
@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
k
thanks. gotcha!
3 Views
Open in Slack
PreviousNext
Powered by