For all your secondary UI screens, it should be possible to add an on-screen back button so I'd do it. As for in-game, that's for you to decide - I haven't seen your game. If there's a place on your in-game screen where a pause button wouldn't get in the way, I'd add it. Once in the paused view, again you can probably draw any buttons you need to enable navigation without relying on the Back button.
As for the spirit of intended Android user experience, I don't think there's any. Whatever "affordances" you draw to the screen, your users will use. What's right or wrong is between you and your users. The "correct" or "intended" use of the Back button was described by Google somewhere - I don't have a link handy but searching for Android Back button should find it. I think you are more or less compliant according to your description. On Fri, Nov 2, 2012 at 5:02 PM, Keith Wiley <kbwi...@gmail.com> wrote: > Thanks for coming back to my original question. So, perhaps we can all > consider my situation from a higher level and discuss the possible design > options we might choose from (and which options are most in the spirit of > intended Android user experience). Although I have a few Android apps, the > one I'm concerned with at the moment is a game and the back button is used > to move between the various "screens". So, when the game launches you get > an on-screen menu of options (settings, scoreboard, play, credits). Tapping > those takes you to a corresponding screen while tapping the back button > takes you from those secondary screens back to the main menu (or from the > main menu it exits the app). Likewise, while playing, the back button > doesn't immediately exit "play" mode back to the main menu but rather first > pauses the game. From the paused view, a second back button tap cancels > play and returns to the main menu...while tapping the paused screen > (anywhere) resumes play. > > That's pretty much it...and my question is whether I need to offer a > nonback-button method for these various actions? Should each of the > secondary screens have an on-screen "return to main menu" button? Should > the main menu have an explicit "quit" option? Should in-game-play not rely > on the back button to either pause the game or cancel and return to the main > menu? These are the things I'm thinking about with as far as this > discussion is concerned. > > Thanks. > > On Friday, November 2, 2012 6:22:50 AM UTC-7, latimerius wrote: >> >> On Fri, Nov 2, 2012 at 1:02 PM, Mark Murphy <mmu...@commonsware.com> >> wrote: >> > On Fri, Nov 2, 2012 at 2:10 AM, Keith Wiley <kbw...@gmail.com> wrote: >> >> All right. I brought this up a few weeks ago on this list and some of >> >> the >> >> advice on the topic was to avoid menus entirely and replace them with >> >> in-app >> >> soft-menus from now on...despite the action bar. I guess that advice >> >> was >> >> incorrect. >> > >> > There are developers who do not want to use the action bar, such as >> > game developers who find that an always-present action bar is a >> > distraction or clashes with their game-focused UI. A subset of those >> > developers are clinging desperately to the old options menu behavior >> > (e.g., setting android:targetSdkVersion to be under 11) -- the right >> > answer for these game developers is to add "in-app soft menus" that >> > blend in with the game UI. >> >> The right answer would have been for Google to leave the button alone >> - but we've talked about that already, the button was universally >> useful, and there's not always a UI to "blend in" anyway. >> >> Back on topic, my lesson for my remaining days on Android from the >> Menu button fiasco and other breakages caused by previously guaranteed >> stuff being pulled at whim from under people using them would be - >> interact as little as possible with the platform. Don't rely on stuff >> on being there cause it likely won't, don't rely on APIs cause they >> will be deprecated or changed. >> >> As far as the Back button specifically, one would think that should be >> safe to rely on. Based on experience though, my advice would be, >> think hard about what you need it for and what your alternatives are. >> If you find any half-decent one, consider using it. You might be glad >> you did once next version of the platform is out. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
