Feature Request P4
Status Update
No update yet.
Comments
il...@google.com
bo...@gmail.com
This actually has nothing to do with NavHostFragment, but is the behavior of NavController's setGraph().
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
When you call navController.setGraph(R.navigation.navigation_graph), it stores that ID and will restore that ID automatically.
If you were to instead use:
NavInflater navInflater = new NavInflater(this, navController.getNavigatorProvider());
navController.setGraph(navInflater.inflate(R.navigation.navigation_graph));
Then NavController would not restore the graph itself and the call to restoreState() you point out would only restore the back stack state, etc. but would wait for you to call setGraph again.
You're right that the inconsistency between the two setGraph methods is concerning. We'll take a look.
[Deleted User] <[Deleted User]>
Turns out, we already had a tracking bug for this issue, will follow up on that other one.
ro...@gmail.com
Thank you for promptly replying to my report. You are right that the issue you've just mentioned is similar to mine. I shall continue observing the progress over there.
il...@google.com
Re #4 - no, what you describe is covered in
This issue, on the other hand, is about enumerating a subset of argument possibilities in the navigation XML file itself such that only that subset of possibilities are valid.
Description
Version used: 1.0.0-alpha-01
Devices/Android versions reproduced on: -
Currently if you support multiple languages or domains you have to provide a separate deep link for each of them. This can be quite laborious and also error prone. Being able to define one deep link with multiple domains/languages would be very useful.
Some examples for this:
A company has multiple tlds per language. Every deep link should work in all of these countries.
The language can be part of the deep link (e.g. /en, /de etc). Each deep link should work in all supported languages.
A deep link URL could be translated into multiple languages (e.g. restaurant, ristorante etc). A deep link should be able to support multiple languages.
An idea how this could work:
<deepLink app:uri="www.google.{tld}/{language}/" />
<deepLink app:uri="www.google.{tld}/{language}/{restaurant}" />
<argument app:name="tld">
<value>
<value>com</value>
<value>de</value>
<value>it</value>
</argument>
<argument app:name="language">
<value>en</value>
<value>de</value>
<value>it</value>
<value>fr</value>
</argument>
<argument app:name="restaurant">
<value>restaurant</value>
<value>ristorante</value>
</argument>