8aa1ffb0ed292891030992c65df4e5dc8bd37524 |
|
08-Aug-2013 |
Chet Haase <chet@google.com> |
pause/resume for Animators It is now possible to pause Animator-based animations. Pausing an animator causes it to hold the current time/value indefinitely, or until end/cancel/resume is called. When resume() is called, it continues from where it left off. There is a new listener interface on Animator, AnimatorPauseListener, which can be used to listen to pause/resume events. Change-Id: I77d1535e792fb7bf349f549a0ac0a0d85958cb47
/frameworks/base/core/tests/coretests/src/android/animation/EventsTest.java
|
17cf42cb85c22b50ecfa8d21efc992f99d20fc45 |
|
17-Apr-2012 |
Chet Haase <chet@google.com> |
Fix logic of animator start/cancel/end callbacks 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
/frameworks/base/core/tests/coretests/src/android/animation/EventsTest.java
|
8b699792b677bd4dd8442b32641ac09d48fdd79c |
|
06-Aug-2011 |
Chet Haase <chet@google.com> |
Fix cancellation of AnimatorSet when child animation has delay 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
/frameworks/base/core/tests/coretests/src/android/animation/EventsTest.java
|
b8f574a165bf6ec5b316734b367ac274ded4809b |
|
03-Aug-2011 |
Chet Haase <chet@google.com> |
Fix AnimatorSet cancellation issues 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
/frameworks/base/core/tests/coretests/src/android/animation/EventsTest.java
|
7dfacdb1c820f955cb3cd6032ff5fbc2dd7d9df5 |
|
12-Jul-2011 |
Chet Haase <chet@google.com> |
Fix Animator cancel() behavior 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
/frameworks/base/core/tests/coretests/src/android/animation/EventsTest.java
|