Should we be disabling onPressBack in a TopAppBar in order to prevent popBackStack() spam? on Navigation Compose 2.6.0. I don't run into this issue but on 2.7.5. I do. If I have two screens with their own backButton, I'm able to spam click through until I end up with an empty graph. Edit: I've attached multiple videos showing the behavior between 2.6.0. and 2.7.5. on both my app and a sample project app which I've provided the code file for in the thread. Any suggestions would be much appreciated.

Does the same happen when you call navigateUp instead? In fact I think the top app bar's back button is the only place where you want to call navigateUp anyway, so I would try with that too.

I'll give that a shot, thanks.

Please do tell here if that helps, I am very curious myself too. Otherwise it may be worth pinging someone from Google to hear their thoughts about this.

For sure! My MainActivity.kt plops right into a new compose sample project created with Android studio, and the only variable you need to change to test is from compose navigation 2.6.0 to 2.7.0+ in order to test it, if you wanted to play around with it. But when I get back to the desk I'll try navigateUp() instead

Are you only handling button clicks when the Lifecycle of the current screen is RESUMED? That's how you prevent clicks when a transition is already happening. Otherwise, yeah, tapping it multiple times will pop multiple times (and you'd want to stop showing the button if your current screen is the start destination of your graph (which should always be the last screen before leaving your app)

So the start destination of my graph does not include the back button at all. I'm not doing anything special with my button clicks at all. But it seems like the multiple presses from the screens that do have back button on clicks that pop the back stack are causing the last screen on the stack which does not have a back button to be popped off. My Main activity.kt I shared above is a simple example I created using the compose template from Android studio and you can reproduce by building to emulator and pressing the buttons to navigate to the end and then spam clicking the back button on the top app bar. I've demonstrated this in some videos above as well. Do you have any examples of only handling button clicks if the current screen is resumed like you've mentioned?

Thanks for sharing. I'm guessing you would always want to do this check for the back button of a TopAppBar?

It certainly does happen on every version of Navigation. The default animations we get from AnimatedContent are a bit slower though, so it may certainly be easier to trigger. Mouse clicking in an emulator is way faster than a finger if you want to try that

Right, I've only tried mouse clicking for both 2.6.0 and 2.7.3. I guess I'm just not fast enough as I've only ran into it on 2.7.3. I guess as a rule of thumb should we be doing what you suggested in that stack overflow post? Are there ever cases when a simple popBackStack alone is good enough? Or would you always want to check either the lifecycle or disable the button after being clicked once.

Like I said, do you want to pop more things while a transition is happening? That's a legit thing to do (you can do that with the system back button for instance). You can do that, but then you have to make sure you don't run out of back stack to pop

Hmmm, considering that I've switched to a per screen TopAppBar and that back action should only navigate from current screen to previous screen only, probably not. The behavior with the system back button will at least close the app out if a spam happens, whereas the issue I'm having with popBackStack leaves me with an empty screen the color of my Scaffold background color.

The

popBackStack

guide does specifically say that if it returns false, you need to finish your activity: https://developer.android.com/guide/navigation/backstack#handle-failure But the Up button in a TopAppBar should never exit your app - that's the key difference between Up and system back. Which is why

navigateUp

exists

I see. I'm planning on giving navigateUp() a shot. I have a screen that implements a backHandler and then shows a confirmation dialog. Would I want this to perform navigateUp() as well? So far I haven't thought of a case where I've wanted my TopAppBar back button action to do anything different that the system back button. (Especially since my topmost screen on the back stack does not have a back button but a hamburger icon that opens a modal drawer).

A BackHandler never, ever should be calling any NavController operation. It should only be

enabled

when it should be handling back and disabled otherwise (to let Navigation handle back). That's how you'll get the Predictive Back animation for free in the future

Apologies, the backHandler simply shows a dialog when enabless. It's the confirmation action on the dialog I'm talking about. Should that popBackStack? Or should that navigateUp() same as what I'm planning on switching the TopAppBar action to?

No, you'd just call

popBackStack

So I'd want to have two lambdas, one for handling the back action from the dialog and one for handling the back action from the TopAppBar?

Seems reasonable since they're two separate things

I see. Even with navigateUp() you'd probably still want to check the LocalLifecycleOwners state, right? I wouldn't think that using navigate up would inherently protect against an extra onClick from happening during a transition.

It does not, no

I noticed here: https://github.com/android/nowinandroid/blob/main/app/src/main/kotlin/com/google/samples/apps/nowinandroid/navigation/NiaNavHost.kt. the onBackClick for search screen which is tied to a back button in a top app bar simply calls popBackStack, they're also using compose 2.7.3. so would it be likely to run into this issue on this app here? I'm guessing that popBackStack here is also not ideal since it's a TopAppBar? Or is it because of the way that the app is modularized and it might not be possible to know where that back action is going to be implemented so popBackStack is used instead?

Any click event would have this issue, it isn't Navigation specific. That's just a specific example of something you may not want to trigger during an animation. A submit button might want that same behavior but for a different reason

Yeah I kind of figured that'd be the case. Seems like it'd make sense to make a Util function that takes in an action for handling this for any onClick event that we're wanting to prevent multiple actions on? Or is it more common to just disable buttons after they've been clicked?

Disabled buttons change their visual appearance, which might be what you want for some cases (a Submit button maybe), but not for others (you wouldn't want your button to change appearance while sliding off screen). Really you need to take these case by case and figure out 1) what state you care about 2) what changes that state makes on your UI

Makes sense. I appreciate your time!

Guarding against navigation events when the lifecycle isn't resumed has definitely resulted in bugs sometimes for me, so be careful when you do that too. In particular, I was triggering a navigation event as a bottom sheet was dismissed, after the user had finished inputting something there and pressed confirm. That button closed the bottom sheet and triggered the nav event. Little did I know that meant that the lifecycle was not resumed at that point. Another one was when there was an event coming from the VM which resulted in me wanting to navigate (successfully did something, so wanna go to success screen). Then it just so happened that sometimes, the user would've not been in the resumed state at that exact moment, I think again due to bottom sheets animating? Don't remember. Again, used unsafe navigation for that case and it worked. That's why I made this navigate function which takes the NavBackStackEntry, for the normal scenarios, and then one which just is called unsafe that just navigates directly, for these scenarios. https://github.com/HedvigInsurance/android/blob/develop/app/app/src/main/kotlin/com/hedvig/android/app/navigation/HedvigNavHost.kt#L283-L314 Haven't found a better way to do this.