I'm working on an Android app that has an activity where the user can add/modify an item. In the action bar at the top of the activity there is a save and cancel button. It behaves like a fullscreen dialog. This is similar to how Google's calendar (add event) and contacts (add/edit contact) apps work. In both the calendar and contacts app the back button saves any edits and this feels very awkward to me. On a dialog with save and cancel buttons, should the back button perform a cancel or a save?

  • 1
    Are the save/cancel buttons necessary? Or could your app be redesigned to have all changes automatically saved in real time? Aug 29, 2014 at 10:54

1 Answer 1


On developers.android.com you can find very useful information about "Navigation with Back and Up" button in Android Apps.

The standard behavior of the "Back" button is to navigate in reverse chronological order:

The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy.

On a dialog the "Back" button dismisses the window:

The Back button also supports a few behaviors not directly tied to screen-to-screen navigation:

  • Dismisses floating windows (dialogs, popups)
  • Dismisses contextual action bars, and removes the highlight from the selected items
  • Hides the onscreen keyboard (IME)

Then why do Google's Calendar (add event) and Contacts (add/edit contact) apps behave differently, using the "Back" button to perform a save?

To understand this we need to refer to Android's guidelines about Confirming and Acknowledging:

  1. Confirming is asking the user to verify that they truly want to proceed with an action they just invoked. In some cases, the confirmation is presented along with a warning or critical information related to the action that they need to consider. enter image description here
  2. Acknowledging is displaying text to let the user know that the action they just invoked has been completed. This removes uncertainty about implicit operations that the system is taking. In some cases, the acknowledgment is presented along with an option to undo the action. enter image description here

In the Google Calendar's case you mentioned - where in the dialog you have no "Cancel" or "Save" buttons - if the user navigates back from the "Add event" screen the event is automatically saved.

That could be an unexpected event, so the app uses an acknowledgment in the form of a toast ("Event created") to make that apparent.

In your case - a dialog with "Save" and "Cancel" buttons - I would definitely let the "Back" button:

  1. Dismiss the dialog. In case there are significant consequences when the user uses the "Back" button (e.g., unrecoverable data loss, credit card charges) remember to ask for confirmation.
  2. Take the users back to the previous screen.
  • In the end it comes down to confirming or acknowledging. That is what we were missing. Thank you for your thorough answer.
    – BLeB
    Sep 2, 2014 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.