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
rossfade_multiple.xml
|
c81a8493884c7f432d6bd5b98aca3fbdc93b355b |
12-Jul-2013 |
Chet Haase <chet@google.com> |
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
rossfade_multiple.xml
|
dc57d9dda559aaf06237b9124dc9ef27513bab31 |
10-Jul-2013 |
Chet Haase <chet@google.com> |
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
rossfade_image.xml
|
2ea7f8b9c5f903050d42c1af57406bf528979f45 |
22-Jun-2013 |
Chet Haase <chet@google.com> |
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
ierarchical_move.xml
|
6ebe3de331efd00ba23bc4191d4a82cfa4c39160 |
18-Jun-2013 |
Chet Haase <chet@google.com> |
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
ading_hierarchy.xml
|
4f5072327d00822a2bfaff56df46cea2981ac90d |
10-Jun-2013 |
Chet Haase <chet@google.com> |
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
wo_buttons.xml
|
25a738fb257aacfc87d3363a834ed6e0b050c3b1 |
05-Jun-2013 |
Chet Haase <chet@google.com> |
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
nterruption_inner_1.xml
nterruption_inner_2.xml
nterruption_inner_3.xml
nterruption_inner_4.xml
|
867a86613d4152a93423300f83597300e6ebeebe |
03-Jun-2013 |
Chet Haase <chet@google.com> |
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
nterruption.xml
nterruption_inner_1.xml
nterruption_inner_2.xml
nterruption_inner_3.xml
nterruption_inner_4.xml
|
faebd8f0795b7d275fb4e503533c8c0c4a9acc21 |
18-May-2012 |
Chet Haase <chet@google.com> |
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
ctivity_login.xml
utton_template.xml
hanging_text_1.xml
hanging_text_2.xml
lipping_text_1.xml
lipping_text_2.xml
ontact_collapsed.xml
ontact_expanded.xml
ontacts_list.xml
rossfade.xml
rossfade_1.xml
ading_test.xml
ading_test_scene_2.xml
ading_test_simple.xml
ading_test_simple2.xml
ncorrect_password.xml
nstance_targets.xml
ist_view_add_remove.xml
ogin_password.xml
ain.xml
ew_user.xml
verlay_test.xml
eparenting.xml
esources_test_layout.xml
esults_screen.xml
earch_screen.xml
uccess.xml
urface_texture_views.xml
nique_id_test.xml
sername_taken.xml
|