TheMrCodes
03/03/2021, 8:47 PMDoris Liu
03/03/2021, 8:54 PMTheMrCodes
03/03/2021, 8:55 PMZach Klippenstein (he/him) [MOD]
03/03/2021, 8:58 PMDoris Liu
03/03/2021, 9:00 PMTheMrCodes
03/03/2021, 9:03 PMDoris Liu
03/03/2021, 9:06 PMThanks for the answers I get why it is made that way but I currently try to combine multiple animations to one motion and it makes it much harder if you can't set / don't know the duration of one of themThat's a completely valid use case. I'd love to understand it more if you don't mind sharing. 🙂 We are still evolving the APIs, and the use cases could definitely help inform the direction of future changes.
TheMrCodes
03/03/2021, 10:12 PMDoris Liu
03/03/2021, 11:45 PMI would like to time the translation and color shifting so the both start and end at the same time.This design makes total sense. It made me wonder if it'd be useful to for us introduce some sort of companion animation, the progress of which is entirely determined by the progress of another animation. The spring would drive the position change for the tab indicator, and color gets its fraction/progress from the position change.
I've got two toughts about this:
First, so some kind for converting duration (+ extra values like start and end state if needed) to dampRatio would be nice.We currently have the calculation goes the other way 😅 - given the start/end state and dampingRatio we can calculate the duration, with
TargetBasedAnimation.durationMillis/Nanos
once you set it up. Even the algorithm for this calculation was non-trivial to work out, the reverse calculation would be only more mathematically challenging.
Second, I would like to know if SpringSpec take the same time to interpolate from A to B as from B to C. If thats not the case I like to be able to have a Spec that implements the same bounce behaivir but varies in speed so the animation is always finished in n millisecsSpringSpec will not take the same time going from A to B as from B to C, unless A, B, C are equal distance apart. Having the same duration for A->B and B->C means their velocity profile will be quite different, which isn't necessarily visually pleasing/consistent. That's especially true in the example above where for one state change the indicator travels 1/2 of a screen width while for another state change it move 1/10 of the screen width. With that said, if you prefer to have the same duration for all the indicator sliding animation no matter what the initial/target states are,
tween()
would be the best choice. To achieve that elastic effect, you could use two different tweens, one faster than the other. That could be done with either the same easing different duration for the two tweens, or same duration different easing curves. 🙂tween
s would be responsible for animating the left end of the indicator and the right end, respectively. Step 6 of the animation codelab explains this elastic effect pretty well: https://developer.android.com/codelabs/jetpack-compose-animation#5TheMrCodes
03/04/2021, 7:51 AMspring
s with diffrent stiffness. I sadly made it first and found this codelab later 😅