More animation questions... is there any flexibili...

# compose

[vide]

More animation questions... is there any flexibility in AnimatedContent to only start animating after the content is ready to be drawn? When switching between complex scenes the animation time has already passed in real time before the content was ready to be drawn, and as a result no animation is seen.

[Ian Lake]

cc @Doris Liu who was looking for use cases for delayed animations. Maybe it would be helpful to talk a bit more about your use case?

[vide]

We have a very large AnimatedContent host which effectively contains navigation routes near the root of the composition. Some of our screen-level routes are so complex that the initial composition might take 1-2s in real time. We would still like to show a brief transition (fadeOut(), fadeIn()) in this case to ease the transition a bit. However, the transition starts running immediately when the target state is changed, and the animation (600ms) is usually finished before the composition is ready, and the change is abrupt.

[vide]

And the problem is the same in NavHost as it also uses AnimatedContent internally. Probably the case with Crossfade as well. It would be nice to have something to enable finer control of all the similar animation helpers.

[vide]

It probably wouldn't be as easy as making Transition public, some changes would probably needed to components that use it as well to accommodate the different behaviour... I'm not sure what the best API surface would be, but I think it would add value to make it as generic as possible, while also enabling this usecase without too much boilerplate.

[Ian Lake]

It is more like you want APIs like the ReportDrawn APIs from androidx.activity that bubble up 'readiness' to higher level components like AnimatedContent to indicate when the transition should actually start?
https://developer.android.com/reference/kotlin/androidx/activity/compose/package-summary#ReportDrawnWhen(kotlin.Function0)

[vide]

Yeah, something like that would definitely seem to be useful for implementing this. There's some other requests for even more flexibility, though:

https://issuetracker.google.com/issues/281204425

My use case is having a flow of screens, where you move from one to the other currently using AnimatedContent. But in some scenarios, as the user is interacting with the content, that transition should sometimes stop, slow down and so on.

[vide]

Using a result from something similar as ReportDrawn could be used to start the actual transition by the user manually instead of AnimatedContent hiding the implementation completely, but it could have a default though. Allowing users to control the transition state of AnimatedContent & co. separately from the target state would allow a wider range of user implementations.

[vide]

Maybe the currentlyVisible entries could be decoupled from the actual state of the transitions?

[Ian Lake]

Mmm, that seems like a totally different request? When to start the transition (because your content isn't ready) vs controlling the already running Transition

Note that AnimatedContent already supports the new SeekableTransition APIs for seeking the transition that is in progress.

[vide]

Yeah, I do agree the potential scope of changes here does somewhat differ. I would be happy with just delaying the start of the transition, but wanted to bring up other possibilities as well blob smile

[vide]

(If I understood correctly, the seekable transitions are only possible on API 34+ which is quite restricting, as Compose internally supports seeking on all supported API levels. Not strictly related to this, though.)

[Ian Lake]

I'm talking about the Compose SeekableTransitionState API introduced in Compose Animation 1.6.0-alpha04, which works on all API levels: https://developer.android.com/jetpack/androidx/releases/compose-animation#1.6.0-alpha04

[vide]

Oh, I didn't realize that was in already. Thanks for the link, I will check it out shortly!

[vide]

I checked out the example and not sure if I misunderstood, but isn't SeekableTransitionState incompatible with more than 2 states in AnimatedContent? The transition is never considered finished by AnimatedContent as currentState is constant:

override val currentState: S = initialState

The example only has 2 static states, while AnimatedContent is (usually?) used with many different transition start & endpoints. targetState is also not modifiable in SeekableTransitionState.

[vide]

And the docstring here is also incorrect now, since SeekableTransitionState.currentState is not backed by a MutableState.

/**
     * Current state of the transition. This will always be the initialState of the transition
     * until the transition is finished. Once the transition is finished, [currentState] will be
     * set to [targetState]. [currentState] is backed by a [MutableState].
     */
    val currentState: S
        get() = transitionState.currentState

[vide]

Should I maybe file an issue for this?

[Ian Lake]

You'd just create a new instance if you want a new target, yes

[Ian Lake]

But yes, please file issues if you run into issues or confusion as you play with the APIs