Fixed
Status Update
Comments
il...@google.com <il...@google.com> #2
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.
du...@gmail.com <du...@gmail.com> #3
Thanks! Somehow I've missed that.
il...@google.com <il...@google.com> #4
Project: platform/frameworks/support
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
https://android-review.googlesource.com/1665821
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
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #5
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.
il...@google.com <il...@google.com> #6
Project: platform/frameworks/support
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
https://android-review.googlesource.com/1665821
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
https://android-review.googlesource.com/1673448
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
du...@gmail.com <du...@gmail.com> #7
Ok, great, now it is much more straightforward. Thanks!
ne...@gmail.com <ne...@gmail.com> #8
This "fix" broke our app and our navigation XML, the file looked like the one described in the first message by OP and that's exactly how we wanted it to work.
Let me describe the use case.
Our Fragments load content based on the argument "url" (coming from backend) and the default value is required to load the initial content when the user starts the app.
Previously we had this default value stored in string resources where all the app strings can be easily accessed and reused across the app.
After this "fix" in beta01, we have to hardcode the default path in the navigation XML file and we have lost the ability to reference the same default path in the code (now the string is duplicated in string resources and in the navigation XML file).
Another undesired side-effect is that another argument used the default value of @string/null_ and now this doesn't work anymore forcing us to use an ugly empty string with a space character and in the Fragment check for blank string.
Could you enable resources references again just for default XML arguments for other argTypes?
Let me describe the use case.
Our Fragments load content based on the argument "url" (coming from backend) and the default value is required to load the initial content when the user starts the app.
Previously we had this default value stored in string resources where all the app strings can be easily accessed and reused across the app.
After this "fix" in beta01, we have to hardcode the default path in the navigation XML file and we have lost the ability to reference the same default path in the code (now the string is duplicated in string resources and in the navigation XML file).
Another undesired side-effect is that another argument used the default value of @string/null_ and now this doesn't work anymore forcing us to use an ugly empty string with a space character and in the Fragment check for blank string.
Could you enable resources references again just for default XML arguments for other argTypes?
il...@google.com <il...@google.com> #9
Re #8:
- String, object, and array argument types support using android:defaultValue="@null" for null default values. This continues to be the case.https://issuetracker.google.com/issues/120627532 tracks adding documentation around that fact
- I've filedhttps://issuetracker.google.com/issues/124248602 for supporting an empty (i.e., 0) default value for reference types
Resources cannot be statically resolved at build time - they are inherently only resolvable at runtime, so there's no way for Safe Args to know what default value to add to the generate code. Given that, there's no plans on supporting resource references on anything other than "reference" types.
- String, object, and array argument types support using android:defaultValue="@null" for null default values. This continues to be the case.
- I've filed
Resources cannot be statically resolved at build time - they are inherently only resolvable at runtime, so there's no way for Safe Args to know what default value to add to the generate code. Given that, there's no plans on supporting resource references on anything other than "reference" types.
mo...@gmail.com <mo...@gmail.com> #10
you need to remove the default value from the nav_graph and figure out an alternative logic to set it .. I do not think that would be so hard to do.
[Deleted User] <[Deleted User]> #11 Restricted+
Restricted+
Comment has been deleted.
Description
Version used: android.arch.navigation:navigation-safe-args-gradle-plugin:1.0.0-alpha11
Devices/Android versions reproduced on: not related to device/api version, it is code generation problem
Bug description:
navigation file defined like this:
<?xml version="1.0" encoding="utf-8"?>
<navigation xmlns:android="
xmlns:app="
xmlns:tools="
android:id="@+id/nav_graph"
app:startDestination="@id/homeFragment">
<fragment
android:id="@+id/homeFragment"
android:name="no.amedia.newsapp.android.WebPageFragment"
android:label="fragment_home"
tools:layout="@layout/fragment_web_page" >
<argument
android:name="web_url"
app:argType="string"
android:defaultValue="@string/url" />
</fragment>
<action android:id="@+id/action_global_homeFragment"
app:destination="@id/homeFragment" />
....
</navigation>
where url (referenced as "@string/url") is defined as <string name="url" translatable="false">
generates code like this:
class NavGraphDirections private constructor() {
private data class ActionGlobalHomeFragment(val webUrl: String = "@string/url") :
NavDirections {
override fun getActionId(): Int = no.amedia.newsapp.android.R.id.action_global_homeFragment
override fun getArguments(): Bundle {
val result = Bundle()
result.putString("web_url", this.webUrl)
return result
}
}
companion object {
fun actionGlobalHomeFragment(webUrl: String = "@string/url"): NavDirections =
ActionGlobalHomeFragment(webUrl)
}
}
so the problem is webUrl: String = "@string/url" instead of webUrl: String = "
the same is with WebPageFragmentDirections generated class:
class WebPageFragmentDirections private constructor() {
companion object {
fun actionGlobalHomeFragment(webUrl: String = "@string/url"): NavDirections =
NavGraphDirections.actionGlobalHomeFragment(webUrl)
}
when I try to use code like this
navController.navigate(WebPageFragmentDirections.actionGlobalHomeFragment())
or
navController.navigate(NavGraphDirections.actionGlobalHomeFragment())
argument value in the fragment is "@string/url" instead of "
while if I navigate like this
navController.navigate(R.id.homeFragment)
default value from navigation xml is used correctly and I get "
I hope that I manage to describe the problem in a proper way, it is very simple to reproduce, but if you have any questions just ask