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.
Related
The navigation design guide explains:
When the previously viewed screen is also the hierarchical parent of the current screen, pressing the Back button has the same result as pressing an Up button—this is a common occurrence.
up vs back - navigation guide
I have a MainActivity A which opens another activity B when touching a navigation entry in the NavigationDrawer. Activity A is set to be the parent of activity B in the AndroidManifest: android:parentActivityName=".MainActivity"
I followed this android documentaion to add up navigation to activity B. It shows how to implement onOptionsItemSelected in activity B:
override fun onOptionsItemSelected(item: MenuItem): Boolean {
when (item.itemId) {
android.R.id.home -> {
// Respond to the action bar's Up/Home button
NavUtils.navigateUpFromSameTask(this)
return true
}
}
return super.onOptionsItemSelected(item)
}
When I press back from Activity B the state of Activity A was saved and the NavigationDrawer is opened. If I use the up navigation though, onCreate()of activity A is called and it lost its state (the drawer is closed etc.).
This is not the quoted "same result".
When I replace the NavUtils.navigateUpFromSameTask(this) with a simple finish() it has the same behavior as pressing back - the state of activity A is kept.
Naturally I would prefer the way using finish. So what is the intended behavior? Do the guides contradict each other or am missing something?
It is an unfortunate reality that Google leaves documentation up for longer than it is relevant, and will even post two different pieces of documentation that directly contradict each other.
In the case of the Up button, your link says
The Up button appears in the app bar and is used to navigate within an app based on the hierarchical relationships between screens. [...]
The Back button appears in the system navigation bar and is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy.
However, there is also this article, which says
When the system Back button would not exit your app, such as when you are on your own task and not on the start destination, the Up button should function identically to the system Back button.
So... which one should you trust?
I assert that you should trust the second one. The first one was posted years ago; I don't know its exact age, but you can tell that it's old because the screenshots all use the Holo theme. The second one, on the other hand, is part of Android's Architecture Components, so is significantly newer. In general, I'd go with the newest piece of documentation.
Additionally, I think that Google was wrong to say for all these years that the Up button should work differently from the Back button. As someone who spent a lot of time thinking about navigation in my app, I see where they were coming from, but real-world users always get confused when Up did something "different".
So I'd go ahead and just finish() your activity when the user presses the Up button, and not worry about those two articles you found.
I think the change of policy to suggest consistency between the up icon and the system back button is a good idea. However the advice that you should:
"navigate in reverse-chronological order through the history of screens"
Is too crude, or at least should be clarified what they mean by "screen".
eg. When you have a bottom nav bar, the back button / up icon should take you back up the hierarchy within your tab section before jumping to the section previously visited. And you should preserve the previous state when revisiting a tab section (which may be drilled down into a lower level screen).
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.
I am looking for the best way in which you would setup navigation in an Android game; a best practice for Android Game Activity Navigation. I have the following scenario:
A Main Menu Activity (Greets the User on Start and gives them options)
A RunLever Activity (This runs a level of the game)
A Transitional Menu Activity (This appears between levels and shows scores and stuff like that while providing a button to go to the next level)
Therefore, if the player starts the game and completes two levels they might have an activity stack that looks something like this:
The problem that I have here is one of expectations when the back button is pressed:
If I was on the last In Between Menu and I pressed back then I would expect to go back to the Main Menu. Instead it would probably take me back to the level that I just won.
I would not expect the last levels that I have played and previous In Between Menu activities to stay sitting there in the Back Stack. I would only expect the Main Menu, the Current Level I am playing and one instance of the In Between Menu to be sitting in the back stack at any one time.
As far as I can tell everything else will work properly and as the user expects. I guess I just want to know what the best options are to solve this kind of problem. To make sure that the activities in this game occur as expected. Should they even be separate Activities? Thanks.
Rather than pushing a new In Between Menu Activity after completing a level, can you instead pop the activity stack, and detect that (e.g.) level one has been completed when the already-there in between activity becomes active again?
That way, the first "back" would always go back to the in-between, the second "back" would go back to the main menu, and the third "back" would leave the game. All of which is probably what the user expects.
I have read into the finish(); commands and the FLAG_ACTIVITY_CLEAR_TOP commands and also checked out Common Ware's answer on killing app, but I am not sure how to put this into my app.
Basically, I have a user click a button that takes them to the camera. The user then snaps a photo and it brings them to a layout view. The user then clicks a button that takes them to one of 2 views, depending on a some conditions.
The user is then allowed to either retake a photo, or go to the main menu (depending). My problem is, if the user goes back to the main menu, and snaps another, then another, etc...the activities stack, so when I click the 'Main Menu' button the app goes back through eached stack activity until finally it goes back to the main menu. Is there a way to kill each activity with one of these lines, so even if a user retakes a photo, they will only need to go back once to get to the main menu?
Thanks for anyhelp.
You could use the noHistory flag which would end each activity once you're away from it.
Probably though, what you really want is singleTop launch mode, that will return to your previously opened activity rather than making a new instance of it.
I am writing a android application where, on startup activity view, I have a button "DoIt". When user clicks "DoIt" button, I start another activity with different layout. On newly started activity, I have a button "Back" which should take me to the first activity. How to accomplish this. What code should I write on OnClick method of "Back" button. Also, I want the newly created activity to die after back button is pressed and application comes back to start-up activity.
In the new activity you can just call
this.finish();
to return to the previous activity. If you want a result from the child activity you have to launch it with startActivityForResult() and override onActivityResult in the parent. The hard back key should always go back to the parent activity by default.
Call finish() on your activity. Also, why are you making a button on screen for this? This is usually the job of the device's back button.
In my opinion, Android is really bad on such scenario. In Activity, it doesn't support multiple views. Consider the situation that users want to switch from these two views, or even several other views? I think in this case, iPhone is much much better.