Is there any known animation issue with `0.4.0-build178` ? `animateFloatAsState` doesn't seem to wor...

# compose-desktop

[theapache64]

Is there any known animation issue with 0.4.0-build178 ? animateFloatAsState doesn't seem to work anymore. 🤔 🧵

[theapache64]

Reproducible Code: https://gist.github.com/theapache64/9dfa23d9f688112b9a51c1fe36de1271

[theapache64]

FYI. The code was working in previous versions.

[jim]

Looks like a (unintentional?) behavioral change in animations. Specifically, the finishedListener would previously run upon first composition allowing you to use tween + finishedListener to implement an infinite animation. It appears this is no longer the case. @Doris Liu WAI or bug?

[jim]

I suspect this changed in https://android-review.googlesource.com/c/platform/frameworks/support/+/1627839

[Doris Liu]

It's an intentional change to avoid unnecessary animations. Previously, animateFloatAsState would animate (from/to the same target) when it enters composition, and subsequently invokes the finished listener. Now it only animates when target changes.

[Doris Liu]

Looking at the code snippet, the previous behavior would have been no visible change (due to the same from/to value) for the first animation duration, then animating in-between the two target values. 🙂 I suspect that's not the desired behavior. If it's intended for the animation to start as soon as enters composition, consider putting an initial state toggle in a DisposableEffect [Edit:] using Animatable . Note, it's generally recommended to avoid writing compositions that take more than one pass to converge. Putting state toggle in DisposableEffect would therefore be an antipattern.

[theapache64]

Understood. was this document anywhere in the release notes?

[theapache64]

Yeah got it. Thanks @Doris Liu @jim

[Doris Liu]

It wasn't in the release note, as we weren't expecting that behavior to be depended on. 😅