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
Some view changes require more flexible transitions than the
defaults provided by Crossfade and TextChange - this change supplies some
of that flexibility.
Also, starting a new transition on a hierarchy undergoing a transition
caused the first to get canceled, then the start values to be retrieved.
The new transition should actually get the start values from the intermediate
state of the views, so we now cancel the previous transition only after the
start values have been captured.
Issue #9756349 Transitions: Crossfade does not handle interruption/reverse correctly
Issue #9295863 Transitions: Add behavior API/flags to various transitions
Issue #9275859 Transitions: Improve mechanism for transition interruption
Change-Id: I5a8c5a12466ddcab9e84e4880930563fa1216f3b
Transitions used to be three phase:
- captureValues(): get all relevant property values in the
affected view targets
- setup(): set appropriate start values for affected views
prior to any transitions being played
- play(): create/play Animators for affected views
Now the second and third phases have been collapsed (and named
"play()"). This single step sets initial values for target views
and creates any Animators that should be played during the transition.
The transition mechanism stores these Animators and then starts
them at the appropriate time in the overall transition.
Issue #9507585 Transitions: Simplify Transition.play() design
Change-Id: I3fc67599b38fe49eee885dc5d32444db90b7703b
setDuration() wasn't handled correctly for TransitionGroup; it should
propagate the value to its children.
Also, videos with no ids were not being handled correctly. The transition code was
using the default id on those views (-1) to store start/end data about the view,
causing multiple non-id views to clobber values in the hashmaps. The correct approach
should be to ignore default id values - only store information about the view
instances, not about the unset ids.
Also, added a new test InterruptTest to be used to fix the current behavior of
not handling situations where new transitions start while old ones are still taking place.
Change-Id: I4e880bdbb33cc26d487bceb0d56e463e72f7621f
This checkin has preliminary API (in flux, definitely changes still
to be made) and implementation for a new "Scenes & Transitions" feature.
The current implementation allows you to define different Scenes
(via layout resource IDs or callbacks) and Transitions to be used when
changing to those scenes. By default, scene changes will use AutoTransition,
which generally does the right thing.
There are no overview docs or tutorials yet. The best way to learn how things
work is to see the code for the various tests in
frameworks/base/tests/TransitionTests.
Expect the API to change. Expect the implementation to change (mostly to add
more functionality). Expect bugs, but tell me if things do not work
as expected.
Change-Id: Ib025a9f565678b225afa4759325cf6d496cc7215
