Fixed
Status Update
No update yet.
Comments
il...@google.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ap...@google.com
yea i'll take it.
jb...@google.com
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
an...@google.com
just emitting same live data reproduces the issue.
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
il...@google.com
With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)
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).