12 Commits

Author SHA1 Message Date
Chet Haase
ff58f92a0a Add exclude() methods to Transition
It would be useful for a transition to declare not just which
targets it wants to be run on, but also which targets it wants
to avoid. For example, you may not want to animate the items of
a ListView, or some other specific target in the view hierarchy.

This change adds various exclude*() methods which make it
possible to alter a transition to automatically ignore specific
views, ids, or classes in the hierarchy.

Issue #10692794 Transitions: Need API for excluding targets

Change-Id: If38025cdbee537a545e5a4268cbbd763af4622c5
2013-09-11 13:53:43 -07:00
Chet Haase
d82c8ac4db 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
2013-09-04 14:46:38 -07:00
Chet Haase
c81a849388 Fix minor transition bugs and add capabilities
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
2013-07-12 13:40:38 -07:00
Chet Haase
dc57d9dda5 Fix minor transition bugs
TransitionGroup.setDuration() was not propagating the new duration to
future child transitions correctly.

Also, Fade should restore a fully-opaque value when a transition ends, to prevent
the problem of mid-stream canceled transitions causing vie3ws to get stuck with partially
faded-in alpha values.

Issue #9755995 Transitions: TransitionGroup.setDuration() not handled correctly
Issue #9756655 Transitions: handle fading cancelation better

Change-Id: Id44569c6f4152a26ee382d04c30a2f035a1ebcf3
2013-07-10 12:14:54 -07:00
Chet Haase
2ea7f8b9c5 Refactoring/simplifying Transition code/API
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
2013-06-21 16:07:14 -07:00
Chet Haase
6ebe3de331 Fix transitions on disappearing view hiearchies
Previously, Fade transitions did not work correctly on hirearchies; they
only handled individual views. in particular, they would side-effect all
fading views by removing them from their parent to fade them out in the
overlay of the scene root. This worked for the fade-out transition itself,
but caused problems when those same hierarchies were added back in and
another Fade was run on the hierarchy, because now all of the views inside
that parent node had been removed, so they didn't fade in at all.

The fix was to add logic in Visibility to detect when a disappearing
view was inside a hierarchy that was also disappearing, and to skip the
fade on the views inside that hierarchy, leaving only the top-most
disappearing view to be faded out, thus preserving the hierarchy under
that faded-out group.

Along the way, there were various cleanups, fixes, and refactorings in the
transition code, and slight API modifications.

Issue #9406371 Transitions: Removing view hierarchy not working correctly
Issue #9470255 Transitions: Separate different transitions by Scene Root

Change-Id: I42e80dac6097fee740f651dcc0535f2c57c11ebb
2013-06-20 15:35:04 -07:00
Chet Haase
4f5072327d Add dynamic scene creation/transition capability
Add TransitionManager.beginDelayedTransition() to handle starting a transition
on the next frame for a given scene root based on all changes that
take place between the first call to that method and the next animation frame.

Issue #9321937 Transitions: consider batching up multiple scene actions

Change-Id: I3fc92b6b4ec5ff42b1e678bcfd385703e32eba2a
2013-06-10 14:06:14 -07:00
Chet Haase
4f0c4672ac Fix CrossFade transition
Small fixes in CrossFade to handle more general situations.
Also, added API to CrossFade to enable different behaviors during
the transition.

Change-Id: I12d17ab8f8f96be370c070373112ad8a62df9115
2013-06-06 07:37:32 -07:00
Chet Haase
25a738fb25 Fix in transition canceling logic
The logic that canceled underlying animations caused a problem
when there were more than one animation in the list (due to removing
items from a list that was currently being processed elsewhere).

Change-Id: Ie207f340b5d7de4ffcf56a26c05ec394abb80224
2013-06-04 16:35:14 -07:00
Chet Haase
867a86613d Various fixes/cleanup in Scenes and Transitions
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
2013-06-03 16:37:05 -07:00
Chet Haase
797b7559d6 Fix build due to transition test errors
erroneous inclusion of R file for test files is causing build breakage
on the server. Remove the offending lines.

Change-Id: I1948facc1b5e3f8b7415e0e6c4290b53a54f12af
2013-04-18 14:18:35 -07:00
Chet Haase
faebd8f079 First draft of Scenes & Transitions feature
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
2013-04-18 13:33:13 -07:00