Thread
#compose
    Adriano Celentano

    Adriano Celentano

    1 year ago
    what would be the most simple infinite loop for an infinite animation ? is it possible to animate without reading a state ?
    Adam Powell

    Adam Powell

    1 year ago
    That's still reading changing state though
    I'm curious what motivated the question about animation without reading state
    Doris Liu

    Doris Liu

    1 year ago
    If you'd like to minimize the state reads, you could consider the coroutine-based animations. The simplest is
    suspend fun animate(...)
    : https://developer.android.com/reference/kotlin/androidx/compose/animation/core/package-summary#animate. But even this has a bunch of state reads (of the internally created states). I'd be curious what's the motivation for that preference as well. 🙂
    Adriano Celentano

    Adriano Celentano

    1 year ago
    Im a bit ashamed to show my hacky game of life code 😅 https://gist.github.com/AdrianoCelentano/c65c58a65b63489821777dba042633cb • I have a some top level properties, which hold a Grid of Cells • a Cell can be alive or dead • each round i need to refresh the alive/dead state of each cell and when each cell state was updated draw each cell again my hacky idea of doing it was just to increase the round count infinitely, but i didnt need to read the round count state anywhere. (although updating my cell grid state in the in the composable functinon is probably even more hacky and causes to many updates 😅) Will fix it and put my cell grid state in a compose state. I think this coroutines based animation will help me, to update my cell grid state. Will write here again if it worked out
    Made this video so u can imagine how it looks, with the currrent implementation
    so this works fine, it just doesnt give me a delay in between each draw (which actually seems fine in my case) I could make the delay timing myself via coroutines, but i thought i should use an AnimationClock somehow.
    LaunchedEffect(Unit) {
                        animate(
                            initialValue = 0f,
                            targetValue = 1f,
                            animationSpec = infiniteRepeatable(
                                animation = tween(1000, easing = LinearEasing),
                                repeatMode = RepeatMode.Restart
                            )
                        ) { _, _ ->
                                cellGrid.value = calculateNextGrid(cellGrid)
                        }
                    }
    Doris Liu

    Doris Liu

    1 year ago
    so this works fine, it just doesnt give me a delay in between each draw (which actually seems fine in my case)
    Glad you gave it a try! 👍 How would you like the delay to work in your case?
    I could make the delay timing myself via coroutines, but i thought i should us an AnimationClock somehow.
    withFrameNanos/Millis
    is the new AnimationClock. If you need to manipulate the timeline of an animation, you could go one level lower and use the combination of withFrameMillis + TargetBasedAnimation . That would give you more control with more code. 🙂 This combo is actually the implementation under the hood for all compose animation APIs (that manage their own lifecycle).
    Adriano Celentano

    Adriano Celentano

    1 year ago
    super thank you 🙏 will give it a try
    my idea was to have sth like this draw() -change state - wait 300ms - draw() - ….
    Doris Liu

    Doris Liu

    1 year ago
    As in, draw every 300ms (i.e. show change at the rate of ~3fps)? For that you could either animate during that time and not draw, or use the combo suggested above to update the animation once every 300ms. The latter is more efficient. 🙂
    Adriano Celentano

    Adriano Celentano

    1 year ago
    is there sth bad about this approach ?
    LaunchedEffect(Unit) {
                        while (true) {
                            cellGrid.value = calculateNextGrid(cellGrid)
                            delay(300)
                        }
                    }
    Doris Liu

    Doris Liu

    1 year ago
    That looks fine. Since the calculation is fairly light, the vast majority of the time in the loop is waiting on
    delay
    , which is cancellation cooperative. Wouldn't hurt to make it
    while(isActive)
    , but not super critical.
    Adriano Celentano

    Adriano Celentano

    1 year ago
    i see that makes sense thx 👍