Fixed
Status Update
Comments
il...@google.com <il...@google.com>
il...@google.com <il...@google.com>
il...@google.com <il...@google.com> #2
Activity destinations should be considered exit points for your navigation graph - they are not part of the NavController's back stack and therefore not being sent to OnNavigatedListeners is working as intended.
ma...@marcardar.com <ma...@marcardar.com> #3
Thank you for your explanation, but although that is the intended behavior, it is still confusing.
In my opinion, the developer expects to be notified when any navigation action defined in the graph is performed, regardless the destination.
Although that action is considered an exit point, it is an action defined within the graph and it is indeed a navigation action happening in that graph, so I don't understand why it is not notified to the "OnNavigated" listener when it has indeed navigated, regardless if it affects or not the back stack.
I that is the intended behaviour, then it should be rather called something like "NavController.OnBackStackChangedListener".
In my opinion, the developer expects to be notified when any navigation action defined in the graph is performed, regardless the destination.
Although that action is considered an exit point, it is an action defined within the graph and it is indeed a navigation action happening in that graph, so I don't understand why it is not notified to the "OnNavigated" listener when it has indeed navigated, regardless if it affects or not the back stack.
I that is the intended behaviour, then it should be rather called something like "NavController.OnBackStackChangedListener".
Description
Version used: 1.0.0-alpha07
Devices/Android versions reproduced on: Android 8.1
This is a feature request.
In my Nav drawer I have a Settings item. Currently, using the Nav Architecture component, clicking this causes the current back stack to be popped up to (not including) the start destination, and then the Settings fragment is added on top of that. I would like to be able to customise this so that the pop does not occur - i.e. that the Settings fragment is simply placed on top of the current destination. Anyway, isn't this what the user would expect for a Settings screen?
The key method call seems to be on the second line of NavigationUI.setupWithNavController() where popUp = false is passed. Maybe whether to popUp or not could be specified in the nav_graph destination?