Android Activity API provides developers a way to hook into back button functionality and even overwrite it. This power should be used with great care. Making back button behave in unexpected ways can easily destroy your application's user experience.
What back button does, technically
From technical point of view the back button manipulates the app's Activity stack. Pressing back calls finish on the active activity and removes it from the stack. If the app only has one activity or the current activity is the only one in the stack (ie. user has closed all the other ones) back button will close the application.
Behavior after pressing back or pressing home look very similar to the user. However, from technical point of view they are very different. Back will terminate the app but home will move the app to background.
Problem
Because the back button has the power of terminating the application it can also cause problems to the user. If the app manages data changes poorly or fails to save application's state on exit user can lose data when pressing back.
In some applications it doesn't make sense to store the application's full state on exit. A good example of this would be a file manager application where user will probably expect the application to start again from the sdcard root every time.
How to prevent accidental app exit
Note: All of the following should be used only if saving the app state on exit is not possible or if closing the application can otherwise make the user to lose work. If neither of these conditions are true the back button should just exit the app.
Double press back
Some apps prevent accidental app exit by requiring users to press back twice when the app is exiting. Common pattern is to display a toast to the user when he or she presses the back button on activity stacks last activity.
![]() |
ASTRO file manager app exit toast. |
![]() |
Postcard Express app exit toast. |
This functionality can easily be implemented by overriding main activity's onBackPressed() method. In this example when user presses back button the app will display a toast for 4 seconds on which time a new back press terminates the app immediately:
private Toast toast;
private long lastBackPressTime = 0;
@Override
public void onBackPressed() {
if (this.lastBackPressTime < System.currentTimeMillis() - 4000) {
toast = Toast.makeText(this, "Press back again to close this app", 4000);
toast.show();
this.lastBackPressTime = System.currentTimeMillis();
} else {
if (toast != null) {
toast.cancel();
}
super.onBackPressed();
}
}
Confirmation dialog
Some applications prompt user when it is about to exit. This seems to be particularly common with game apps. This practice is not recommended in normal applications. A confirmation prompt would disrupt user's normal workflow. Even in games using this option should be very carefully considered.
![]() |
Angry Birds app exit confirmation |
![]() |
Grave app exit confirmation |
Run in background
Some apps, like Spotify here, don't close when back is pressed if there's a process going on. In this case Spotify keeps running on background if a song is playing. This is indicated by a notification bar icon.
![]() |
Spotify doesn't close the app when pressing back |
Back long press for app home screen
Roman Nurik, a Android developer advocate from Google, tweeted an excellent idea for an extension to the normal back button behavior:
romannurik Roman Nurik Android UI idea: Long press BACK to get to the home screen of your app.
Generally hiding actions behind long press is not very good UI practice (it has some good uses like long pressing a list item to get context menu). Google has already replaced home long press as multi-tasking control in the latest Android version (3.0). In this case, however, I feel like long pressing back to bring user to the app's home screen is a good idea as the functionality is available to the user by other means also. Back long press in this case is just a shortcut for advanced users.
Thank you for the post, it's really interesting.
ReplyDeleteI have some ideas about it.
Let's start from the first variant. I think that waiting for 4 second to close the app is too long, users do't like to wait, they got accustomed back and close actions are immediate.
Back long press for app home screen. User also should wait, but the problem is that it's not a standard behaviour and user doesn't know how to use it.
I suppose confirmation dialog is the best way. App closing is out of normal workflow, and confirmation prompt will protect from accidental closing.
Hi vmakeev,
ReplyDeleteActually, in the first option user doesn't have to wait at all. Clicking back twice kills the app immediately. 4 seconds is the time out that resets the timer ie. if there has not been a second back press in 4 seconds instead of terminating the app back button will show the toast again.
Long press for home screen should definitely not be the only way to get app's home screen. It should be complementary to already available functions like pressing back until you reach home screen.
Good comments. Thanks :)
Oh, the first option is really suitable, I'll use it in my apps. Thanks for explanation.
ReplyDeleteNo problem. Glad I can help!
ReplyDeleteMaybe a bit late, but I just discovered this blog...
ReplyDeleteThe main trouble with the back button sadly wasn't in this post. It's navigation in an activity.
For example, the file explorer goes back to the previous folder, the default web browser to the previous page, and so on. This often makes it really complicated to end a task (opposed to interrupt it with the Home button). You eiter have to press the back button again and again and again, until you finally get out (maybe even after a query) or you need other ways, like the "Exit" button or menu entry Google discourages.
In my opinion, it would've been more consistent and easy to use if the back button would switch only between activities, while back actions inside the activity would use screen buttons. It would also render nasty workarounds like double clicks or queries useless, unless for apps that need really long to restart or really need user action (like "save game").
Hi Mort,
ReplyDeleteThank you for your comment! That is a very good point. I think the whole activity stack navigation and structure can be extremely difficult to manage the way that users understand what is going on. I don't think that in many cases users understrand the difference between activities and transitions inside an activity.
But a guideline for the navigation is clearly needed. Whenever I see new people using Android phones they seem to struggle with the back concept. I've learned to like it but I suspect that internal understanding what is going on in the system helped me a lot.
Very usefull, thank you
ReplyDeleteNice way to minimise the error of exsiting app by accident.
ReplyDeleteThis error is done by user who is getting use to android Activity and task design.
Never the less :
Don't take over the Back button unless you absolutely need to
As far as i know browser and map application takes overides the back funtionlity.
Its better get use to the system behaviour where the application is residing.
Very informative,nice article ,Thanks
ReplyDelete