Fixed
Status Update
Comments
so...@gmail.com <so...@gmail.com> #2
Only the `argType="reference"` accepts resource IDs (and returns an int that you'd pass to getContext().getString()), so it is working as intended that a "string" type is exactly what you put into your XML. It was important that the build time code gen and the runtime behavior always matches and that was not possible in the general cases - see edge cases such as https://issuetracker.google.com/issues/111736515 for some background.
Please starhttps://issuetracker.google.com/issues/36994900 to track progress towards allowing placeholders in XML files, which would be the recommended way of filling in placeholders at compile time.
Please star
il...@google.com <il...@google.com> #3
Ok thanks, I understand now, I wasn't aware of argType="reference". Anyway I think it is a bit strange that behavior is different if we navigate using safe args gen code (navController.navigate(WebPageFragmentDirections.actionGlobalHomeFragment())) and code without safe args (navController.navigate(R.id.homeFragment)) if the navigation xml file is the same.
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #4
Yes, I think we can make it more explicit that only reference types can have references to other resources.
ka...@gmail.com <ka...@gmail.com> #5
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bb456e84a524d4e5cd241a6a839a1062297b9cf4
Author: Ian Lake <ilake@google.com>
Date: Thu Jan 31 15:46:55 2019
Enforce "reference" types for reference default values
In order to ensure that inflation of a navigation
graph results in the same arguments as Safe Args,
we now enforce usage of the "reference" type for any
argument that has a defaultValue that references
another resource (i.e., @string/app_name, etc).
This makes it much more obvious that the default value
in Safe Args is in the form of R.string.app_name and
any provided override for that should also be in the
form of R.string.some_value.
In these cases, it is expected that developers either
1) Use the ids directly (for example, passing an
R.string to a method that takes a resource id)
2) Specifically call context.getString() with the
resource id they retrieve from their NavArgs instance.
Test: updated NavInflaterTest
Change-Id: I06b8c9a0d1420821b8c0064c22f176788da43d7a
Fixes: 123551990
M navigation/runtime/src/androidTest/java/androidx/navigation/NavInflaterTest.kt
M navigation/runtime/src/androidTest/res/navigation/nav_default_arguments.xml
A navigation/runtime/src/androidTest/res/navigation/nav_invalid_argument_arg_type.xml
A navigation/runtime/src/androidTest/res/navigation/nav_invalid_argument_default_value.xml
M navigation/runtime/src/main/java/androidx/navigation/NavInflater.java
https://android-review.googlesource.com/891680
https://goto.google.com/android-sha1/bb456e84a524d4e5cd241a6a839a1062297b9cf4
Branch: androidx-master-dev
commit bb456e84a524d4e5cd241a6a839a1062297b9cf4
Author: Ian Lake <ilake@google.com>
Date: Thu Jan 31 15:46:55 2019
Enforce "reference" types for reference default values
In order to ensure that inflation of a navigation
graph results in the same arguments as Safe Args,
we now enforce usage of the "reference" type for any
argument that has a defaultValue that references
another resource (i.e., @string/app_name, etc).
This makes it much more obvious that the default value
in Safe Args is in the form of R.string.app_name and
any provided override for that should also be in the
form of R.string.some_value.
In these cases, it is expected that developers either
1) Use the ids directly (for example, passing an
R.string to a method that takes a resource id)
2) Specifically call context.getString() with the
resource id they retrieve from their NavArgs instance.
Test: updated NavInflaterTest
Change-Id: I06b8c9a0d1420821b8c0064c22f176788da43d7a
Fixes: 123551990
M navigation/runtime/src/androidTest/java/androidx/navigation/NavInflaterTest.kt
M navigation/runtime/src/androidTest/res/navigation/nav_default_arguments.xml
A navigation/runtime/src/androidTest/res/navigation/nav_invalid_argument_arg_type.xml
A navigation/runtime/src/androidTest/res/navigation/nav_invalid_argument_default_value.xml
M navigation/runtime/src/main/java/androidx/navigation/NavInflater.java
Description
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on:
Assuming:
- Main Activity has a NavHostFragment, which navigates between Fragment A & Fragment B
- Main activity handles going back with onSupportNavigateUp
- Fragment B has it's own NavHostFragment, which navigated between InnerFragmentB1 & InnerFragmentB2
- Parent NavHostFragment navigates from A -> B (which starts with B1)
- Sub NavHostFragment navigates from B1 -> B2
- Press up: Sub NavHostFragment returns to B1
- Press up: Parent NavHostFragment returns from B to A
What's the proper way of handling these types of situations where we'd like the back button to handle backing out of Inner Fragments first and then Outer Fragments after?
Details here:
Sample Code: