Handling the missing MENU button in new versions of Android (3.x and up)

Question

I'm a fan of the menu button as used in Android <3.0, as it was very useful for my game apps - it allowed me to take important but gameplay irrelevant functionality (saving game, reference info links) and place it somewhere where it did not clutter up the main game interface, but was still easily accessible (the options menu).

This use of keys became a problem with 3.0, because it removed the MENU button and substituted it with the Action Bar. The Action bar is really not suitable for a game which likes to run full-screen, so that was a real pain. No action bar - no access to the options menu. However, I could sort of ignore it for a while, since I didn't have that many users on tablets and lacked the time to test this.

However, ICS makes this a serious issue, since the MENU button is obviously not coming back. Now I don't only have to deal with this problems on tablets, but on phones as well.

My initial solution to this problem has been to simply place a soft button in my GUI to replace the hard MENU button

this.openOptionsMenu();

And everything is back to working perfectly in ICS.

However, this does not work on Honeycomb. Calling openOptionsMenu does absolutely nothing if you do not have the ActionBar visible.

Any thoughts on how to deal with this?

• I suppose I could always go back to using TargetSDK < 11 (thereby forcing the ActionBar to appear on tablets), but as far as I can see this is merely pushing the problem into the future, which I would prefer not to do.

• Drop the Options Menu entirely, and go over to only using Context Menus? [Clarification: By this I mean that instead of opening an options menu - I only use context menus since - at least for now - these work on all devices].

Interested in hearing what others who have had similar issues with the whole Options Menu/ActionBar mess decided to do.

Solution 1

Let me share another scenario where Menu Button becomes critical even though it is not a game.

I have app implement its own tool bars which behave to some extent like ActionBar. Well I did that coz my app was released with 1.5 sdk. At that time there is no such concept. And to accomodate for my toolbars i hide the default title bar. But some of the actions are done through Menu functionality.

Now since in Galaxy Nexus there is no Menu button if you are not using ActionBar and that is hurting me because my app still supports 1.5.

Well there are various work arounds, but none is easy.

That said, the only work around I come up with is to give user all options on my toolbar, so there is no need for Menu at all. I can do this because i only have two actions which are not part of the toolbar.

In your situation, context menu on a button is not a bad soln in a game as game will have only one context in which it is running as compared to having context menu on list items where every item is a different context.

BTW if openOptionsMenu works on ICS and you can ditch HoneyComb after a while (even now the userbase is too low) then try giving both menus based on the version.

EDIT: Well there is another way also to get the MENU s/w button in the below navigation bar. Just set the targetSdkVersion to less than 11. For more details pls read the whole soln.

Solution 2

However, ICS makes this a serious issue, since the MENU button is obviously not coming back.

More accurately, it is up to device manufacturers whether to have off-screen buttons or not for things like MENU. Quoting the Compatibility Definition Document for Android 4.0:

The Home, Menu and Back functions are essential to the Android navigation paradigm. Device implementations MUST make these functions available to the user at all times when running applications. These functions MAY be implemented via dedicated physical buttons (such as mechanical or capacitive touch buttons), or MAY be implemented using dedicated software keys, gestures, touch panel, etc.

So, you cannot count on there being an off-screen MENU button, though there may well be one.

Any thoughts on how to deal with this?

Write your own "menu" as part of your game UI. I would not expect a game that thinks it needs the full screen to use the options menu -- in fact, I can't remember ever seeing a game that did that (though, admittedly, I am not a big-time game player). All the games that I have played do nothing on a MENU press. Rather, anything that might be considered a "menu" is implemented directly in the game UI (e.g., a button that leads to a screen, formatted in the game UI's look-and-feel, that offers choices for things to do).

Drop the Options Menu entirely, and go over to only using Context Menus?

That would be awful, as users will not know where to long-press to bring up the menu.

Solution 3

And just to put the last spike in the proverbial coffin of the menu button, Google weighs in with a final goodbye:

http://android-developers.blogspot.com/2012/01/say-goodbye-to-menu-button.html

Comments

[Michael A.]

"Device implementations MUST make these functions available to the user at all times when running applications." - This makes absolutely no sense at all, given that Google's own Galaxy Nexus does NOT do this at all.

[Michael A.]

"That would be awful, as users will not know where to long-press to bring up the menu." They would know to press on the button which says Menu, which would pop up a Context Menu, instead of - as I do it now - an Options menu that only turns up on non 3.x devices.

[CommonsWare]

@MichaelA: I have a Galaxy Nexus, and I don't recall situations where the MENU button is not visible. Care to elaborate? "press on the button which says Menu, which would pop up a Context Menu" -- how about, instead, when they press the button which says "Menu", you display an AlertDialog with your menu choices? Or a PopupWindow? Or other things where the UX is more under your control?

[Michael A.]

Hmm... what do you refer to as the Menu button? On my phone, I have always have access to precisely three buttons (from left to right): Back, Home, and the Recent Apps button. If it is the latter that you (and the CDD document) refer to as the Menu button, then we're talking a bit at cross-purposes: I am referring to the original Menu button paradigm (as used in Android up to at least version 2.3), which is clearly not the same GUI paradigm as in ICS. That is also the essence of the problem of course - how best to handle this GUI paradigm changing radically across OS versions.

[CommonsWare]

@MichaelA.: Sorry -- the action bar menu button/trigger/whatever you want to call it appears whenever it is needed, except in apps that don't use action bars. I wasn't thinking straight with my previous comment -- my apologies.

[Michael A.]

Understood. Wrt to using an AlertDialog or PopupWindow in place of a ContextMenu, these are certainly valid options if I follow the second option of dropping the options menu entirely. Annoying, because I rather liked the way the option menu works in Android, but certainly a valid alternative.

[Michael A.]

Giving both versions might certainly be worthwhile, though I am uncertain as to how (and whether) openOptionsMenu works for tablets in ICS. I'm currently unable to test this, since ICS + tablet size emulators are not friends on my development machine. :-/

[havexz]

Tablet based development on emulator sucks big time...even running simple app is problem n u have a game....;-). Now to test openOptionsMenu on ICS tablet, just try creating a small app just for testing Menu in emulator. After an hour or so..;), you ll come to know. And if it works, then you can switch between the two menus based on the version. You might consider creating helping handler for menus which can be re-used for both cases.

[Michael A.]

I could do that if the emulator would even start up an instance with ICS at tablet sizes, which - so far - it has completely failed to do. Apparently something to do with RAM usage, but so far I have not had time to spend on trying to get this to work.

[user1076637]

To add to CommonsWare's post, the CDD actually prohibit manufacturer from having a MENU button in the navigation bar at the bottom of the screen.

[user1076637]

If the targetSdkVersion < 10 (or if targetSdkVersion is not specified and minSdkVersion < 10) then Galaxy Nexus will show in the navigation area a fourth menu button in the form of three dots on the right hand. This is dictated by the Android CDD 4.0 for backward compatibility with legacy apps. This will also cause the app to have the legacy look and feel (e.g. in the Setting page).

[Michael A.]

Re:Edit. That's my option 1 above, but then you also get the ActionBar, which I definitely don't want.

[havexz]

Well action bar and navigation bar are two things. Action bar generally comes at the top and navigation bar at bottom as shown here link. So which one are you trying to get rid off? BTW in your case specifically you dont depend upon the Holo theme n all you have a game.

[Michael A.]

As it says in the text - the issue is the replacement of the MENU with the ActionBar. But I overlooked the part about the MENU appearing in the navigation bar. Very interesting, thanks - not noticed this before, and it certainly works for ICS (will have to check Honeycomb). That would certainly help avoid the problem for a time, though I wonder how long we can rely on the Android OS to continue supporting this functionality.

[havexz]

Well it should be as long as most of the devices migrate to 4.0. So you should be safe as by the time support is not there, most of the audience will be moved on to the new platform and you dont have to support < 4.0. I think api/patterns in 4.0 stay longer than the predecessors. They are more mature.

[Michael A.]

One can certainly hope so, though I have to say that I'm not encouraged by Google's track record so far on it so far. Still, it's good advice for the general case - if I could upvote it more than once, I'd have done so.

[havexz]

tx for the virtual vote..well the reason i think it is more stable as google is now addressing issues like enforcing guidelines on manufacturers who do skinning, standardization of Themes, more mature patters like Loaders etc. Nyways good luck coding...:)