Status Update
No update yet.
Comments
zh...@google.com
zh...@google.com
This requirement for addObserver to be called on the main thread is part of the 2.3.0-alpha06 release notes
LifecycleRegistry now verifies that its methods are called on main thread. It was always a requirement for lifecycles of activities, fragments etc. An addition of observers from non-main threads resulted in hard to catch crashes in runtime.
It affects all APIs that use Lifecycle, including Navigation.
yb...@google.com
Thanks! Somehow I've missed that.
zh...@google.com
Branch: androidx-main
commit 76230d4cbcf193ad3c01e2fb317a1bb3c571b1de
Author: Ian Lake <ilake@google.com>
Date: Tue Apr 06 12:53:25 2021
Mark navigate/setGraph as @MainThread
With the upgrade to Lifecycle 2.3.1,
Lifecycle now enforces that all creation and
changes to the Lifecycle state (including adding
and removing observers) should be done on the
main thread.
By marking navigate() and setGraph() as
`@MainThread`, we can give developeres better
visibility that these operations should only
be done on the main thread.
Relnote: "Navigation now depends on
[Lifecycle `2.3.1`](/jetpack/androidx/releases/lifecycle#2.3.1)
and now marks `setGraph()` and `navigate()`, the
methods that update the `NavBackStackEntry` `Lifecycle`,
as `@MainThread`, aligning Navigation with the main thread
enforcement introduced in Lifecycle `2.3.0`."
Test: existing and updated tests pass
BUG: 171125856
Change-Id: Ifcbe407d9cb186b50f05cbbd8bc5e11e19115a82
M navigation/navigation-dynamic-features-fragment/src/androidTest/java/androidx/navigation/dynamicfeatures/fragment/DynamicNavHostFragmentTest.kt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/build.gradle
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
yb...@google.com
For the upcoming Navigation 2.4.0-alpha01 release, we've made it explicit that setGraph() and navigate() should only be called on the main thread (by adding @MainThread annotations to the methods), thus aligning with the main thread enforcement of Lifecycle 2.3.
yb...@google.com
ap...@google.com
Branch: androidx-main
commit 00c608a86c44b066198bd8c1dc7e2aef6088d4e1
Author: Ian Lake <ilake@google.com>
Date: Mon Apr 12 14:04:54 2021
Mark popBackStack and navigateUp as @MainThread
In addition to the navigate() and setGraph()
methods updated in
the methods for popping the back stack
should also be marked as @MainThread.
Relnote: "Navigation now depends on
[Lifecycle `2.3.1`](/jetpack/androidx/releases/lifecycle#2.3.1)
and now marks all of the methods that update the
`NavBackStackEntry` `Lifecycle`, including `setGraph()`,
`navigate()`, `popBackStack()`, and `navigateUp()`,
as `@MainThread`, aligning Navigation with the main thread
enforcement introduced in Lifecycle `2.3.0`."
Test: existing and updated tests pass
BUG: 171125856
Change-Id: Ib8bedbb3fe384b28c7441cbd57a0751eba307a2b
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
th...@shareforce.eu
In my code I keep a reference to the supervisorJob used in the datastore scope:
val job = SupervisorJob()
val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "dynamic name", CoroutineScope(Dispatchers.IO + job)
When the datastore is no longer in use, I call job.cancelAndJoin(). Does this change imply cancelling is no longer needed?
yb...@google.com
you still need to explicitly cancel if you want to re-open the same file via another instance. This is because StorageConnection objects still need to be explicitly closed and even when we are not observing the file, DataStore instance claims ownership of it.
There is a relevant FR about that here:
th...@shareforce.eu
Thank you for your quick answer and the relevant information, much appreciated.
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.datastore:datastore-core:1.1.0-beta02androidx.datastore:datastore-core-android:1.1.0-beta02androidx.datastore:datastore-core-iosarm64:1.1.0-beta02androidx.datastore:datastore-core-iossimulatorarm64:1.1.0-beta02androidx.datastore:datastore-core-iosx64:1.1.0-beta02androidx.datastore:datastore-core-jvm:1.1.0-beta02androidx.datastore:datastore-core-linuxx64:1.1.0-beta02androidx.datastore:datastore-core-macosarm64:1.1.0-beta02androidx.datastore:datastore-core-macosx64:1.1.0-beta02
Description
we already have versioning check to avoid issues there.