I was wondering, since on Android one closes a screen by pressing the "return" round-arrow, is it still OK to have a cancel button on each screen or does it look rather clumpsy and confuse because the user might think it does something different than the return button.
Is there a good rule or even guideline for this ?
Many thanks
On each screen it's from my point of view useless, you are suppose to go to your previous screen (previous Activity since one screen is one Activity... usually) with the back button. For dismissing an AlertDialog, keyboard, ProgressDialog : back button is still ok. Where a cancel button can be added is when the user is processing a complex chain of action and in the middle of it he thinks : screw this... here a cancel button which bring him back to your home Activity is welcome.
Downloading lots of app and look at their application's flow (navigation between screens) will teach you what's intuitive, natural and what's not.
Personal thoughts.
Related
Several SO questions cover the topic of how to wire up a WebView to have the "back" button traverse browser history. An Android developer doc page answers that question well. We have an app that uses the recommended method:
#Override
public void onBackPressed() {
if (mWebView.canGoBack()) {
mWebView.goBack();
return;
}
// Otherwise defer to system default behavior.
super.onBackPressed();
}
And that works fine. But the doc page also cautions,
Be careful when using this mechanism with highly dynamic web pages
that can grow a large history. Pages that generate an extensive
history, such as those that make frequent changes to the document
hash, may make it tedious for users to get out of your activity.
Our client has confirmed that this is a problem: When following over a dozen successive links within a WebView, getting back out to the previous (parent) activity is tedious, especially because you have to wait between taps of the back button for the WebView to refresh.
Unfortunately the developer doc page doesn't suggest a workaround for this situation.
One possibility is to use the "up" button in the toolbar/appBar/actionBar to exit the WebView.
My concern with that is that the "up" button normally looks like a backward-pointing arrow or chevron, very similar to the "back" button (identical to the "back" arrow in some browsers). So then we'd have an "up" button in the toolbar and the Android "back" button, looking very similar and doing something different. That would seem confusing to the user.
Is there a better way to provide "exit" navigation from a WebView besides the "back" button?
(Not a duplicate: using phones back button to exit from webview asks how to get the "back" button to exit the WebView only after there's no more history to traverse back over.)
One possibility is to use the "up" button in the toolbar/appBar/actionBar to exit the WebView.
What else would you have in the toolbar? What would it do?
Usually every screen that is not the root has a home (up) button in the toolbar that closes the screen again. That's how most Android apps work.
My concern with that is that the "up" button normally looks like a backward-pointing arrow or chevron, very similar in concept to the "back" button (identical to the "back" arrow in some browsers). So then we'd have an "up" button in the toolbar and the Android "back" button, looking very similar and doing something different. Is that a recipe for confusing the user?
That's Android and if you do it that way you follow the platform guidelines. As mentioned above, that arrow in the toolbar is in almost every app and navigates away from the current screen, whether its called home, back, up, or something else.
But you're right, back and up gets confused a lot.
An alternative is to opt for the close style. Replace the default arrow by an ✖ and its action closes the current screen should be evident.
While I prefer the Up arrow, the ✖ is a valid alternative, especially if you pop some WebView for additional content and want a strong indicator on how to close it again.
Is there a better way to provide "exit" navigation from a WebView besides the "back" button?
Nope. You could try asking on UX Stack Exchange, but you already have 2 platform standards—namely back and up—that can and should be used for navigation.
Anything else that you might come up with would be "new" and unique to your app, but of course you could just add a "Close Screen" button.
tl;dr If you don't like the Up Arrow in your toolbar use an ✖ as a close icon.
I've got an app with two screens, we can call them List and Details.
If an user is at Details and presses Home to minimize the app and then switches back I want to stay in the view and just restore, but if he presses Back I want to go back to List, I figure I can save a "Done"-button this way. But...what's the proper way to do this?
Currently I've overriden onPause and onSaveInstance but it seems they're both called in both cases.
I'm thinking about overriding onKeyDown instead, like he did; How to control Activity flow - Back button versus Home button, but that doesn't seem like a "nice" way to do it so I thought I'd check if anybody else has another idea.
Make two activities, for list and for details. When you will press the back key in the details activity it will finish and will show up the list activity.
I've googled this and googled this. Perhaps my terminology is wrong. I have a normal activity. I have a button called go to background mode. When the user presses this button, I want the activity to just go into the background (like it would normally do on the back button)
However, I want to prompt the user with an alert dialog: "Do you wish to enter background mode?"
If the user hits "Yes" THEN go to background, if no, then stay on current screen/activity.
For this, I am overriding ONBackPressed(). If the user hits, "YES", how to I put my activity into the background?
Thanks!
If you want to close just that activity, you can just use finish(). If you want to move the entire task to the background, you use moveTaskToBack(boolean nonRoot).
What does "put into the background" mean? Android has an activity stack, once you go back one activity, you can't go back forward. So in that sense, you just close your activity.
If you want your application to keep running and do its stuff in the background, you'll have to resort to Services.
When an application has a single view, the Back button probably resumes whatever previous application was running/suspended. I'm tempted to provide an explicit button which says 'Back' right there on the UI ...
Should I provide an explicit back button in my view, or should I simply override the navigation button provided by the OS? My gut says the latter would be counter-intuitive. Are there any recommendations on this by the android community?
That entirely depends on your application. Normally, your application is made out of multiple activities (Activity objects), and the back button will go to the previous activity.
So if your app has a main menu (activity A), which has a button to go to search (activity B), which will lead to search results (activity C), then pressing the back button on the search page gets you back to the main menu. This is fully automatic, you don't need to write anything for this to work.
That's how Android works, and that's how you should write your app. All Android devices have a device button (physical or on-screen, in case of Honeycomb), so don't waste precious screen real estate on a "back button". Don't be like the iPhone.
I have an activity here.
I want to click a button and then hide the activity GUI.
That is, GUI is needed and you can hide it by clicking a "Hide App" button. How can i
implement this "Hide App"?
Somebody help! Thanks in advance!
To do what you want within the organizational model of android, your "program" should be written as a service, not an activity. You would then have a gui that is an activity and a client of your service, which can be started (made visible) and paused/stopped (hidden) as desired.
Presumably when your user clicks the hide application button, you're going to want to show something - at the very least a show button, so the user isn't stuck without input options!
So what you really have then is two views, one with the GUI hidden.
Two approaches I can see:
Hide app calls another activity with only the UI shown that you want. When the activity is finished, use Activity.finish() to return to the original activity with the GUI
Look at ViewAnimator and its subclasses (ViewFlipper and ViewSwitcher)
You could also just enable the screen lock. ;-)
That would automatically lock the screen (hide your app). And when the user unlocked the screen (using the UI and a gesture the user is already very familiar with) he would automatically get back into your app without you needing to do any extra coding.
The additional advantage of the screen lock is that it can be be password-protected, so if the user has his screen-lock already set to a password, instead of a slide bar -- he would just get the slide password thingy.