CODEWITHSUNDEEP
androidnavigationandroid-architecture-components
me.at.coding
me.at.coding

Reputation: 17766

Correct way to close DialogFragment when using Navigation component?

I am using the Navigation component to show a DialogFragment (<dialog...>...</dialog> in the navigation.xml) and want to know what's the recommended way to close the Dialog. I tried myself and got the following results:

1) dismiss()in DialogFragment: seems to work fine

2) findNavController().navigateUp(): seems to work fine

3) findNavController().navigate(MyDialogFragmentDirections.actionMyDialogFragmentToMyNormalFragment()): works, but loads a fresh version of the target destination, so depending on the use case this might not be what one wants to have.

Note: My use case is that MyNormalFragmentuses MyDialogFragmentto get some input, so after MyDialogFragmentis shown, I need to get back to the already existing instance of MyNormalFragment.

So for me, only 1) or 2) is correct. Now I am wondering, is there any difference between 1) and 2) ?

Upvotes: 19

Views: 10451

Answers (2)

Vikash Kumar Tiwari
Vikash Kumar Tiwari

Reputation: 835

You need to make sure dismiss() is called inside MyNormalFragment beefore MyDialogFragment is resumed. It is achievable by simply calling dismiss() before closing the MyDialogFragment.If you want you can also put check like below

 if (navController.currentDestination?.id == R.id_my_dialog_fragment_dest) {
        navController.navigateUp()
}

Where R.id_my_dialog_fragment_dest is destination id of the MyDialogFragment in navigation graph

Upvotes: 0

ianhanniballake
ianhanniballake

Reputation: 200080

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.

Upvotes: 39

Related Questions