| b7a7fc9d233bad507ce893882352618b13647058 |
|
21-Sep-2013 |
Chet Haase <chet@google.com> |
Make fading transitions work better
Previously, a Fade transition would only affect a view if its
parent hierarchy was not also affected between the start/end states.
This caused problems for views which were removed from their parents
between scenes when their parents' visibility also changed between those
scenes. The effect would be that the transition would fade the parent...
but the child would no longer be in that parent, so the user would just see the
child view blink out.
This fix ensure that views are faded appropriately by fading them
regardless the parent hierarchy; if a view is removed from its
parent, fade it out.
Additionally, if that view has not been removed from its parent, but
its parent is no longer parented *and* scene being
transitioned from is based on a layout resource file (and thus
the views are considered temporary after transitioning), then it is
removed from its parent to be faded out in the overlay.
Also, renamed TextChange to ChangeText to be more consistent with
other transition class names.
Change-Id: I4e0e7dfc9e9d95c7a4ca586534b6d204c4f3bae0
/frameworks/base/core/java/android/transition/Fade.java
|
| c46181a963be736186ae29101625a05b5c1f0ba8 |
|
16-Sep-2013 |
Chet Haase <chet@google.com> |
Use transition-only alpha property for fading transitions
The original bug is fixed already, but showed up some problems in
the underlying fade-transition implementation. This fix addresses
those and other issues. The biggest part of the change should help
transition robustness in general, as it removes the dependency on the
public 'alpha' property of views and uses, instead, a new hidden property
on views called 'transitionAlpha'. This is a value which is normally
opaque (1), but which can be used by transitions (only) to animate the
translucency of views without disturbing the actual 'alpha' value which
might be manipulated outside of transitions. This should make transitions
much more robust in general.
In implementing and testing this overall fix, I noticed a couple of things
about transitions that were simply wrong (such as starting fades from the
wrong start value, and incorrectly avoiding transitions on some views
that didn't happen to have ids), and those are fixed in this CL as well.
Issue #10726905 ActionBar weirdness in People app
Issue #10727937 Menu items in gallery appear in faded color after selecting an image/album by long press
Change-Id: If1618446db10c1bfcff4761449241de4f559afc1
/frameworks/base/core/java/android/transition/Fade.java
|
| 23c61f6bc57a611d97d333bce0d8fe00ab81af4c |
|
14-Sep-2013 |
Chet Haase <chet@google.com> |
Ensure that transitions animating alpha end on a reasonable value
The Fade transition sets an initial alpha value of 0 when items are
appearing. This makes items invisible to start with, and then they
eventually fade in as part of the transition when the transition's
animation runs.
But if that animation/transition gets interrupted, or not started, then
the alpha value would not be restored, and the value would stay 0,
making the items invisible indefinitely. This is what was happening in
the action bar of the People app when performing a search.
The fix is to handle Transition and animation events to restore the alpha
to its true value when the transition completes, whether that
transition is canceled or not.
Issue #10726905 ActionBar weirdness in People app
Change-Id: Idb65fd8d471d2ac0a1ddc243fee00ae99f7e72d8
/frameworks/base/core/java/android/transition/Fade.java
|
| d82c8ac4db7091d2e976af4c89a1734465d20cd2 |
|
26-Aug-2013 |
Chet Haase <chet@google.com> |
Transition API changes from API council recommendations
Issue #10460684 KLP API Review: android.view.transition and android.animation
Issue #10570740 Transitions: inflate transition targets from xml
Change-Id: I7a3f6d3aece2fcafc5efd555d033f79e86635c98
/frameworks/base/core/java/android/transition/Fade.java
|