hey guys, i’m migrating an `animatedFloat` to `rem...

# compose

[Chris Grigg]

hey guys, i’m migrating an animatedFloat to remember { Animatable(initialValue = 0f) } . Changing this involves replacing an onEnd callback and I’m using async/await for it, I was wondering if this is a good way of approaching it? Complete code snippets are below in the reply thread.

[Chris Grigg]

Previously, i was kicking off an animation at load using DisposableEffect but it’s necessary for me to switch it to LaunchedEffect and, more importantly, I was using an onEnd callback in animateTo. It looked like this:

DisposableEffect(powerValue) {
        animatedProgress.snapTo(0f)
        animatedProgress.animateTo(1f, tween(durationMillis = 200), onEnd = { _: AnimationEndReason, _: Float ->
            setPowerValueWas(powerValue)
            animatedProgress.snapTo(0f)
        })

        onDispose {}
    }

Since onEnd was removed, would an appropriate way of handling this be the use of async/await to examine endReason?

LaunchedEffect(powerValue) {
        animatedProgress.snapTo(0f)
        val result = async { animatedProgress.animateTo(1f, tween(durationMillis = 200)) }.await()
        when (result.endReason) {
            AnimationEndReason.Finished -> {
                setPowerValueWas(powerValue)
                animatedProgress.snapTo(0f)
            }
        }
    }

[Dominaezzz]

You don't need async/await . Just call the method directly.

[Chris Grigg]

oh jeez, i’m fading. of course, it wouldn’t run asynchronously unless i launched a new coroutine, right?

[Dominaezzz]

Indeed.

[Chris Grigg]

of course of course

[Chris Grigg]

thank you

[Doris Liu]

And yes... you could just call it directly, and examine the returned result. If you don't have bounds set on the Animatable, you don't even need to check the end reason - the animateTo only returns when it finishes (or reaches bounds). In the case of interruption, there'll be a CancellationException thrown

[Chris Grigg]

that’s a great tip, thank you