-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Properly blend delayed animations #11
Comments
Hi @ryanmoelter, You are right, this behaviour might seem unexpected, but it's a design decision I made when writing the library. The
In this case, because of the additive nature of the animations the view would actually go past the maximum set value of 100 while it was animating to 50, before settling at 100!
But the order in which the animations would be played is be this:
Notice that x shortly goes to 150 in this version! The way the library works right now would make the changes in this order:
This implementation makes sure that the animation never produces intermediate values that were not enqueued, but suffers from the problem that you described in your ticket. Changing this behaviour itself would not require a lot of code (1 line, if I'm not mistaken (famous last words)), but I'm hesitant to make this change because of the implications it would have on existing projects. Maybe a flag to explicitly enable this behaviour would make sense? In the meantime, you could opt out of the additive behaviour by calling Cheers, |
Another idea I had was to add an optional parameter to the In you example, the code could look like this: animator.animate(view)
.alpha(0f)
.thenIf(() -> mIsViewHidden)
.target(otherView)
.alpha(1f)
.start(); In this case, What would you think of this solution? It also has some pitfalls, but solves a common problem of statefulness in animation chaining. |
Wow, this ended up at the bottom of my inbox, sorry for the late reply! What I'm trying to achieve with the proposed style of blending is to make it easy for my teammates (who may not understand the library as well as you or I do) to get the right behavior, defined mostly by not ending in an unexpected state. I see the tradeoff you made, and it makes sense. You want to keep the animated value within the expected range, i.e. within the bounds of the values passed into the animations. I think adding a flag would work fine! I understand not wanting to change the behavior for existing codebases. Unfortunately, the other two options won't work for me. Calling Overall, I'd love if we could add a flag for the style of blending I'm asking for! P.S. I understand not wanting to have animations go outside of the expected bounds, but you can already do that. Consider this:
This will do the following if I understand how animations get added together correctly:
So, the existing framework allows for out-of-bounds animations, as long as they're overlapping. That doesn't address the people who are relying on the library, so I still don't think we should change the default implementation without a major version bump, but I do still think it makes more sense. |
Hi Ryan, I understand your needs in this case, but I'm still not quite convinced the proposed change is a good one - it breaks basically all of the It's not obvious exactly when and how an animation will break (except for repeating and reversing animations, which are always busted). I can push the change to a branch if you'd like to try it out yourself? Regarding the You're right about the possibility of going out-of-bounds by starting two animations with different durations, I had not thought about that! |
Hi Ryan, I'm happy to tell you that I've made some progress on this issue, by rethinking what the user actually wants to do in cases such as your initial example. I think the best way of abstracting the expected behaviour is to think about it as the state of the view, so that is the basis of a new approach I'm trying: explicitly animate between predefined States as opposed to animating specific parameters which coincide with the expected UI state. One of the new constructs is an Using the new API looks like this:
… and behaves exactly like you want, even when quickly triggering between the (The I'm interested in hearing what you think about it, you can check out the code and play around with the demo in the animation_states branch! |
First off, thanks for this library! It's made animating things so much better.
But could we include animations with delays in the blending calculations as soon as we call
.start()
on the chain? Say we have a simple fade-out-then-fade-in:And we have its reverse:
If we run these in quick succession, the outcome is that both views are visible, since the
.alpha(1f)
animations are started last due to the.then()
delay.I would expect that the blending would take into account any animations that have been
.start()
ed, i.e. that the last animation block to be declared and.start()
ed would be the end state of all views involved, regardless of delays/choreography.I can make a PR for this if I find the time before you do, but I'd love to hear your thoughts first.
The text was updated successfully, but these errors were encountered: