k

    Kevin Hester

    2 years ago
    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

    Leland Richardson [G]

    2 years ago
    is there something specific that you’re talking about here?
    k

    Kevin Hester

    2 years ago
    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"
    l

    Leland Richardson [G]

    2 years ago
    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

    Kevin Hester

    2 years ago
    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

    Leland Richardson [G]

    2 years ago
    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
    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

    Kevin Hester

    2 years ago
    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

    Leland Richardson [G]

    2 years ago
    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

    Kevin Hester

    2 years ago
    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

    Leland Richardson [G]

    2 years ago
    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

    Kevin Hester

    2 years ago
    l

    Leland Richardson [G]

    2 years ago
    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
    k

    Kevin Hester

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

    Leland Richardson [G]

    2 years ago
    looks like it
    k

    Kevin Hester

    2 years ago
    and it does! thanks.
    l

    Leland Richardson [G]

    2 years ago
    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
    k

    Kevin Hester

    2 years ago
    thanks. gotcha!