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<javascript:>> > wrote: > > On Fri, Nov 2, 2012 at 2:10 AM, Keith Wiley <kbw...@gmail.com<javascript:>> > 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
