Status Update
Comments
jb...@google.com <jb...@google.com>
be...@google.com <be...@google.com> #2
Please star
ap...@google.com <ap...@google.com> #3
il...@google.com <il...@google.com> #4
b9...@gmail.com <b9...@gmail.com> #5
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
be...@google.com <be...@google.com> #6
Please star
b9...@gmail.com <b9...@gmail.com> #7
b9...@gmail.com <b9...@gmail.com> #8
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?
ap...@google.com <ap...@google.com> #9
- 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.
b9...@gmail.com <b9...@gmail.com> #10
il...@google.com <il...@google.com> #11
b9...@gmail.com <b9...@gmail.com> #12
za...@gmail.com <za...@gmail.com> #13
I believe I'm facing another issue because of this fix:
When navigating to an activity that belongs to a dynamic module, the AbstractProgressFragment
is not removed from the back stack. The line that's supposed to do it was moved from onResume
to onViewCreated
:
if (navigated) {
findNavController().popBackStack()
return
}
And onViewCreated
is not called since we're coming back from another activity.
Moving that block back to the onResume
method should solve the problem. In the meantime (as a workaround), I guess we can do as follows:
class CustomProgressFragment : AbstractProgressFragment() {
private var navigated = false
override fun onResume() {
super.onResume()
// Workaround:
// AbstractProgressFragment is not being removed from the back stack when returning from another activity
if (navigated) findNavController().popBackStack()
}
override fun onInstalled() {
testing = true
}
...
...
}
za...@gmail.com <za...@gmail.com> #14
Update:
Regarding the workaround I mentioned, this is the correct implementation of the onInstalled
method
override fun onInstalled() {
navigated = true
}
il...@google.com <il...@google.com> #15
Re onViewCreated()
is indeed called when you return to the AbstractProgressFragment
from another fragment, which is the only thing your newly loaded graph should have as its start destination. You...don't happen to have a start destination that is an activity destination? You shouldn't be using Dynamic Navigation at all in that case (as the system will auto-download the module your activity is in upon request).
Description
Component used: androidx.navigation:navigation-dynamic-features-fragment
Version used:2.3.0 Devices/Android versions reproduced on: all devices/android versions
override fun onResume() { super.onResume() if (navigated) { findNavController().popBackStack() return } var monitor = installViewModel.installMonitor if (monitor == null) { Log.i(TAG, "onResume: monitor is null, navigating") navigate() monitor = installViewModel.installMonitor } if (monitor != null) { Log.i(TAG, "onResume: monitor is now not null, observing") monitor.status.observe(this, StateObserver(monitor)) } }
Any time onResume() is called, monitor.status observed. When dynamic feature module is installed, each StateObserver will call navigate() and destination activity/fragment will be navigated multiple time