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.
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'm working on an existing Android application for medical purposes.
The back button and home button should be disabled.
With the existing code, the back button is disabled.
For disabling the home button they used onAttachedWindow with LayoutParams TYPE KEYGUARD,
but this security hole is fixed since 4.0.
I tried a lot of similar questions, but none worked out for me.
What is the way to get this done these days?
Also, hiding the status bar on tablet (where the home & back button live) would do the trick,
so any suggestions there are equally helpful!
Update: also, free third party apps that do the hiding trick are okay!
This sounds like a kiosk or dedicated use kinda thing, yes? You want your app to "own" the tablet and prevent other usage? I did this for an app whose sole purpose was to act as a remote control for a custom device. Basically I created two apps, a "custom launcher" app and the app that did the remote control. It's probably possible to integrate the two, but I wanted to support both dedicated and non-dedicated use. Note that I gave the launcher app a password-protected way to access settings so that I could recover the tablet at any time.
You can find a number of tutorials that will guide you through creating a custom launcher, just strip out all the stuff that makes it a generic launcher and replace it with an image button or similar that launches the actual app, or replace the launcher activity with your main app activity. Warning: I never figured out how to remove the launcher except by going into the settings.
As for hiding the system bar (notifications and status icons at the top of the screen), you'll want to use a full-screen theme like #android:style/Theme.NoTitleBar.Fullscreen.
As for hiding the home button I took this approach:
View main_layout = this.findViewById(android.R.id.content).getRootView();
main_layout.setSystemUiVisibility(View.STATUS_BAR_HIDDEN);
Unfortunately the STATUS_BAR_HIDDEN flag is deprecated now, but I think some of the other options would have the same effect. Regardless, the best you can achieve within Android's intended use is to temporarily hide the navigation buttons (home and back). A tap on the screen will bring them back.
I am porting an iPhone app to Android, and I can't find the Android equivalent of the UINavigationItem. These are buttons with a triangular side indicating movement between different screens. For an example of what I'm trying to accomplish, this is from the BeyondPod app:
http://mobiputing.wpengine.netdna-cdn.com/wp-content/uploads/2011/05/beyondpod.jpg
The buttons labeled "Categories" and Podcasts" are what I'd like to duplicate.
Android has a hardware back button. Forward is typically accomplished by some widget, such as a button or link, somewhere in the Activity.
I looked at the screenshot you posted again and noticed that your left and right buttons are to switch between categories and not to go to an earlier screen.(Im not sure if im right)
If that's the case using the left and right buttons are okay as they are to switch between categories and not the previous screen. But keeping a left button just to go to the previous screen isn't really necessary. Here we need to think in terms of an android user. They are hardwired to press the hardware back button to go to a previous screen. There are many examples of apps that have a bit of changes in their android and iPhone version. Eg Evernote.
It uses tabs on the iPhone but in android they sort of created a dashboard in combination with an action bar.
So main thing to consider when porting an iphone app is to make enough changes so that an android user will feel like it has a navigation they are used to. Most apps that look exactly the same as iphone apps are created with these cross mobile development tools(titanium, sencha touch).
Please give me feed back whether it's good practice to have a back button in activity, or is it just nonsense? Maybe some android phones don't have back/return key? Or do all models have them?
All android phones will have the back key. Putting a back button is, IMO, ugly and unnecessary; you better use your space with useful stuff. Sometimes your boss will just obligate you to put a Back button, usually because (sadly) most of the android sketchs are based on iPhone's ones... so the only reason why I'd put a back button is to not get fired (well, sometimes it's much better getting fired than becoming a poor programmer).
Piling on. I recently had a debate about this where we talked about design metaphors for android, iPhone, and windows mobile. The bottom line where we agreed is that you should follow the design metaphors for the device you are developing on. For android, the design should not include a back button because users are used to the physical back button. If one is required, the physical button should work as well.
I put a Back menu item in the option menu. The option menu in my apps seem to already contains other navigation-like menu items, so its seems reasonable to have a Back menu item in there. Having the explicitly labelled Back menu item there seems more newbie-friendly and the redundancy seems harmless there unless the option menu has a ton of menu items already.
OTOH, remembering that there is an option menu and remembering how to access it can be a challenge for some Android newbies. Yes Dad - I mean you. :-)
Similarly, on an Add/Edit screen, I provide Save and Cancel buttons, even though the Back button could be (and probably often will be) used to Cancel button. Again, having an explicitly labelled Cancel button seems more newbie-friendly and harmless. (What were you going to do with that empty space beside the Save button anyway?)
All android phones that want to have android market access need to have a menu, back and home button. those are the rules from El Goog. Some models may not have these but I bet that is a small number of devices.
I'm not sure if anything will change with honeycomb, seeing as Motorola Xoom has none of these buttons.
If you have an app that needs the space to exclude a "back" functionality, such as an "undo" functionality in a drawing app where you want to show the whole screen, then it's a great shortcut, but you better have a button as well.