Fixed
Status Update
Comments
an...@backx.org <an...@backx.org> #2
I assume we'll have to start using separate Activities for nested navigations like this.
il...@google.com <il...@google.com> #3
By default, Fragments **do not** pop anything added to the back stack of child fragments.
To get the system back button to pop child Fragments of your Fragment C, you must specifically opt into that behavior by calling setPrimaryNavigationFragment():https://developer.android.com/reference/android/support/v4/app/FragmentTransaction#setprimarynavigationfragment
This can be done anywhere in your Fragment after your Fragment is attached. For example, you can update your Fragment to do it in onActivityCreated():
override fun onActivityCreated(savedInstanceState: Bundle?) {
super.onActivityCreated(savedInstanceState)
// This routes the system back button to this Fragment
requireFragmentManager().beginTransaction()
.setPrimaryNavigationFragment(this)
.commit()
}
This is actually the same technique that the app:defaultNavHost="true" attribute on NavHostFragment is using under the hood.
To get the system back button to pop child Fragments of your Fragment C, you must specifically opt into that behavior by calling setPrimaryNavigationFragment():
This can be done anywhere in your Fragment after your Fragment is attached. For example, you can update your Fragment to do it in onActivityCreated():
override fun onActivityCreated(savedInstanceState: Bundle?) {
super.onActivityCreated(savedInstanceState)
// This routes the system back button to this Fragment
requireFragmentManager().beginTransaction()
.setPrimaryNavigationFragment(this)
.commit()
}
This is actually the same technique that the app:defaultNavHost="true" attribute on NavHostFragment is using under the hood.
an...@backx.org <an...@backx.org> #4
Yes, I looked at the onAttach from the NavHostFragment. However I'm talking about nesting NavHostFragments which do not escalate the back button behavior down to the child fragment because of how primary navigation fragments works. We're currently using separate activities for the use of multiple Bottom Navigation Views in our app. But I thought I'd still ask around whether there are plans to support nesting NavHostFragments.
il...@google.com <il...@google.com> #5
Sorry, let me try to clarify. This is already supported and you can get it working right now. Each nested FragmentManager needs to have its primary navigation fragment. By using app:defaultNavHost="true" on your top-level NavHostFragment, it gets system back press events.
What you need to do manually right now is ensure that your Fragment destination hosting your nested NavHostFragment tells its parent FragmentManager (the one returned by requireFragmentManager()) that it wants system back button presses.
Then, assuming your nested NavHostFragment also uses app:defaultNavHost="true", system back presses will successfully go from your root NavHostFragment -> your Fragment -> your nested NavHostFragment.
I'll reopen this to evaluate if it would be possible to call setPrimaryNavigationFragment as part of FragmentNavigator's operations to remove the manual step.
What you need to do manually right now is ensure that your Fragment destination hosting your nested NavHostFragment tells its parent FragmentManager (the one returned by requireFragmentManager()) that it wants system back button presses.
Then, assuming your nested NavHostFragment also uses app:defaultNavHost="true", system back presses will successfully go from your root NavHostFragment -> your Fragment -> your nested NavHostFragment.
I'll reopen this to evaluate if it would be possible to call setPrimaryNavigationFragment as part of FragmentNavigator's operations to remove the manual step.
an...@backx.org <an...@backx.org> #6
> What you need to do manually right now is ensure that your Fragment destination hosting your nested NavHostFragment tells its parent FragmentManager (the one returned by requireFragmentManager()) that it wants system back button presses.
This is what I was looking for, my apologies for the confusion. I couldn't find anywhere how to get the parent FragmentManager to allow its children to receive back button presses. We currently went with multiple activities for multiple navigation graphs, but are still interested in this.
> I'll reopen this to evaluate if it would be possible to call setPrimaryNavigationFragment as part of FragmentNavigator's operations to remove the manual step.
Regardless of whether this will be done, could more documentation be added in the future regarding nested NavHostFragments? I'd also appreciate some deeper documentation, how it handles the transactions and works with the fragment manager behind the scenes.
This is what I was looking for, my apologies for the confusion. I couldn't find anywhere how to get the parent FragmentManager to allow its children to receive back button presses. We currently went with multiple activities for multiple navigation graphs, but are still interested in this.
> I'll reopen this to evaluate if it would be possible to call setPrimaryNavigationFragment as part of FragmentNavigator's operations to remove the manual step.
Regardless of whether this will be done, could more documentation be added in the future regarding nested NavHostFragments? I'd also appreciate some deeper documentation, how it handles the transactions and works with the fragment manager behind the scenes.
be...@google.com <be...@google.com> #7
Joshua, we can triage these nav doc bugs I'm assigning together when I'm back.
il...@google.com <il...@google.com> #8
We've updated FragmentNavigator such that it always sets the current Fragment as the primary navigation fragment and the change will be available in alpha05.
This means that nesting NavHostFragments that use app:defaultNavHost="true" will 'just work' when it comes to the system back button - the inner NavHostFragment's back stack will be cleared before the outer NavHostFragment is popped.
This means that nesting NavHostFragments that use app:defaultNavHost="true" will 'just work' when it comes to the system back button - the inner NavHostFragment's back stack will be cleared before the outer NavHostFragment is popped.
il...@google.com <il...@google.com> #9
And by alpha05, I mean alpha04. Getting ahead of myself :)
an...@backx.org <an...@backx.org> #10
This is great to hear. I'm curious as to what is recommended when for example you need to navigate between screens with different BottomNavigationViews. Is it recommended to have separate activities or nested NavHostFragments? If it's NavHostFragments, how should this best be achieved? Would love some added documentation on this in time for alpha04.
Also thank you very much for the quick responses on the issue!
Also thank you very much for the quick responses on the issue!
il...@google.com <il...@google.com> #11
Per the material design guidelines (https://material.io/design/components/bottom-navigation.html ), bottom navigation bars should be consistent and appear on the bottom on every screen so changing the BottomNavigationView isn't really a recommended pattern.
ra...@gmail.com <ra...@gmail.com> #12
1.0.0-alpha04 introduces a new bug where using a BottomNavigationBar 'NavigationUI.setupWithNavController(bottom_bar, navController)' results in the BottomNavBar not being synchronized.
The selected tab icon is not set when the fragment changes, it stays on the last icon that was tapped.
The selected tab icon is not set when the fragment changes, it stays on the last icon that was tapped.
Description
Version used: 1.0.0-alpha02
Devices/Android versions reproduced on: Nexus 5, OnePlus One
We want to implement nested NavHostFragments because we want to navigate between 2 screens that each have 2 different Bottom Navigation Bars. We also thought about nesting NavHostFragments so we can bind ViewModels to a navigation part of our app. Parts that need to clean up the data they were using after being navigated through. The problem we're facing is that the outer most NavHostFragment intercepts the back button navigation before the child NavHostFragments do. The result is that when pressing the back button, it completely goes back to the destination before the child NavHostFragment. Are there any plans to support nesting NavHostFragments or is there a different solution to nested navigation that is seemingly not supported by nesting navigation graphs because I don't see how you can for example navigate between fragments with different Bottom Navigation Bars and navigate the fragments that belong to the Bottom Navigation Bar?