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,
Related
I noticed an insanely big bug with the Shell navigation. Am I doing something wrong?
Let's say we add 3 FlyoutItems to the Menu. After that navigate to the first one, then the second one, and finally the last one using the menu items.
Then press the back button of the mobile phone (I have Android 11). It will collapse the whole application to the background instead of navigating back to the second Page.
What do you think? That is a huge-huge UX bug In my opinion.
When I do the navigation with the await Shell.Current.GoToAsync(nameof(MyPage)) then the navigation stack is builded, so the back button will bring the previous page. But why not with menuitem navigation?
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).
So I want to create a back button on every View I open in my Xamarin Android app. To explain better here is the screenshots, that will help me explain my problem:
Lets assume this is my first view when I open app:
When I click three dots popup menu opens. And for example I select Profile item.
Then this view opens:
Now as you can see at the top I have back button, but the text near the button is hardcoded... How can I make it show me previous view name? In this case it should be "List".
Moreover, I don't know how to implement back button to get back, and I was looking for any kind of tutorial or example, but couldn't find any... could someone please help me?
UPDATE 1
I am using MvvmCross in my application there are some places where I navigate between activities and some places where I navigate between fragments, I thinking about unifying everything and make navigation only between fragments...
For now I didn't made any implementation of back button, I need some help with that
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 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