Both 1) and 2) end up doing the same thing the end, but 2) is always a safer option.
When you call dismiss()
, the DialogFragment
is dismissed and the DialogFragment
is stopped (it receives a callback to onStop()
). This triggers the listener in DialogFragmentNavigator
, which then updates the NavController
's state by calling popBackStack()
.
dismiss()
however, is an asynchronous operation (as seen in the DialogFragment
source code - you'll note it does not use commitNow()
, etc). Therefore if you were to check what destination you are on from the NavController.getCurrentDestination()
, you'd see that you're still on the dialog destination, despite having triggered the dismissal.
navigateUp()
, on the other hand, goes directly to the NavController. Since you have another destination on your back stack (the one under the DialogFragment
), the NavController
source code shows that navigateUp()
just calls popBackStack()
- the same operation that dismiss()
was eventually triggering.
However, when it is the NavController
that is driving the operation, NavController
updates its state synchronously. This means that immediately after you call navigateUp()
, it will have updated its getCurrentDestination()
and internal state in addition to calling through to DialogFragmentNavigator
's popBackStack()
, which is what calls through to dismiss()
(removing the observer mentioned above to prevent double dismissals).
Therefore calling navigateUp()
is always the safer choice since it ensures that the NavController
is synchronously updated to the correct state, rather than rely on FragmentManager
's asynchronous timing (which may mean that additional click events are received during that time period due to multi-touch, etc.).
Calling navigate()
with an action that has an app:destination
on it will navigate to a new instance of the destination, which would not be appropriate for returning back to your previous instance.