2

what is the best practice regarding the back button currently?

A lot of apps save and restore an entire activity stack when you open them (after they've been onStop and onDestroyed), take Facebook for example, when you open it and your last place was in a photo, then pressing back doesn't close the Facebook app, it takes you back infinitely till the very first thing you did when you opened the app days ago.

This design convention is a little different than what the back button would be expected to do, I think. Where it typically is used to kill the app or stop the main view taking you back to your device's launcher screen.

Facebook was just one example of an app doing this.

Are there developer articles or an authoritative source like Google I/O discussing the utility of this feature (restoring activity stack and having back button traverse through them) vs other functionality (killing the view taking user back out of the app)? If so, please discuss and link them here. I hope this isn't considered too subjective because there is a proper use of the back button as well as an incorrect use

CQM
  • 42,592
  • 75
  • 224
  • 366
  • Nobody knows! :) Even though there are guidelines that google tries to make people follow everyone does what they think is best. Confuses everyone... – pumpkee Jan 15 '13 at 15:43

4 Answers4

2

What the Facebook app does actually is the basic default behavior of Android. Those apps don't do anything special regarding that behavior. The Activity stack is saved by default.

One of the more cited blogs regarding it is CommonsWare's BACK means Back. Basically, the functionality of the "BACK" button means it should to take you to the previous page that you just were at. In Android, this is very often the last Activity you just pushed. If the user wants to leave the app, then he or she can press the "HOME" button and that will always push the Activity stack and take the user to the homescreen.

What this means is, the functionality of the BACK button is entirely dependent on the app in question, but the concept is to reverse the action that the user just did. If you are in a game, you go to a sub menu, the BACK button should take you to the top menu. If you are in a browser, the BACK button may take you to the last webpage you were viewing. If you are in a browser and you are in the top page, the user may expect the BACK button to close the app since the last action the user did prior to opening the browser is open the app. If the user starts a download, the BACK button may be to cancel it.

One functionality improvement that Facebook and others like is may consider is to wipe the stack after x number of days since the user may not remember exactly what they did since being interrupted from the last use. The use case for this is very small though.

Overall, this is why people always stress usability testing. You have to figure out what 99% of the people of the app expected when they press the back button.

Sababado
  • 2,524
  • 5
  • 33
  • 51
DeeV
  • 35,865
  • 9
  • 108
  • 95
  • +1 for beating me to the punch (and having another source for Back behavior than the Android Dev site). – Sababado Jan 15 '13 at 15:56
2

You can find on the Android Developer site that you should not change the expected behavior of the back button. Let the OS handle the back button.

App does not redefine the expected function of a system icon (such as the Back button).

That quote is pulled from their Core App Quality page.

You should consider using Up Navigation. You can read more about designing for it here:

Lastly, here is a tutorial on how to implement various types of navigation (lateral, ancestral [up], temporal, descendant). check here

swiftBoy
  • 35,607
  • 26
  • 136
  • 135
Sababado
  • 2,524
  • 5
  • 33
  • 51
  • 1
    What's funny is how often even Google ignores those guidelines. – DeeV Jan 15 '13 at 15:56
  • 1
    Even with up navigation though, there may be use cases where overriding the functionality of the back button is necessary. Chrome Mobile for example overrides the back button when viewing webpages because if they didn't the app would close when the user actually expects to go back a page. – DeeV Jan 15 '13 at 15:57
  • And in that case it is perfectly valid to override. What my answer should be saying (more like yours) Is that the back button should take the user back to an expected place. If the default behavior doesn't do that then override and make sure it does! My purposes usually don't require much (if any) change. – Sababado Jan 15 '13 at 16:00
0

From my personal experience you can close most, which are using back pressing to go to a previous screen, with a long click on the back button.
The best example is the browser app, whether its the native one or a third-party browser

Nickolaus
  • 4,785
  • 4
  • 38
  • 60
0

I think that behavior depends on application logic. By default it is desired to move on previous screen (activity in back stack, or fragment if it was saved to the fragment's back stack). Actually there is no any silver bullet for this case. Just use "back-pressed implementation" what ever you want. My point is that on back pressed, application must be shown in previous logical state.

bvz
  • 76
  • 1
  • 3