Status Update
Comments
ti...@google.com <ti...@google.com> #2
Branch: androidx-master-dev
commit 23a7d960caf43390a554700d3c56ada189a9d10e
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Mon Aug 10 15:11:36 2020
IconButton / IconToggleButton API scrub
Test: ./gradlew updateApi
Bug:
Bug:
Relnote: "Adds enabled parameter to IconButton, and reorders parameters in IconToggleButton"
Change-Id: I0a9419b1a631cadad451395302ad87b7f9214f96
M ui/ui-material/api/current.txt
M ui/ui-material/api/public_plus_experimental_current.txt
M ui/ui-material/api/restricted_current.txt
M ui/ui-material/src/commonMain/kotlin/androidx/compose/material/IconButton.kt
ti...@google.com <ti...@google.com> #3
BTW, the TargetBasedAnimation
and DecayAnimation
have been exercised heavily in the code base, as they have been the implementation detail that backs the various AnimationSpec. So they should be fairly stable for you to use directly. :)
As for a convenient method to create FlingInfo, do you intend to support other types of decay? If not, something like what you proposed could work. If you'd like to support other types of decay, you could consider making it an extension function on decay: fun FloatAnimationDecaySpec.generateFlingInfo(start: Float, startVelocity: Float): FlingInfo
ap...@google.com <ap...@google.com> #4
Branch: androidx-master-dev
commit 8a1d8f35c44825cf80e697ef3cd4682cb2c5624d
Author: Doris Liu <tianliu@google.com>
Date: Tue Sep 22 20:26:16 2020
Make Animation, TargetBasedAnimation, and DecayAnimation public
Bug: 163329867
Test: Tests on `Animation` and subclasses all pass
RelNote: "New Animation interface and subclasses: These classes
store the start and end conditions for animations, and therefore
allow value and velocity to be queried via only playtime"
Change-Id: Ie95bdaad0a1cf18dc18548fd511ef6f31faa1e59
M compose/animation/animation-core/api/current.txt
M compose/animation/animation-core/api/public_plus_experimental_current.txt
M compose/animation/animation-core/api/restricted_current.txt
M compose/animation/animation-core/src/commonMain/kotlin/androidx/compose/animation/core/AnimatedValue.kt
M compose/animation/animation-core/src/commonMain/kotlin/androidx/compose/animation/core/Animation.kt
M compose/animation/animation-core/src/commonMain/kotlin/androidx/compose/animation/core/TransitionAnimation.kt
M compose/animation/animation-core/src/test/java/androidx/compose/animation/core/PhysicsAnimationTest.kt
M compose/animation/animation-core/src/test/java/androidx/compose/animation/core/RepeatableAnimationTest.kt
M compose/animation/animation-core/src/test/java/androidx/compose/animation/core/SnapAnimationTest.kt
ti...@google.com <ti...@google.com> #5
Matvei,
fun getValue(playTime: Long): T
style animation is now available as DecayAnimation
. The target calculation based on initial velocity and value can be achieved via calculateTargetValue
Please let me know if there's anything else I can help provide. :) If not, please feel free to close the issue.
ma...@google.com <ma...@google.com> #6
Nice! Thanks Doris. This is what I had in my mind when I was filing this bug.
Thanks for making this happen, this will scale very good!
Description
After offline discussion with Adam we came up with the good idea around AnimaitonDecaySpec and the level of granularity we might want to add.
Basic idea: Let's split AnimationDecaySpec into two abstractions: one will be an per-animation-run "Info" thing that, and the other will allow creation of this "info" things for any particular animation given some input.
Detailed information: Let's split
AnimationDecaySpec
into two things:the API of this will be similar to what we have right now in AnimationSpec, BUT with one big difference: you already have all the knowledge about this particular occurrence of the animation, so you don't need to remember what was your entrypoints (start position, start velocity, etc).
Given that,
will become
and similar with other methods.
(Names are TDB of course).
What this separation gives us: This granularity brings clear separation of concerns and knowledge: one thing lives for a long time and hosts somewhere higher lever (in components, states) and it's generated "Info" objects can flow into lower level abstraction that are one-time fired (such as
AnimatedFloat.fling
oranimateTo
).Additionally, I would suggest to rename Decay to Fling (or just make it part of plain animations api) everywhere because:
For the reference and initial idea: take a look here
Going forward, we can try to stretch this idea to the whole animation, and not only decay/fling part.
Doris, I'd like to know your opinion on this.