IssueTracker

We have tests that ensure that onCreateView() is not called multiple times. If you can create a sample project that reproduces your issue, that would be most helpful.

I can guarantee that onCreateView() is indeed being called twice, and there is an onDestroyView() in between. So there may be an issue with your tests.

Were you not able to reproduce the problem with a BottomNavigationView and a call to startPostponedTransition()?

No, I was not able to reproduce it.

OK, I've created a sample project, reproducing the issue:
https://github.com/timusus/android-fragment-navigation-bug

I've noticed that this issue only occurs for the Fragment set as 'startDestination' in the navigation graph xml.

So to explain what the key players are:

1) Have a BottomNavigationView setup with NavController
2) Have a Fragment marked as the 'startDestination' in the navigation graph
3) Have that same Fragment perform postponeEnterTransition()

Also, to clarify. onCreateView() is not being called twice on the same Fragment instance, so I apologise - your tests may be fine. It appears there are two instances of the fragment in question.

Thanks, your sample app was very helpful in reproducing what you saw. I was able to reproduce it by going to the Home fragment, then tapping on the Dashboard button to go back to the Dashboard fragment.

If you look at the NavigationUI code (https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/navigation/navigation-ui/src/main/java/androidx/navigation/ui/NavigationUI.java#57), it does a few things when you click a MenuItem:
1) It adds the correct cross fade animations
2) It pops up to the start destination of your graph
3) It uses setLaunchSingleTop(true)

And then it navigates to the selected destination (i.e., the screen associated with the MenuItem you clicked) with the goal being that the user is at the exact correct location in the app.

Step 2) ensures that we don't keep an every growing stack. In your case, this pops the any instance of the Home or Notification fragment from the back stack. Step 3) ensures that there's only one instance of your start destination Dashboard fragment is on the back stack.

Why you're experiencing the behavior is due to the intersection of two things:
a) Fragments don't have a single top like functionality (there's no onNewIntent() like for an Activity), so FragmentNavigator, when faced with a single top operation like this one, pops the old instance and creates a new instance of the Fragment, passing through the new arguments, animations, etc.
b) As you've noticed, postponed Fragments are a special case that requires some extra work by FragmentManager. What happens is that the new Dashboard instance has its view created and becomes postponed. Since FragmentManager can't know when that will stop being the case, it basically reverses the replace() operation it was just about to do, causing the old Fragment to be eligible for having its view created. Therefore the second onCreateView() you see is the old instance having its view temporarily created to "fill the gap" until the new instance is available. After the new instance calls startPostponedEnterTransition(), the replace() is commited again and the old instance has its view removed.

From the Navigation perspective, it is indeed doing the right thing.

From the Fragment perspective, this case of pop+replace with a postponed Fragment is perhaps 'working as designed', but we're aware that the way that FragmentManager manages postponed Fragments is something that needs some improvement (to put it mildly). We have some ideas in this area, so I'll leave this issue open as a case we should specifically test to ensure it is fixed with any internal restructuring we do.

Thanks for the detailed response Ian, I appreciate it.

I wonder if this problem would go away if I used the google sample code for bottom navigation, where it maintains multiple backstacks (maybe that eliminates a 'pop') . I might give that a try.

Keep up the great work.