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.
Related
I want to know if there's some way to maintain an Android activity always on top regardless of any other apps present in the phone device that might put on top on it, except for home screen via home button, which cannot be helped.
I've checked that if a whatsapp popup displays over my activity, that activity starts showing a strange behavior.
Maybe this can be controlled by some events, but I think it's much easier to avoid anything that might put on top of app, so no strange behavior appears.
Is there any way to do that?
It depends on the level of control that you have over the device. If your app is going to be publicly available you cannot (and should not) do much to prevent other components from coming on top of the stack.
Apart from that, one thing you can do is check for UI changes through this: https://developer.android.com/reference/android/view/View.OnSystemUiVisibilityChangeListener or/and activity lifecycle events (like onPause) and prevent whatever this "strange behaviour" is.
The inverse way to deal with this is to prevent any app from having the "Draw Over Other Apps" permission, but as I said it depends on the environment of your deployment.
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.
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.
I frequently get designs for android apps featuring iphone-like functionality. In this case it has to do with a back button integrated in the layout as part of the header (on the left side).
Android already comes with a back button - although I have seen some technophobes completely ignore the back button and complain about the flow of an app. ("why is their no cancel button, 1 star, uninstall" push back)
First of all, recreating iOS elements is tedious and counterproductive, but in this case do android users expect a back button in the header at this point? Would a "back" button subtract from a UX at all?
For instance, Android users expect to long-click items in a listview to see what happens - often for options or to delete. Or at least the assumption can be made.
But for a back button in the layout, do Android users get enough apps with iOS-style back buttons to simply expect it?
Insight appreciated
Implementing a back button taking up screen real estate really has no point or benefit for an Android user. The only thing it does is cramp the UI for no real reason since the back button already exists.
Android users don't expect a software back button, since it's simply not the Android way of going back and not many apps have it.. hardly any apps have it actually.
Not only is a software back button completely unnecessary but it could even irritate the user since it could be seen as trying to "iPhone-ify" the app. Not popular at all for some Android users ;)
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.