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?
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:
- 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.
- 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.
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:
- 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.
- Take the users back to the previous screen.