Status Update
No update yet.
Comments
il...@google.com
Jeremy, is this still an issue? I think the problem was that you had two transitions targeting the same View for the same action (e.g. two Slide() transitions).
ap...@google.com
I have a similar issue with plain AnimatorSet:
set.start()
set.pause()
set.setCurrentPlayTime(100)
set.setCurrentPlayTime(0)
set.setCurrentPlayTime(100)
set.resume()
doesn't play animation in resume().
jb...@google.com
Should clarify that if I filter out setCurrentPlayTime(0) (or replace it with setCurrentPlayTime(1)) it works well.
Also even with setCurrentPlayTime(0), onAnimationEnd is notified with correct delay (as if the animation has played).
an...@google.com
@
I think that is intended for Animator. If you set the currentPlayTime to 0 or the total duration the animator completes. We do some
il...@google.com
Did some investigation on the Fragment side and it seems like the merged transition is targeting correctly.
Exiting Transition: Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
>>>>> ExitingViews <<<<<
View: android.widget.LinearLayout{f9add3d}
Entering Transition: Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
>>>>> EnteringViews <<<<<
View: android.widget.LinearLayout{b7f24bc}
Final merged transition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
merged transition passed to controlDelayedTransition: TransitionSet@7bc1c45:
TransitionSet@e133f9a:
Slide@aa9288e: tgts(android.widget.LinearLayout{f9add3d})
Slide@35b8af: tgts(android.widget.LinearLayout{b7f24bc})
Still digging.
Description
Version used: 1.2.0-beta02
Devices/Android versions reproduced on: All tested
I have attached a sample project and a screen recording from the project which illustrates the issue.
The project consists of a start view with two items (one of which is rotated 180 degrees). Clicking on any item does a shared element transition into a detail view, which has two images at the bottom. When you came in via the item that was unrotated and press back, the images explode out away from the center of the shared element as desired (the first transition seen in the video). If you came in via the rotated item however, the epicenter position is calculated incorrectly and the shared elements explode away from somewhere to the lower right of the screen (second transition seen in the video).
I believe the error is caused by the use of `View#getLocationOnScreen` when calculating the epicenter for a fragment transition, in FragmentTransitionImpl:
/**
* Replacement for view.getBoundsOnScreen because that is not public. This returns a rect
* containing the bounds relative to the screen that the view is in.
*/
protected void getBoundsOnScreen(View view, Rect epicenter) {
int[] loc = new int[2];
view.getLocationOnScreen(loc);
epicenter.set(loc[0], loc[1], loc[0] + view.getWidth(), loc[1] + view.getHeight());
}
I've ran into this problem myself when calculating screen bounds - the location given by getLocationOnScreen is in fact (0,0) in the View's coordinate system transformed to that of the screen. This means if the view is rotated for example 180 degrees, this will be the lower right corner of the view as seen on screen. When you then add the width and the height, you end up to the lower right of where the view actually is on the screen - which is exactly what we see in the sample project.
The proper way to do it would be to port the code from the View implementation (which takes the matrix into account, meaning scale, rotation, pivot etc would all work).