What’s the easiest way to provide a spring() spec ...

# compose

[Stylianos Gakis]

What’s the easiest way to provide a spring() spec to an animation, but with an initial delay before it starts?
For a tween there’s a delayMillis which makes this convenient. From what I understand this isn’t the case for the spring one since you want to maintain momentum from potential earlier animations or something like that, is this the case?
Now I’m thinking of doing something like

val animatableProgress = remember { Animatable(0f) }
LaunchedEffect(Unit) {
    delay(300)
    animatableProgress.animateTo(1f, spring())
}
// use animatableProgress

to use this exact thing, but I feel like I may be missing some API which makes this simpler for me.

[Stylianos Gakis]

In fact it’d be optimal if I could somehow do this directly in the API of fadeIn() for example, which takes in an animationSpec as to how to fade in.

fun fadeIn(
    animationSpec: FiniteAnimationSpec<Float> = spring(stiffness = Spring.StiffnessMediumLow),
    initialAlpha: Float = 0f
)

I’d like to be able to do something like (pseudocode) fadeIn(animationSpec = nothing(300.milliseconds) + spring()) or fadeIn(animationSpec = spring(initialDelay = 300.milliseconds)) or something like this.
Otherwise with my impl above I have to then avoid using the convenience of AnimatedVisibility and have to animate the thing myself using the result of the animatableProgress, which will be much more inconvenient in general.

[Albert Chang]

Is there any reason you can't use tween?

[Stylianos Gakis]

Hmm I wanted the fluidity of spring since it feels better in my particular animation. But maybe I should try and imitate that fluidity with the right Easing provided to my tween

[Albert Chang]

Yeah I think that's the better way.

[Stylianos Gakis]

Hmm yeah will try and work with a tween then and see how it goes, thank you 🙌

[Doris Liu]

Springs are intended to be fluid and handle interruptions by resuming the existing momentum. A spring with a delay would create an unclear behavior - should I pause for the delay in interruption handling case? What you'd want is probably only to use the initial delay when the animation is not already running.

Take the case: fade in -> (interruption) fade out -> (another interruption) fade in. The most reasonable behavior is for the last fade-in to kick in without delay, which would contradict the animation spec if it was spring w/ delay

[Doris Liu]

Perhaps we could allow specifications for how interruptions should be handled, so it's not tied to the animation spec used for "happy path" animation 😛

[Stylianos Gakis]

Yeah I totally understand the reasoning now. It that case I would indeed want it to kick the animation immediately, which would as you say break what I just passed it in since it’d then skip the initial delay.
Allowing some control of how the interruptions are handled sounds interesting, but if it’s only me who’s asking something like this it may not be worth the effort 😄 In the end I’ll end up simply using tween anyway now since I better understand what I want to happen and what my current options are.