| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The callbacks for animators in some corner cases were not being
called correctly. For example, startDelayed animators that were
started and then ended didn't send out the proper events.
This CL fixes that logic. Specifically:
- An animator that is end()'d will implicitly start() itself and then
assign an end value. This was already the case, but listeners were not
getting notified. Now this situation causes callbacks to listeners for
both the start and end events.
- startDelayed animators that are end()'d or cancel()'d prior to finishing
the startDelay phase will send out events (start and cancel/end, as appropriate)
to listeners.
Change-Id: I40a0f2fdb19d9ec7c3726a91363686c6ecb7d915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, AnimatorSet incorrectly checked whether child animations were
'running' to figure out what to cancel. If a child animation was started, but
sitting in a startDelay phase, it was not 'running', so the right cancel/end
events would not propagate.
The fix is to add a new isStarted() API to Animator, which returns true when
the animator has started (but not yet ended), regardless of whether the animator
has a startDelay or not. It's basically a superset of the existing isRunning()
method, which only returns true when an animator has actually started setting values.
Change-Id: I126814cb6637b58295b6d18d9b155235671f99be
|
| |
|
|
|
|
|
|
| |
AnimatorSet was incorrectly ignoring cancel() when it was in the
initial startDelay phase. Fix is to change isRunning() to be true if the
animator is also in its delay phase.
Change-Id: I1a8c877de24fa294beea0ba30d495658255b13b3
|
|
|
Previously, calling cancel() on an Animator would cause onAnimationCancel
events to be sent to all listeners. This was confusing for listeners
that were keying off this event for performing other actions, when the original
animator wasn't truly canceled (because it wasn't even running, or had already
been canceled earlier). This change hinges listener notification on
the animator actually running; no events are sent otherwise.
Also added the first set of Animator tests to verify that this behavior
is correct.
Change-Id: I81ab56559b5c0343c8dc7880e1c8235f3020975b
|
