https://kotlinlang.org logo
Channels
Powered by
#compose
Title
# compose
v

vide

09/19/2023, 8:56 PM
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.
i

Ian Lake

09/20/2023, 4:01 PM
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?
v

vide

09/20/2023, 4:19 PM
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.
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.
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.
i

Ian Lake

09/20/2023, 4:34 PM
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)
v

vide

09/20/2023, 4:50 PM
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.
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.
Maybe the 
currentlyVisible
entries could be decoupled from the actual state of the transitions?
i

Ian Lake

09/20/2023, 4:56 PM
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.
v

vide

09/20/2023, 5:02 PM
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
(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.)
i

Ian Lake

09/20/2023, 5:17 PM
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
v

vide

09/20/2023, 5:42 PM
Oh, I didn't realize that was in already. Thanks for the link, I will check it out shortly!
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:
Copy code
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
.
And the docstring here is also incorrect now, since 
SeekableTransitionState.currentState
is not backed by a 
MutableState
.
Copy code
/**
     * 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
Should I maybe file an issue for this?
i

Ian Lake

09/20/2023, 11:31 PM
You'd just create a new instance if you want a new target, yes
But yes, please file issues if you run into issues or confusion as you play with the APIs
Powered by