New Fragment StateManager does not call on onCreateView when a Fragment that had it transition postponed is popped [166658128]

Fixed

Bug

Status Update

No update yet.

Description

tj...@gmail.com

created issue #1

Aug 28, 2020 03:29PM

Component used: Fragment Version used: 1.3.0-alpha08 Devices/Android versions reproduced on: Emulator / Pixel 3

If this is a bug in the library, we would appreciate if you could attach:

Sample project to trigger the issue.
A screenrecord or screenshots showing the issue (if UI related).

I have a sequence of 3 Fragments that use shared element transitions, and use postponeEnterTransition() on all of them.

Everything is great when I go from Fragments 1 -> 2 -> 3. However, when I pop from 3 -> 2, the onCreateView and onViewCreated methods are skipped. onStart and onResume are called however. What's worse, after popping, I see the old view instance for Fragment 2 that should have been destroyed when I move to Fragment 3. OnDestroyView is also never called for Fragment 2 at all.

Repository with reproducing code: https://github.com/tunjid/Android-Extensions/tree/feature/fragment-1.3.0

Fragment 1 -> DoggoListFragment Fragment 2 -> DoggoPagerFragment Fragment 3 -> AdoptDoggoFragment

Comments

il...@google.com <il...@google.com> Sep 16, 2020 06:31PM

Assigned to jb...@google.com.

jb...@google.com <jb...@google.com> #2Sep 16, 2020 11:39PM

Marked as fixed.

Yigit, do you have time to fix it?

reemission of the same liveData is racy

tj...@gmail.com <tj...@gmail.com> #3Sep 17, 2020 12:50AM

yea i'll take it.

jb...@google.com <jb...@google.com> #4Sep 17, 2020 06:38AM

Status: In Progress (Accepted) (reopened)

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.

ap...@google.com <ap...@google.com> #5Sep 18, 2020 07:07PM

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()
}
}

jb...@google.com <jb...@google.com> #6Sep 22, 2020 04:38PM

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)

tj...@gmail.com <tj...@gmail.com> #7Sep 22, 2020 10:49PM

yea sorry immediate does not fix it.
I actually have a WIP fix for it:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.

val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}

jb...@google.com <jb...@google.com> #8Sep 22, 2020 11:41PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019

Fix coroutine livedata race condition

This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.

We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)

Bug: 140249349
Test: BuildLiveDataTest#raceTest_*

Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40

M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt

https://android-review.googlesource.com/1112186

https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06

tj...@gmail.com <tj...@gmail.com> #9Sep 23, 2020 12:02AM

Oh my apologies! It persisted because I updated the fragment dependency to
androidx.fragment:fragment:1.3.0-SNAPSHOT, but forgot to update the ktx
extensions to androidx.fragment:fragment-ktx:1.3.0-SNAPSHOT.

Updating both fixes it, sorry about the false alarm and thanks for the fix!

>

jb...@google.com <jb...@google.com> #10Sep 23, 2020 01:07AM