Status Update
Comments
dm...@gmail.com <dm...@gmail.com> #2
reemission of the same liveData is racy
gr...@ynab.com <gr...@ynab.com> #3
il...@google.com <il...@google.com> #4
gr...@ynab.com <gr...@ynab.com> #5
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
ro...@bbc.co.uk <ro...@bbc.co.uk> #6
ro...@bbc.co.uk <ro...@bbc.co.uk> #7
I actually have a WIP fix for it:
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} )
}
ju...@gmail.com <ju...@gmail.com> #8
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
ap...@google.com <ap...@google.com> #9
Branch: androidx-main
commit e303243b7b3b27281485a333c408d16a4a2ff151
Author: Jeremy Woods <jbwoods@google.com>
Date: Fri Jul 15 15:59:41 2022
Ensure Menu ComponentActivity always pass Menu callbacks
There is an issue where if you use the old Menu APIs without calling
super on an implementation of ComponentActivity, then Fragments will
never get the callbacks.
Instead of override the option menu APIs, we should override the more
encompassing panel menu APIs.
RelNote: "ComponentActivity will now properly dispatch menu calls
without the need to call the super function."
Test: existing tests pass
Bug: 238057118
Change-Id: Ie33c57e900be51ab49abfdbe5c57407f61553167
M activity/activity/src/androidTest/AndroidManifest.xml
M activity/activity/src/main/java/androidx/activity/ComponentActivity.java
M activity/activity/src/androidTest/java/androidx/activity/ComponentActivityMenuTest.kt
jb...@google.com <jb...@google.com> #10
This has been fixed internally to ensure that we respect the old default behavior of not requiring the super call.
This will be included in the Activity 1.5.1
release.
rp...@gmail.com <rp...@gmail.com> #11
Thank you for this, both the comments and the fix - much appreciated. I realise how this fits together now, and the outcome is the ideal one.
na...@google.com <na...@google.com> #12
This bug was linked in a change in the following release(s):
androidx.activity:activity:1.6.0-rc02
an...@gmail.com <an...@gmail.com> #13
A little late to the party here. We are overriding override fun onOptionsItemSelected(item: MenuItem): Boolean {
in the activity in order to have the back arrow (in the toolbar auto generated by nav controller) to behave the same as the back button pressed (eg. swipe). We create and dispatch OnBackPressedCallback
in the Fragment, and then do the following in the activity:
override fun onOptionsItemSelected(item: MenuItem): Boolean {
Timber.e("Does this get called?")
// This is again silly. In order for onNavigationUp to behave as back button pressed, we
// have to override toolbar.
when (item.itemId) {
android.R.id.home -> { ... }
}
}
However, I've noticed that with the upgrade to API 34 onOptionsItemSelected
does not get called anymore, hence the arrow press back and the swipe back behave differently. We don't inflate or set any menu's. We are purely overriding onOptionsItemSelected
, because that was the suggested solution for back arrow in navigation component to behave the same as the swipe back. What is the recommended solution now? Thank you
Description
Version used: 1.5.0
Theme used: -
Devices/Android versions reproduced on: -
When updated the androidx fragment from 1.4.0 to 1.5.0 the onCreateOptionsMenu is not called anymore.
SetHasOptionsMenu(true) is called so the menu shall be enabled and everything is working on 1.4.0. Not sure if the issue is related on activity or fragment but it was introduced on 1.5.0.
However the onPrepareOptionsMenu is still called.
Our application uses the old menu methods heavily so migration to MenuProvider is not feasible.