Develop Reference

Back vs. Up - Intended behavior

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).

Prism Navigation in Xamarin Forms - MasterDetailPage

I have a master detail page setup using Prism 6.3 pre-2, I've finally got it working as I expected for navigating to "detail" pages; so the hamburger button shows the slide drawer and I have a simple ListView bound to the ViewModel, I list some items, and I use the NavigateCommand to navigate correctly.
Now, the expected behaviour (in Android), is when you've navigated to other items in the slide-out menu, you should be able to use the hardware back button to navigate back to the very first "detail" page shown.
For example, say your app has this setup, and the items listed are Inbox, Drafts, and Sent. The default view is going to be whatever you decide is the default detail view, in this example, it will most likely be Inbox. So if I navigate to Sent, and then press back, it should go back to Inbox, also, if I go to Sent -> Drafts, and then press back, it should go back to Inbox, as this is the default starting point, if you then press back again, the app should exit. At the moment, using Prism navigation, no matter what page you navigate to using this setup, it will exit straight away.
Please note, I have set it up correctly, I essentially have something like this (as an exmaple):
await NavigationService.NavigateAsync("RootPage/BaseNavigationPage/InboxPage");
When I navigate to say another page like Sent, the relative URI is like so:
"BaseNavigationPage/SentPage"
Now, when back is pressed, it should go back to the InboxPage, I'm not sure how this can be fixed... Brain...???
In addition to this, there is one other unexpected behaviour that is missing.
If I want to show a modal page whilst using a Master Detail Page, it doesn't work as any app written by Google does... This is easy to see if you open any google app that has this layout. If you show a modal window for say Settings, it pops up, has the navigation title set and a back arrow, basically looks exactly the same as if you've navigated one step further down like:
"RootPage/BaseNavigationPage/InboxPage/EmailPage"
However, I expected this functionality to be available if I did the following:
"BaseNavigationPage/SettingsPage", useModalNavigation:true
If you simply play around with any Google made application you'll see these features, and these are what I expect and they feel natural.
Any help available to achieve this...? again...Brian...?
All of this should be simple, but it's proving not to be...

To get the behavior you are wanting with the NavigationPage in a MasterDetailPage scenario, you must create a custom NavigationPage that implements INavigationPageOptions and set the ClearNavigationStackOnNavigation property to false. This will kep the NavigationPage's navigation stack in place with each navigation operation.
As to your other "expected behavior" regarding modal navigation, your understandings about modal navigation are wrong. Modal navigation does not provide a software back button. Any time you want a software back button you must have the pages wrapped in a NavigationPage,

Android navigation system/bar square button

I do not find on Internet, what is the name of this button ?
And I want to know what is the exact action when an application is deleted like this :
With this action, the application is not really stopped

The Third Image means Square is called Overview button(Recent Button). When Click on That Button the list of application is display which you are work on it. and you can simply remove app from the list by slide app Right to Left.
For more detail visit this : https://android.stackexchange.com/questions/32697/what-is-the-offical-name-of-the-third-on-screen-button

Navigation Drawer "Up" button when in deeper sections

I want to transform the upper left button that normally allows to open the Navigation Drawer to become a "Up" button (with the left arrow).
I looked everywhere but I couldn't find even a question where this problem is answered in a quick way.
Details:
I have a single Activity. The NavigationDrawer contains a list of elements. Let's call them Element1 and so on.
When I open the application I can see a "Home" Fragment that contains a sort of splash screen with some basic details of my application.
If I open the Drawer and select Element4 I switch the "Home" Fragment with the "Element4" Fragment. The icon at the top left should become the classic "Up" icon as intended in the Google developer site and allow me, touching it, to come back to the "Home" Fragment.
A simple example could be the NavigationDrawer application mockup created by Eclipse in its wizard. I want to modify it to make the 0 section the home section and if the 1 section its child.
Maybe if someone that knows how to do answer me it'll be a big help not only for me but for many other people.
Thanks

Wiping Activity stack

I'm implementing a not-so-standard navigational menu that is accessible from every screen in my app. That is to say, from every screen in my app, I can pop up a menu that will let me choose an entirely different area of the app to navigate directly to.
I have several screens that I call edit screens. They are screens where the user had chosen an item from a list of items and are able to then edit the data for that item. I do not wish for these screens to remain on the Activity stack if the user then uses the menu to navigate to some other area of the app.
This is easy enough. I can simply call "finish()" before navigating away. However, there are a couple places where it is possible to access a nested edit screen. Meaning the edit screen the user is currently on is a child of a parent edit screen. I want both off the Activity stack.
Can anyone think of a slick way to do this? The only way I can think of is to always use startActivityForResult and pass back some identifier that tells the screen to kill itself the next time it resumes.