Android and Honeycomb – how to have a menu icon with SDK 13 without having an “action bar”

I would like to maximize use of the screen for a Honeycomb app. Since the bottom of the screen is already stuck with “always-on” items, I’d like to add a menu button down there in that space rather than sacrificing more screen space putting an “action bar” across the top. How can I accomplish this without downgrading to API 10 or less? (As much as I don’t need an action bar using up more space, I also don’t need a resize button that does my app no good at all and can’t be disabled except by going to a very recent API version.)

Surely one can make some kind of effective use of hundreds of pixels that currently sit dark and wasted at the bottom of a Honeycomb screen, between the back/home/thingy icons and that ever-present clock? It’ll be a ridiculous waste of yet more space to create an action bar for the purpose of having a single settings button tucked in the corner.

  • Maven and Android Facebook SDK apklib
  • How to Create Android Tabbed style with Page Swipe View
  • How to add a MOOV atom in a mp4 video file
  • how can i determine internet speed in my android application
  • Change the background color of CardView programmatically
  • App crashes on start caused by NPE in android.content.Context.getString
  • Edit: I see others have asked somewhat similar questions but in general, how can we make use of the otherwise wasted space at the bottom by adding buttons or what have you down there? If I have to create my own menu button from scratch I will, but I get the impression that this space is unusable (which would be pretty absurd if true).

    Edit 2: Apparently it’s true: The “system bar” is indeed inviolable and mostly exists to present unoccupied space to the user (particularly in landscape mode). Looks like I may have to revert back to an older SDK – as long as nobody uses the zoom icon it should be fine.

    Edit 3: I’m pleased to report that with API 10 the menu button is back AND the useless zoom button is GONE (using android:xlargeScreens=”true” in the supports-screens appears to work in this API!)

    Related posts:

    Unable to access jarfile lib\archquery.jar
    Status says Draft in Prod
    Android Gradle's dependency cache may be corrupt and gradle build not working
    No static method zzUr() in Firebase when I try to use Analytics with Notifications
    Can you set graphical layout preview-only text on a TextView?
    BaseAdapter or ArrayAdaptor - Android
  • backup full sms/mms contents via adb
  • Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 27830 (ple.myfragexample) — only on Android 4.1.2
  • Usage of ?android:attr/ in backwards compatible apps
  • what is the difference between view and activity in android development?
  • How to resolve “Waiting for Debugger” message?
  • Adding Fragments Dynamically
  • One Solution collect form web for “Android and Honeycomb – how to have a menu icon with SDK 13 without having an “action bar””

    How can I accomplish this without downgrading to API 10 or less?

    You can’t.

    Surely one can make some kind of effective use of hundreds of pixels that currently sit dark and wasted at the bottom of a Honeycomb screen, between the back/home/thingy icons and that ever-present clock?

    Only if you are modifying the operating system. You can put a Notification down there, in the lower right, but that is designed for alerts, not menus.

    It’ll be a ridiculous waste of yet more space to create an action bar for the purpose of having a single settings button tucked in the corner.

    Then use a button to bring up your settings. Or some gesture, or whatever.

    how can we make use of the otherwise wasted space at the bottom by adding buttons or what have you down there?

    You don’t. That is for the OS to use. Just because there is whitespace does not mean that space is “wasted” — having an overly-complicated control area is not necessarily a good thing, as those with UX and design experience will point out.

    The whole thing is kinda ridiculous

    If you mean your attitude, yes, it is “kinda ridiculous”.

    Android developers have a well-deserved reputation for not adhering to any sort of conventions or standards, resulting in applications that don’t look and work like one another. Partly, this is Android philosophy — Google doesn’t enforce human interface guidelines the way Apple does. However, Google does provide frameworks to steer developers in a direction that promotes consistency between apps. Some of these frameworks have existed for quite some time (e.g., PreferenceScreen); others are new (action bar).

    You do not have to use the action bar. Lots of applications won’t, such as games. If you are not using the action bar, though, it is up to you to provide the entire user experience, and to do so in a way that users will find intuitive even though you are eschewing platform frameworks.

    Using an old target API level will increasingly confuse users who are used to applications that are up to date. Right now, there are certainly plenty of applications that are not targeting API Level 11 or higher and therefore have the system bar MENU button. That will change over the next year. Eventually, a preponderance of users will have no idea how to access your menu, because they will not notice this funny-looking icon that appears in the system bar or not know what it does. Some of these users will wonder why you don’t have a menu in the upper-right corner like most of their other applications.

    If you don’t want an action bar, you can roll your own upper-right-corner menu, using an ImageButton and PopupMenu, for example. That, at least, will keep you consistent with other apps that do use an action bar, putting the menu where users will expect to see it. Or do something else more integrated with the rest of your UI as a menu affordance. Don’t rely on the legacy-support MENU button in the system bar for long — while it should be supported indefinitely, users will be adapting faster than perhaps you are.

    Android Babe is a Google Android Fan, All about Android Phones, Android Wear, Android Dev and Android Games Apps and so on.