what is the best practice regarding the back button currently?
A lot of apps save and restore an entire activity stack when you open them (after they've been onStop and onDestroyed), take Facebook for example, when you open it and your last place was in a photo, then pressing back doesn't close the Facebook app, it takes you back infinitely till the very first thing you did when you opened the app days ago.
This design convention is a little different than what the back button would be expected to do, I think. Where it typically is used to kill the app or stop the main view taking you back to your device's launcher screen.
Facebook was just one example of an app doing this.
Are there developer articles or an authoritative source like Google I/O discussing the utility of this feature (restoring activity stack and having back button traverse through them) vs other functionality (killing the view taking user back out of the app)? If so, please discuss and link them here. I hope this isn't considered too subjective because there is a proper use of the back button as well as an incorrect use
What the Facebook app does actually is the basic default behavior of Android. Those apps don't do anything special regarding that behavior. The Activity stack is saved by default.
One of the more cited blogs regarding it is CommonsWare's BACK means Back. Basically, the functionality of the "BACK" button means it should to take you to the previous page that you just were at. In Android, this is very often the last Activity you just pushed. If the user wants to leave the app, then he or she can press the "HOME" button and that will always push the Activity stack and take the user to the homescreen.
What this means is, the functionality of the BACK button is entirely dependent on the app in question, but the concept is to reverse the action that the user just did. If you are in a game, you go to a sub menu, the BACK button should take you to the top menu. If you are in a browser, the BACK button may take you to the last webpage you were viewing. If you are in a browser and you are in the top page, the user may expect the BACK button to close the app since the last action the user did prior to opening the browser is open the app. If the user starts a download, the BACK button may be to cancel it.
One functionality improvement that Facebook and others like is may consider is to wipe the stack after x number of days since the user may not remember exactly what they did since being interrupted from the last use. The use case for this is very small though.
Overall, this is why people always stress usability testing. You have to figure out what 99% of the people of the app expected when they press the back button.
You can find on the Android Developer site that you should not change the expected behavior of the back button. Let the OS handle the back button.
App does not redefine the expected function of a system icon (such as
the Back button).
That quote is pulled from their Core App Quality page.
You should consider using Up Navigation. You can read more about designing for it here:
Lastly, here is a tutorial on how to implement various types of navigation (lateral, ancestral [up], temporal, descendant).
check here
From my personal experience you can close most, which are using back pressing to go to a previous screen, with a long click on the back button. The best example is the browser app, whether its the native one or a third-party browser
I think that behavior depends on application logic.
By default it is desired to move on previous screen (activity in back stack, or fragment if it was saved to the fragment's back stack).
Actually there is no any silver bullet for this case. Just use "back-pressed implementation" what ever you want. My point is that on back pressed, application must be shown in previous logical state.
Related
I am used to IOS development and there are unwind segues in Swift to exit to a certain view controller from the present view controller.
(If there is any) What is equivelant of Unwind segue in Android Development? What should I do to go back to a certain activity?
This is handled in onBackPressed() of your Activity, which you can override if you want to do anything special. If you want finer control or more detail,
you can read up on FragmentManager, which manages the backstack. popBackStack() and popBackStackImmediate() may be what you're looking for. Generally you shouldn't have to micromanage this too much. By default it'll take you back to the previous activity with no effort on your part.
One thing to take note of as an iOS dev jumping into Android, is there's a difference between back (the button at the bottom), and up (the button in the toolbar up top). The back button takes you back to the previous screen you saw(even to other apps), closes the keyboard, or dismisses certain windows. The up button basically returns you to the main screen of the app, popping the whole backstack. There's some fine points here, which Google does an excellent job explaining in the design guidelines.
I am trying to understand what happens when you press the back button. how does the system manipulate the back stack? From where does it get the window handle to the top window?
I have looked into the PhoneWindowManager.java, but couldn't find what I am looking for. Has anybody seen this code earlier?
What you are refering to as the "back button in the action bar" is called the "up button". The difference between the two is well explained in that article from the documentation: Navigation with Back and Up.
In short:
The Up button is used to navigate within an app based on the hierarchical relationships between screens.
The system Back button 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.
Difference is well market for instance when you navigate to an app from another app. E.g.: you are accessing an application's Google Play screen from a link in your mailbox. Once in Google Play:
Up will take you to Google Play's home for applications
Back will take you back to the GMail application
Well, this will take you back, as like the back button would:
super.onBackPressed();
The documentation for onBackPressed() says that the Back button simply ends the current activity. No back stack manipulation is needed.
At a deeper level, Android does maintain a stack of activities inside of a Task, and it can determine which activity to show next when the top activity finishes. But those mechanisms live in native code and are probably beyond the scope of what you're trying to do. As far as I know, the best you can do from Java is to use RunningTaskInfo (source code here), which will expose the "base" and "top" activities in the current Task.
If you're trying to implement complex app navigation, there are a number of flags that you can use to control the way in which activities are placed on the stack.
I have seen couple of Android applications when I came across one common practice. Navigation header does not have a Back button. Since then I was quite confused so as to place the same in the Navigation header of my application.
Should back button be placed in Navigation (Header) or we should leave keys to handle it? What is the best practice we should follow?
Thanks
My personal view is that each platform has its own way of handling certain functions. An apple device will have a back button on its navigation bar because that is the place where an iphone user will look for it.
As far as Android is concerned, because we are supplied with a physical back button, we must leave it at that because that is the first place an android user will look to if he wants to go back.
Therefore since user satisfaction and ease of use is the main concern, i would not play with the back button (unless i have to).
Similar to the responses above, however for the sake of simplicity I have taken a central approach in which I actually keep a back button in the navigation header however user can still press the hard key back button and the code actually performs the same functionality.
Essentially what it does is to cover both set of users, some really new ones who do not understand Android hard-keys yet, like people used to iOS (pun intended) and the other more suave Android users.
oI believe there could not be best approach. It depends on your custom UI and how much screen estate your navigation consume. The best approach is to buil two variants ant alllow to beta-testers decide.
Allthow back button on the screen could be as much handy, so much annoying.
What the "Back" button actually does, is to close your current activity and bring the previous one to the front.
You can do the same by calling finish() in your current activity. It will remove the current activity from activity Stack and take you to the previous one.
Asaf Pinhassi
OK sorry this is a bit of a "stupid" question.
Currently I am developing an application with a number of views and XML files. If I click certain buttons the view changes etc.
BUT, I want it like stack. So if you go to Page 2, pressing the back button goes back to Page 1. Currently the back button destroys the activity and the application closes.
The only thing I can think of is to have states, so if the back button is pressed, set the view to State X, but I am not sure if this is the "correct programming technique" for Android.
Another thought was to have multiple Activities, so when a button is pressed, a new Activity is created on top of the old one. But this seems inefficient and stupid.
TIA
Yes, you want multiple Activities.
Activities and Intents have a lot of built-in knowledge about the back stack and make it easy to do just what you're describing while providing the user with a coherent experience.
Perhaps you could describe a bit more why you think this would be efficient for your application? Are you creating hundreds of Activities programmatically?
Edit - if you're coming from another mobile platform, where application parts are more tightly bound together, you might try thinking of Android apps as being more like web pages. The most common way to share information is via the query string (Intent) and the back button works because your are arriving at a new page (Activity) for each navigation.
The Widget Sample code, 'Wiktionary' on the android sdk site has some sample code for this in the LookupActivity.java file.
I seem to be missing something obvious here, why would I want more than one activity per application in Android? Does somebody have some solid examples?
Suppose you are creating a game. You need to have at least two activities - a welcome screen, and the actual game screen. The third activity in this example might be a settings page of the game.
Another example.
Suppose you are developing an application and you need to pop up a dialog, i.e. asking user to set username and password (Standard login screen). You might choose to create and activity and apply a dialog theme to it.
Think about it as the form of desktop application. you don't put everything on one form do you? :)
Sorantis' answer is spot on. Here are other thoughts as well:
Most Web applications, even AJAX-y ones, don't try to have everything in one single page. Some do, and those tend to be the ones that are slow as molasses to load (Evernote, I'm looking at you), have code that looks like a heaping mound of spaghetti, etc. Android is no different.
Also, state management for a super-complex Activity will be nasty, causing you problems with screen rotations and supporting being kicked out of RAM because you screw up onSaveInstanceState(). Memory management in Android assumes lots of cheap activities, not fewer massive ones. Intelligently handling the BACK button requires gobs of your own logic. If you want multiple entry points (e.g., Launcher icon and a MIME type handler and something some other app can call with startActivityForResult() and a search results handler), doing that in one activity will be a nightmare. And so on.
One very basic thing that makes having multiple activities in your program desirable is the use of the back button. I have a form in app after the user clicks search he is presented with another activity showing the results of the search. If he wants to change the search parameters he just can press back and without me doing anything particular he gets back to the search form. Doing this with one activity would be a lot of work for you.
The next thing is the memory management. Android will trigger the garbage collection automaticaly after changing activities that means my whole search form leaves the memory and doesn't take any resources away from the user.