Fixed
Status Update
Comments
al...@google.com <al...@google.com> #2
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.
al...@google.com <al...@google.com> #3
Turns out, we already had a tracking bug for this issue, will follow up on that other one.
bu...@google.com <bu...@google.com> #4
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.
bu...@google.com <bu...@google.com>
al...@google.com <al...@google.com> #5
Stepping back a bit, right now we have:
File name | Reviewed | Checked |
---|---|---|
current.txt |
x | x |
public_plus_experimental_current.txt |
x | |
restricted_current.txt |
* |
- Only for non-atomic groups
What we really want is the AND
of:
Annotation | Reviewed | Checked |
---|---|---|
(default) | yes | yes |
@RequiresOptIn |
yes | no |
@RestrictTo(LIBRARY) |
no | no |
@RestrictTo(LIBRARY_GROUP) |
no | * |
@RestrictTo(LIBRARY_GROUP_PREFIX) |
no | yes |
- No for atomic groups, yes otherwise
So I'm wondering if we can eliminate public_plus_experimental_current.txt
and embed the "Checked" state into a Metalava flag. Then we'd have current.txt
as reviewed APIs and restricted_current.txt
as unreviewed (but still checked) APIs.
al...@google.com <al...@google.com> #6
Checked with Aurimas offline, it sounds like merging the two files and conditionally checking compatibility based on annotations would be feasible. This isn't urgent, so I'm re-scoping to cover that as well.
bu...@google.com <bu...@google.com> #7
Hi. I've received your bug, you didn't specify what to wait for so I will wait for b/278769092 to be resolved and then assign the bug to alanv@google.com.
Bugjuggler: b/278769092 -> assigned to alanv@google.com
Bugjuggler:
Description
Health Connect, at least, would like experimental APIs reviewed up-front rather than after they have been promoted to non-experimental during the following alpha.