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.

Was it helpful?

Solution

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.

OTHER TIPS

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.

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

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.

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

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"
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top