Whats the case for `transitions` in compose? ```v...

# compose

[ursus]

Whats the case for transitions in compose?

val transition = updateTransition(
    targetState = expanded,
    label = "expandedTransition"
)

val width by transition.animateDp(label = "width") { expanded ->
    if (expanded) 220.dp else 64.dp
}

val alpha by transition.animateFloat(label = "alpha") { expanded ->
    if (expanded) 1f else 0f
}

how is this fundamentally different than 2 animateXAsState?

[Chrimaeon]

The first diagram on top of this page https://developer.android.com/develop/ui/compose/animation/choose-api

[ursus]

that only says to use it, doesn't explain my question

my question rationale - it's more code, so what do I gain?

[Winson Chiu]

That page seems to imply that time sync is not guaranteed between multiple animate calls, but it would be with Transition since it's driven by a single backing value. I don't know how often that happens in practice, but I've been using Transition whenever I have multiple properties of a single node to animate.

[ursus]

whats sync time? vsync?

[Winson Chiu]

As in Compose could update the animation in different frames, so the 1st animate call could start before the 2nd. I don't know if that ever happens in practice though.

[ursus]

not sure if I follow. every (latest) State change gets rendered come vsync time

[Winson Chiu]

Right, but the actual state may not change together. If you look at animateValueAsState, it uses launch with a Channel to schedule animation updates. There's no guarantee of promptness there, it's possible one launch occurs before the frame boundary and another after.

Whereas Transition calls derivedStateOf on its state value, meaning that when the value is invalidated, all of the dependent state values must be updated in the same snapshot for it to be considered successful and applied.

[ursus]

hmm really? are you saying animateAsStste might skip frames? i.e. stutter by design?

[Winson Chiu]

No, the actual animation should be synced with Compose's frames. From what I can tell it's only the change in state. Compose can't control when the Kotlin coroutine resumes, so it may start the animation at different times.

[ursus]

yea but if you don’t change a value in time, it stays the same, so the visual effect is same as if frame was dropped

unless I have no idea how anything works 😀

[Winson Chiu]

But if you can only drop frame 0 it doesn't matter, does it? The user would just see the animation start later, which doesn't matter if you've made the choice to make the animation independent by using animate instead of Transition.

[ursus]

hmm true

[Winson Chiu]

I feel like it would only matter if you're animating 2 properties that need to line up, like if you're relying on one view to overlap another exactly.

[ursus]

tbh im not against transitions, i just want to understand vs just cargocult

[ursus]

although id expect for the transition to be also coroutine driven, why would they swap backends between apis

[ursus]

so naively im not sure why would it not suffer from the same issues

[Winson Chiu]

Transition is coroutine driven, I think, but because it only updates 1 value, that single value is transformed into each of the state values that get applied to the UI. If the coroutine is delayed or skips or something, all of the derived properties move together. They don't individually get a coroutine.