NavigationDrawerItem prevent reselect if fragment is showing
IntelliJAbhishek opened this issue · 7 comments
About this issue
Suppose There is a HomeFragment when we click home again it will relaunch HomeFragment which should be prevented. Also if we are observing a livedata on that fragment then two observers will be register that will lead to crash.
Details
Version - 8.3.3
My Implementation
NavigationDrawerItem(R.id.homeFragment, PrimaryDrawerItem().apply {
nameRes = R.string.drawer_item_home
iconDrawable = ContextCompat.getDrawable(context, R.drawable.ic_baseline_home_24)
isIconTinted = true
})
And Click Listener
setupWithNavController(navController){ _, drawerItem, _ ->
Timber.e("Drawer Click");
if (drawerItem is Nameable) {
Toast.makeText(
this@MainActivity,
drawerItem.name?.getText(this@MainActivity),
Toast.LENGTH_SHORT
).show()
}
false
}
Clicking on same item relaunching same route again and again.
We can check currentdestination in DrawerNavigationUI.kt and then only navigate
private fun performNavigation(item: IDrawerItem<*>, navController: NavController): Boolean {
return when (item) {
is NavigationDrawerItem -> {
try {
if(navController.currentDestination?.id != item.resId) //Add This check will prevent relaunch
navController.navigate(item.resId, item.args, item.options)
true
} catch (e: IllegalArgumentException) {
false
}
}
else -> false
}
}
let me know how can I override this code?
Wondering if we shall add:
if(navController.currentDestination?.id != item.resId) //Add This check will prevent relaunch
to the project. but I fear of this possibly breaking existing apps code
@mikepenz yeah I figured out that day and made a DrawerNavigationUICustom.kt and done necessary changes. Now it will not relaunch the same route when tapping same option multiple times.
But still I observed an issue. If we tap Route A then Route B then again Route A then two Route A is available in backstack . is it Intended? Or we can check if route is available in backstack and launch the same instance.
P.S. Adding if(navController.currentDestination?.id != item.resId)
doesn't break anything for me.
@IntelliJAbhishek the risk is, because it will be a behaviour change which can unintentionally result in a change existing users of the library don't expect.
The second issue you describe sounds like you may want to check the graph or navigation flow. The utils itself does not have much logic in regards of navigation. it will simply use the destination and navigate there when clicked. that's it.
any more advanced, ... requirements are most likely better served with either custom implementations as you noted above, or by using the normal approach of the drawer with listener, and then react on the click via the listener.
But I believe most of these things are not necessarily related to the MaterialDrawer
itself
@IntelliJAbhishek the risk is, because it will be a behaviour change which can unintentionally result in a change existing users of the library don't expect.
The second issue you describe sounds like you may want to check the graph or navigation flow. The utils itself does not have much logic in regards of navigation. it will simply use the destination and navigate there when clicked. that's it.
any more advanced, ... requirements are most likely better served with either custom implementations as you noted above, or by using the normal approach of the drawer with listener, and then react on the click via the listener.
But I believe most of these things are not necessarily related to the
MaterialDrawer
itself
Yeah but there should be a reselect listener like Bottomnavigaview
@IntelliJAbhishek the MaterialDrawer
does not make a decision if something is reselected or different. it provides you with the click event, giving you all the power for all needs you may see.
practically this allows you to also remember what the previous choice has been if a reselection is non anticipated.
or similar as you already do, to check if you are at the proper destination before navigation away.
This library itself tries to stay very generic in these areas to allow for the most flexibility needed
Closing due to inactivity