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.
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.
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.
I need general advice.
I'm building an app that can be started via the icon (normal way) but also with an intent triggered by a click in the notification area (the app places an icon in the notification area). The is awaken when a time event / alarm occurs.
The app has 5 to 10 views. Is it better to open a new activity for each view? How can I be sure not to have mutliple tasks open? Say if my app is Activity-A, Activity-B, Activity-C and can be started from Activity-A and Activity-B (depending on if it's opened via the icon or the notification area) ... how do I clean everything upon app close?
Or is it better to have one activity and just switch views (xml layouts)?
I'll start of with what you should watch and read. It should be clear that navigation in Android is very easy to do wrong. Google has a history of doing differently from app to app, but they are getting better. This said, if you are to do an app you should know how it is intended to work, and the best way to do that is to read the docs. As mentioned, there was an excellent talk at IO'12. There is also a very good section on the design site, and finally there is a good section in the API Guides.
To summarize: a full screen is an activity (which in turn can be constructed of fragments). The activities should in virtually all cases be structured as a tree with the root being the activity that are launched from home. For every activity you should have an "up" activity that takes you up in the hierarchy. Note that this is different from back which should take you to the last full screen state you were in. Also note that full screen means that for example tabs should not be recorded in the "back history", since they provide navigation within a screen.
When it comes to tapping a notification it should be equivalent to: pressing home, remove the task from the recents view (clearing the task), opening the task, and finally take the shortest path to get to the activity presenting the info that the notification told you about. Complicated, yes indeed... But at least there is a helper class in JB and in the support library called TaskStackBuilder.
The key to all this is a UI design that follow the Android design guidelines. Take your time to make the design for your app, and make sure to separate up (static) and back (temporal).
It might be as simple as using a different launchmode, which you can define in the manifest or I think in the inent you are using. It takes some experimenting but SingleTask or SingleInstance may be the right choices for you,
Your activity should support onNewIntent in this case, to reuse existing Activities if that is the desired effect.
In this case I better use one activity or use fragments.
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.