-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nav-Framework is nice, however, it create fragment's view every time when people click menu-item on drawer-layout #419
Comments
Meet the same issue. Checked the code , in navigate function inside FragmentNavigator, it use "replace" for any fragment transaction, so it will call onCreate() and onCreateView() every time when we change the destination. Probably we can override Navigator<FragmentNavigator.Destination> and replace navigate function with our own implementation. Hope to have any other better solution~ |
Hey guys! Have you tried to run the sunflower app? I've tried and noticed the following behavior: when the user navigates from PlantListFragment to PlantDetailFragment and go back, the PlantListFragment is unchanged (holds the same state after the navigation). The bad thing is: when i try to create my own project with navigation, this behavior doesn't work. When the user goes back all the previous state is lost. Any of you had experienced something like that? Thanks! |
That PlantListFragment keeps it's state because it doesn't get destroyed, when you click on an item and navigate to PlantDetailFragment it creates a new instance of DetailFragment and places it on top of the backstack, leaving the ListFragment alive. When later on you press back, it navigates up, popping the DetailsFragment and leaving the ListFragment visible, meaning ListFragment was never recreated. |
Agreed with @aromano272 and @sociaxie. Inability of having proper backstack in nav controller is a huge productivity issue. Hope it's a missing feature or a work-around made on purpose... IMO this is a must-have and has to be introduced sooner rather than later (however: https://issuetracker.google.com/issues/109856764 says We won't be allowing customization of the transaction type (such as hiding/showing, etc) for the foreseeable future.) :( |
@ianhanniballake Can you please share your views on how to achieve the same, possibly with some example? |
Temporary solution I think, for BottomNavigationView, you should try NavigationAdvancedSample this example which mentioned in issue tracker for support multiple back stacks. And you should try to keep data in ViewModel and inflate layout with that data when fragment recreate. Most system provided view have already save its state in onSaveInstanceState, and you just need to make sure you keep the right data to restore the view state. For custom view, I think it's you responsibility to make your own SaveInstanceState logic. |
@ianhanniballake maybe you can share you views on this issue before you close it |
I've just faced the same issue and finally come up with the old way as follow:
|
Android navigation component is suck, Better switch to old school method... |
has anyone found the solution to it? |
Stiill on 2021, the same issue exist. Wow! |
I will share my solution to this. It is minimalistic as it re-uses the code from Register a destination change listener to keep your menu item checked status in sync with the current destination.
And register the below item selected listener to change the destination when a navigation menu item is clicked:
That's it! Note the |
Still, the issue exists!. I think we have to move older way instead of the navigation component. @ianhanniballake do you have any sample code for this issue. without a solution how you close this one. |
April, 2023. The problem still exists... |
I use NavController + DrawerLayout, set some menu-items on the drawer, it seems automatically setup the drawer, it's cool. But, each time I click one item on the drawer and click the same item several times, the Nav will navigate to the same fragment and onCreateView will be called each time, it's so SAD! It's definitive a bug because the initializing of a view is not cheap.
Any idea?
issues
Same problem: android/sunflower#117
The text was updated successfully, but these errors were encountered: