Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
Please include a sample project that reproduces your issue.
ap...@google.com <ap...@google.com> #3
Here is the sample project.
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
Steps to reproduce:
1. Press on "Search" icon;
2. Write something;
3. Search this text, keyboard will be dismissed;
4. Tap on "Dialog" button;
5. Dissmiss dialog;
With the new 1.5.0 fragment library version text will be cleared in the search box after dismissing dialog.
In the version 1.4.1 and lower text in the search is not clearing and this is correct behaviour.
Please suggest some workarounds or how to fix this issue?
jb...@google.com <jb...@google.com> #4
Hello, have you checked sample project? I hope it will help find the issue.
an...@google.com <an...@google.com> #5
il...@google.com <il...@google.com> #6
Hello, any update please?
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).