Should I use `FloatTweenSpec` or `tween<Float>`, … `FloatSpringSpec` or `spring<Float>`...

# compose

[elye]

Should I use FloatTweenSpec or tween<Float>, … FloatSpringSpec or spring<Float>?

[Colton Idle]

Use whatever `Float`s your boat /s

[Doris Liu]

Either one works. I would recommend tween and spring for working with higher level animation API. Float*Spec avoids boxing the Floats when you use the methods defined in that interface directly. But if you use it as an AnimationSpec, it's no different than tween and spring

[elye]

Thanks @Doris Liu.
Can you elaborate what is boxing the Floats a little more…

[Doris Liu]

Auto-boxing for primitives happens when used in an interface of generic type (e.g. Foo<Float>). Float*Spec interface declares methods that accept primitive Float type parameters, therefore no autoboxing is needed when you use those methods. (They are in fact used in the low level animation system when all data types have been converted to floats.) But if you were to use Float*Spec as an AnimationSpec<Float> to pass to high level animation APIs, none of those linked methods will be used. Therefore in that case there's not much difference between FloatSpringSpec and SpringSpec<Float> .

[elye]

Thanks very much @Doris Liu!
I guess, I make the below conclusion. Let me know if I get it wrong.
• If we have a primitive Float, then Float*Spec would be more efficient.
• If we are not using Float, we’ll have to use tween or spring
• When using non-primitive Float , then both are the same.

[Doris Liu]

That's not correct. 🙂 They are the same unless you call FloatAnimationSpec.getValue/VelocityFromNanos(...) from your application in a manual animation use case. Otherwise, they will be both treated as AnimationSpec<Float> and through AnimationSpec<T>.vectorize get converted to AnimationVector-based animations to be used in Animation<T>.

[Doris Liu]

Come to think of it, the observable fields of non-stateless animation APIs are backed by State<T> . So the floats eventually are boxed anyways.