Fixed
Status Update
No update yet.
Comments
tn...@google.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.
sp...@google.com
Turns out, we already had a tracking bug for this issue, will follow up on that other one.
sp...@google.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.
tn...@google.com
One interesting thing I've noticed:
It often happens that EXISTING id's that have not recently been added or modified, suddenly end up red!
Something goes in and makes these resources no longer recognized. I have not discovered yet what seems to trigger it.
It often happens that EXISTING id's that have not recently been added or modified, suddenly end up red!
Something goes in and makes these resources no longer recognized. I have not discovered yet what seems to trigger it.
be...@google.com
I'm becoming convinced the problem occurs when a VFS refresh (triggered by Git) happens for a file that doesn't have an in-memory Document associated with it. This means the corresponding PSI event is propertyChanged with com.intellij.psi.PsiTreeChangeEvent#PROP_UNLOADED_PSI, without any reference to the file in question. I can reproduce it reliably on my desktop.
I'll try to add a FileDocumentManagerListener to handle fileWithNoDocumentChanged and fileContentReloaded.
I'll try to add a FileDocumentManagerListener to handle fileWithNoDocumentChanged and fileContentReloaded.
be...@google.com
The change with FileDocumentManagerListener has landed in 3.6, so has improved (simplified) handling of @+id. I think this should resolve a lot of these problems.
tn...@google.com
Great! I haven't used the IDE in the last couple of weeks but I'll try it for a bit next week while traveling!
ch...@bigcommerce.com
I still occasionally have this issue in 3.6 Canary 9. For instance, after creating a new layout file, my Kotlin class is unable to resolve the R.layout reference. However, the app compiles and runs fine.
be...@google.com
I believe this is
Description
I've been building a sample app off and on over the last couple of weeks and I've repeatedly run into scenarios where I've added a resource, and the editor system (the resource repository?) does not see the new id. The symptom is that the editor shows the resource reference as a red symbol. I observed this with both canary 4 and now canary 5.
Take a look at the given screenshot; the @+id/headerText id is defined in the layout XML file on the bottom; it isn't only showing up as undefined R.id.headerText in a Kotiln file; it's even showing up as undefined when referenced later in the same layout file!
I have not figured out how to reproduce this. It has happened at least 4-5 times.
One time it happened when I went to the layout editor, dragged in a widget and renamed it in the property sheet, then switched back to the code editor. Another time it happened when I added a tag and id directly editing XML. Just now when the screenshot was taken I had done a git pull to pull in new sources, which included new id's, and I then gradle synced.
All I need to do to refresh things is to restart the IDE. Once I do that, things correct themselves (I don't have to invalidate caches, even though that's what I did the first couple of times I ran into it.)
I'll keep trying to reproduce this, but I wanted to make sure this was filed as a top priority bug. Let me know if there's something you want me to investigate or record. I've been deliberately trying to use our released bits but I can switch to master and add additional logging statements etc if that will help track this down.