This question already has answers here:
Are the 4 Android buttons standard? Ex. back button, menu button
(4 answers)
Closed 5 years ago.
Do all Android devices have "option" and "back" buttons? Or should my design have "back" and "option" buttons for making it more versatile?
The Android 4.1 CDD section 7.2.3 contains information on this:
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. Android 4.1
supports both implementations.
The back button is going to bring back the previous screen on the stack regardless, much like the home button will pretty much always take you to the home screen. As for the option button, it's generally good practice to implement something for it if there are some settings to be changed or something like that, but that really depends on your application. Many apps don't utilize it and do just fine.
No, not every device comes with a back button. Amazon Fire phone do not have a back key.
On Android platform it is always better to be cautious as device manufacturer always do customization.
Related
Since API 14, right mouse clicks should have been easy to detect via getButtonState().
However, when I right-click, then it acts as the Back button. The middle button acts like the Home button. (Android 4.4, Galaxy Note 3, mouse via USB adapter)
My question:
Does the (smartphone/tablet) device manufactor decide what to do with right button?
Or do different Android versions act differently?
What Android versions / devices support right/middle mouse button?
The default behavior for the middle and right button are as you described for most devices, as is defined by the OS.
Starting at API level 14, there is a way to handle the second and third button from the MotionEvent of a GenericMotionListener.
I suggest you have a look at the answers to this similar question for more details.
The answer is yes, the manufacturer controls how the secondary/tertiary buttons react, because it is compiled with the kernel. Generically the right click acts as a back button, however, on a couple of my non-mainstream tablets it uses one of the mouse's side buttons to go back. Usually the wheel button goes home, all tested on my collection of devices. If you want to know how to override the default behavior, whether it be for an app or as a mod, check out my answer here: Change Mouse Right-click behavior
Hope this clears up everything
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).
My app has code to go full-screen where sensible to do so -- it's sensible on most Android 1 and 2 devices, but under Android 3 for example going full-screen loses the app menu button, and at the moment I don't implement my own menu button so users can't (or at least can't easily) get to the app's menu.
At the moment I test for Android version < 3, and go full-screen if that's the case, but I have users with Android 2 tablets (Viewsonic view pad 10s for example) where this isn't sensible (the Viewsonic user tells me she has to hold down the back button to get app's menu to appear).
Is there a better way of testing whether going full-screen will lose the menu button? Or going full screen only if it's sensible to do so?
Thanks for any help you can give. Let me know if you need more info or if the above isn't clear.
Mark
Is there a better way of testing whether going full-screen will lose the menu button?
No. The Viewsonic device in question does not qualify for the Android Market, AFAIK, and all bets are off in terms of compatibility for devices that fail to meet the requirements for the Market.
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.
Are there any requirements/guidelines for an Android device? like numbers of buttons or minimum buttons required.
Also are there any android devices which do not have the menu and back buttons?
( I am aware that no menu/back buttons will kill most of the apps in terms of usability , I just wanted to know more on the topic :-) )
Are there any requirements/guidelines
for an Android device? like numbers of
buttons or minimum buttons required.
Yes. These are documented in the Compatibility Definition Document.
Also are there any android devices
which do not have the menu and back
buttons?
That depends on how you define "buttons" and "android devices". Quoting from the CDD (see above link):
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, regardless of
application state. These functions
SHOULD be implemented via dedicated
buttons. They MAY be implemented using
software, gestures, touch panel, etc.,
but if so they MUST be always
accessible and not obscure or
interfere with the available
application display area.
There are devices that do not have dedicated off-screen buttons (whether physical or touch-sensitive off-screen spots). The ARCHOS 5 Android tablet is one -- it has the HOME and BACK buttons in an expanded title bar. However, it is unclear if Google considered them to have met the CDD, since the ARCHOS does not have the Android Market. Devices lacking the Market may not meet the CDD.
So, it is entirely possible to create devices that do not meet the CDD, but at that point Android is mostly just another embedded OS, IMHO.
I would recommend this links:
Twitter for Android: A closer look at Android’s evolving UI patterns
Android UI design patterns
User Interface Guidelines