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.

Productive

Well, I'm not quite sure, but I have a tablet, and the bar at the bottom (how's that called, I guess not Action Bar, as this is the one on the top?) does not vanish (it's the one with the home, back, ... button; actually, it may not vanish, that's imposed by the OS). A lot of applications make an options button appear there! Couldn't you do the same? Haven't used it and thus don't know how to make it though... EDIT: Reading up... that's what you mean by going back to using TargetSDK < 11? – Doable

Assuming you are talking about the Action bar, then yes. – Productive

Can you tell wat is the targetSdkVersion you are using for uses-sdk in your app ? – Camphene

Not 100% sure (not at my dev machine right now), but it's either 14 or 15. I like to keep the target SDK relatively current, although I still support Android 1.5. – Productive

Answer 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.

Camphene

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. :-/ – Productive

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. – Camphene

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. – Productive

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

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. – Camphene

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. – Productive

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. – Camphene

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. – Productive

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...:) – Camphene

Answer 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.

Nader

"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. – Productive

"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. – Productive

@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? – Nader

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. – Productive

@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. – Nader

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. – Productive

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. – Vercelli

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). – Vercelli

Answer 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

Productive

Answer 4

Michael, I was in exactly the same situation and solved it by implementing my option menu using a custom dialog. It looks better on ICS than the legacy option menu at the bottom. It is configured like this

minSdkVersion = 8 targetSdkVersion = 14 SDK build version 8 (in eclipse settings.could set to 14 but I like the type safety it provides)

Users with API < 10 use the hard menu button and see the standard option menu. Users with API >= 10 see a three dot icon (overflow menu) in the app and when click get my custom dialog menu. They also see the new ICS look in Settings, etc.

It does not seem that the Menu button is coming back and I wanted to break the legacy barrier even though only <1% of my users use ICS.

Vercelli

Answer 5

Responding to that recent blog post, they seem to want developers to start using Action Bars over Menus, but this becomes a pain if wanting to support API => 3.0 and API < 3.0. So either create a custom Action Bar that is compatible with API < 3.0 (you can find examples in the SDK), or... I was experimenting with this last week:

I also had an issue where the menu button did not appear on my ICS tablet, I believe I had targetSdk set to 11 at the time as I wanted to implement an ActionBar. Then I set minSdk to 3, and targetSdk to 4. Both the ActionBar and the menu overflow button appeared. So this is the workaround right now (at least for the project I'm working on).

Timbering

Answer 6

I added a special logic for 3.x releases. Only for these releases I use the action bar.

            if (Build.VERSION.SDK_INT == Build.VERSION_CODES.HONEYCOMB
             || Build.VERSION.SDK_INT == Build.VERSION_CODES.HONEYCOMB_MR1
             || Build.VERSION.SDK_INT == Build.VERSION_CODES.HONEYCOMB_MR2) {
                requestWindowFeature(Window.FEATURE_ACTION_BAR);        
            }
            else{
//              hide the status bar, do not use action bar         
                requestWindowFeature(Window.FEATURE_NO_TITLE);    
                getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN);               
            }

For all other releases I display my own menu button and run my game in fullscreen mode. When pressing my menu button, I use the following code line, where "act" is the current activity.

act.openOptionsMenu();

As part of your menu xml, make sure to have a line like this to set "showAsAction"

showAsAction="ifRoom"

Postscript