I'm trying to understand what the new approach to the menu is in Honeycomb (and beyond).
If I set my version to < 11 the menu hotkey appears at the bottom and everything works as it did in pre honeycomb days.
terrific.
however, if I set my versino to 11+ then the hotkey no longer appears and now the menu button is in the top right corner... it's missing the icons, but at least the menu options still work as before.
great...
HOWEVER
if I'm running my app full screen AND it's an v11+ then my menu is simply gone.
I notice that the Kindle app offers something akin to a toggle. When you tap anywhere on the screen that isn't a button of some kind, the app flips from fullscreen mode to regular mode and the menu appears at the top.
Is this something that the App developers did manually, or is there a feature of Honeycomb that I haven't noticed that facilitates this full/non-full screen toggle for apps that have menues semi-automatically?
I dont think Honeycomb has the feature you described. It is something specific to Kindle app.
Related
Quick question, Android related..
How do I display a working "THREE VERTICAL-DOTS" floating action button, to trigger same functionality as Android menu button that worked on Kitkat (Android-4), and all previous Android versions?
Details:
I have an Android app that uses Java Native Interface. It worked fine in Kitkat (Android 4.x series), but in Android 5.x, the menu-options button (three vertical dots) no longer responds. Originally, in Kitkat (Android 4.x), the standard Android menu button brought up the applications configuration menus. Now, in Android-5, the Menu button has been replaced with a "Recent Apps" button (this was a very poor design change - probably the worst basic re-design of a working interface I have seen in 30 years... ). Is there an easy way to use a "floating action button" or something like that, to restore functionality of the standard Android "Menu" button?
On Samsung tablets, one can tweak: "Settings / Accessibility / Dexterity and interaction / Assistant menu " to "On", and then a floating-action-button appears, which then has the three vertical-dots as one of it's optional push-buttons, if invoked. Pressing that three vertical-dots button (on the Samsung FAB (floating-action-button)), triggers the old Kitkat/Android4 menu, and at least Samsung users can alter set my app config parameters.
In my app's AndroidManifest.xml file, I have minSdkVersion="8" and the targetSDKVersion="8". I have tried setting the targetSDKVersion to higher levels, which results in a non-functional floating action button, showing three vertical dots, appearing on the screen.
There must be an obvious way to fix this damage that the Android "Material Girl Design" people did to Android Kitkat(and previous Android vers.) Android Menu Button. I've detailed a work-around for my user-base at this point, and released an new app version which offers details on the work-around - at least for Samsung phone and tablet users, but an in-app button really should just appear to allow the main app configuration menu to be triggered.
I have looked at this:
http://developer.android.com/training/appbar/setting-up.html#utility
Don't want an "Action Bar". My app is a DOS-emulator, and needs all the screen space.
I have also reviewed:
Android Options Menu in Fragment
This gets closer, but rather than trial-and-error, I would like to just jump to the solution, if possible. There must be some code or a feature selection that just fixes the little action button that appears (but does not work), when I set the targetSDKVersion="12" (or higher values), in the AndroidManifest.xml file.
My app uses SDL (Simple DirectMedia Layer) vers. 1.2 and 1.3 to control and draw the screen.
I will post the answer here when I find it. I know it is possible, because Samsung is already doing this, within its "Accessibility/ Dexterity.. /Assistant Menu" feature.
This kind of behaviour appears on devices that have a hardware settings button (e.g. Samsung Galaxy S3). Apps like Hangouts or Slack use both an overflow menu and the menu that appears when pressing the hardware settings button.
Using an overflow button to show exactly the same options as the hardware settings button menu seems redundant to me. It also seems like it stands against best practices. Because such behaviour appears in many popular apps, I think this might confuse the regular user a little bit.
Is this to make the user's transition to newer versions of the Android platform easier?
Is it recommended to implement the options menu this way for such devices?
I suppose so it depends. Even an Samsung G5 or G6 have a hardware menu. Press the multi tasking window for a long time. It does the same as pressing an overflow button. This is so that the uses of older versions of Android can use there accustomed way of using the menu button. This simply provides your app with a richer User experience.
Especially value of minimum SDK version is very low it is recommended to use this to provide a richer User experience to your application. It is your wish as to how the app is supposed to workm
I have application which uses Sherlock ActionBar package.
The application uses platform-specific behavior for menu (so it's 3-dot icon in ActionBar on ICS and classic menu under HW button on pre-ICS)
I had recieved report from one user with HTC One X. It appears, that One X shows some "compatibility" bar with menu button on the bottom of screen, and there is also same button in ActionBar (where it's supposed to be).
I was not able to emulate this in AVD, and I have multiple reports that this issue is not present on Galaxy Nexus or Galaxy S (they show only the icon in ActionBar).
I have no idea where to look to resolve this or how to debug it, so any help or workaround will be appreciated.
Application is built against API14, with targetSdk="11"
You have a typo:
The android:targetSdkVersion in the manifest should be the solution - it's recommended by Google to always set it to the maximum available (currently it's 19).
Some websites do show that HTC shows the huge button on old apps, but not on new ones, as shown here, so if you think it's weird/ugly, simply set the target SDK. Also make sure it's updated in the project.properties file .
In the past I've kept my game's options behind the physical menu button for these reasons:
I don't have to have on-screen buttons in-game.
The menu action is consistent with the android user experience; it's not something unique to my app.
In some situations Android provides a soft menu button in the bottom system bar. Looking forward, though (e.g. with recent devices and targetSdkVersions), it seems there's no guaranteed way to have a menu button without implementing the new ActionBar.
If my understanding is correct, I see these options:
Use the ActionBar. Say goodbye to a big chunk of screen real-estate, especially in landscape orientation.
Implement my own on-screen menu button. I've seen this in other games, and it strikes me as inconsistent and terrible.
Target an old sdk version. I don't like this.
Is my understanding correct? Anyone have additional suggestions for my list?
relevant links:
http://developer.android.com/design/patterns/compatibility.html
Android Menu Button on 4.0 Devices
Android 3.0 statusbar & targetSdkVersion in manifest, menu button
android honeycomb menu button target
You could implement a tiny , transparent menu button of your own. Many games do that. That way you are not dependent on anyone and you don't loose any screen space.
Edit : Your menu button could then have follow your game's design.
Is my understanding correct?
Yes.
Anyone have additional suggestions for my list?
Your definition of "terrible" differs from mine. IMHO, any game that has its own stylized graphics and look (i.e., just about anything using the Canvas or OpenGL) should have implemented its own "menu" from the outset, and therefore largely would be oblivious to these changes.
I am trying to get my app to be backward compatible so i need to show the menu button
since we used the menu button in our app on previous versions.
So I was reading and it says that if your target is 11 (3.0) than you don't get the menu button but it your target is 10 they you do.
But the issue is I am using fragments so my target has to be 11.
Any thoughts.
Ordinary options menus will appear regardless of Android version. If you have:
android:targetSdkVersion="11"
then the options menu will appear in the action bar on Android 3.0+ devices. All items in the options menu will be available when clicking the "overflow" button in the upper-right corner. Your options menu will appear normally on Android 1.x and 2.x devices, even if you have android:targetSdkVersion="11" in your <uses-sdk> manifest element.
If you overrode the MENU button to have other behavior, you will need to create some other trigger for that behavior for API Level 11 and higher. Overriding the MENU button was never a good idea to begin with, and as you can see, it is even less of a good idea now. I know of no way to get a MENU button on an Android 3.0 device if you have android:targetSdkVersion="11".
One thing that worked for me in order to get older Options Menu on Tablet devices was after I used the following:
minSdkVersion="11"
targetSdkVersion="10"
I think what helps over here is that I am stating to system that app has been tested against API 10 so I get older Options menu.
And because my app is meant for tablets only, keeping minSdkVersion to 11 also prevents it to be installed on the smaller devices. I know, I might still have to see the case of installation for smaller devices having ICS.