I have a simple list and detail pages for an app in mobile. It is done with navigation component (not Jetpack). The nav graph will look something similar to the one below.
1 -----> 2 -----> 3,4 and so on.
Now, the same app should work for tablet as well. But for the UI, the list and detail must be shown in the same first page in split.
1,2 ----> 3,4 and so on.
How do we make it work with navigation component itself?
Related
I have a list of persons that when user click on one item the app show its detail ! i used dual pane Master/detail design pattern for tablet size and for small size it just replace list with detail fragment.
The problem is that my manager think its better to change this design with navigation drawer ! what is the best choice for this case ? navigation drawer or master/detail design ?
which is better for user experience ?
The Navigation Drawer is:
a panel that transitions in from the left edge of the screen and displays the app’s main navigation options.
Per the App Structure guide:
A navigation drawer is a slide-out menu that allows users to switch between views of your app. It can hold a large number of items and is accessible from anywhere in your app. Navigation drawers show your app's top-level views, but can also provide navigation to lower-level screens. This makes them particularly suitable for complex apps.
And the Material Design structure guidelines state:
The content in the left nav is ideally navigation- or identity-based.
The Navigation Drawer is not listed as a mechanism for multi-pane layouts, while a master/detail multi-pane layout is specifically mentioned.
In short: Navigation Drawer is for navigation only and not for displaying a master list with corresponding detail.
In fact, one of the framework engineers wrote a Google+ post back in 2013 specifically about how they tried to use DrawerLayout (the class name for the navigation drawer) for displaying master/detail style content and instead built a separate component, SlidingPaneLayout specifically to address this issue of displaying master/detail on smaller screens without using the Navigation Drawer affordances or pattern as they just did not fit. Note that this has fallen slightly out of favor in Material design, with a re-emphasis on a traditional master/detail pattern with meaningful transition animations.
You can create 2 demo apps to see the difference on a phone.
Master Detail flow:
The master page (menu, or list page) will always be displayed to the user first and the master page covers the whole screen. If the user does not tap, he/she will not notice there is a detailed page.
Navigation drawer:
The detailed page will be displayed to the user first, with a navigation menu (3 stripes menu) on the top left corner.
If the user taps the navigation menu, he/she will see a sliding out page, which covers only half of the screen. For the most of the time, the menu screen will be hidden.
So they are actually very different from the design aspect. Of course, they have similarities during implementation.
I'm used to using a 3rd party library for implementing a navigation drawer (sliding menu) in Android, but I want to use the native version from now. I went through the tutorial (http://developer.android.com/training/implementing-navigation/nav-drawer.html) which is pretty straight forward.
I typically extend the 3rd party navigation drawer to each activity by defining the configuration in a base class. The new nav drawer, however, swaps fragments in and out, which my research indicates is the standard way of managing your displays.
This seems fine, but my app has a fairly complex hierarchy of pages and navigation. Like most apps, it contains more fragments than just the ones in the menu.
So if I have 3 nav drawer items for fragments A, B, and C, and I can only load fragment D from fragment C, do I handle that navigation logic in the activity where I configure the nav drawer? It seems like kind of a nightmare to have one container to swap out an indefinite number of fragments, especially if the work flow is deep.
From what I can gather on Stack, there seem to be a lot of people who are familiar with extending a 3rd party drawer in each Activity, but when they switch over to the native version there is confusion.
So to summarize, I understand the fragment swapping aspect of the navigation. I just don't understand how the rest of the work flow navigation would work, say if I had several detail screens below a nav item fragment. If anyone can give me some hints on how best to approach this scenario, maybe I can experiment and post some code for future readers.
For navigation in Android there is always one thing you have to remember:
If you stay on the same level of the navigation hierarchy, for
example when swiping through pages, you use Fragments.
When you move up and down in the navigation hierarchy, for example
going to a detail view, you would start a new Activity and displayed the
Fragment with the detail content in it.
A NavigationDrawer is used for top level navigation in your app to quickly navigate between different parts of your app. It's kind of like a main menu. With that in mind you need to determine if a NavigationDrawer makes sense in your app. It's all about how the user should navigate through the content. If there is just one path for the user to follow for example if you start out with just one screen and from then on the user can just go deeper and deeper in the navigation hierarchy from one detail view to the next than a NavigationDrawer does not make much sense. But if there are multiple paths the user can take that lead into different, independent parts of your app without one dedicated start screen on which everything else depends than a NavigationDrawer sounds pretty reasonable.
You can look at Google apps like Gmail, Drive or Google+ to see how a NavigationDrawer is supposed to be used.
I am looking to replicate the iOS app my company makes and on tablet in landscape they have a second nav drawer slide out from the first for the second level of categories.
e.g. in the first level they have clothes, shoes, accessories, then if you click clothes a second one appears scrolling to the right from the far right of the first nav bar, that then shows things like shirts, t-shirt, jeans, jumpers etc.
Is this possible in android? And if so, is it the accepted way of doing things?
Thanks
on tablet in landscape they have a second nav drawer slide out from the first for the second level of categories.
That's not a nav drawer, then, at least as defined by Google.
Is this possible in android?
Sure, just not using DrawerLayout. Execute a FragmentTransaction to slide in the second list adjacent to the first list, neither of which are in a DrawerLayout.
And if so, is it the accepted way of doing things?
For a two-tier structure, I suspect that you will see other patterns used:
ExpandableListView
tabs for the first tier, and simpler master-detail for the second tier
action bar list navigation for the first tier, and simpler master-detail for the second tier
etc.
I can't even rule out DrawerLayout as being the implementation of the first tier (with traditional master-detail for the second tier), though the stuff in that list does not strike me as fitting the usage pattern for a navigation drawer.
Sure, It is possbile. But it is not a practise using in android.
If you want to implement this design, the best way is to use two fragments instead of navigation drawer and use FragmentTrasation to provide the animations.
I am switching my Android app over to a more "proper" UX with the ActionBar etc. I have been trying to determine what the best/recommended navigation style would be.
My app has 5 activities that I currently switch between by using the menu/overflow menu.
My app has 1 main home screen that the user will spend most of their time on. The user needs a way to navigate to the other activities but none of them are really related to eachother. They are more like utility screens that a user will go to when they need to do some maintenance.
I am reading this link: http://developer.android.com/design/patterns/actionbar.html
I was first thinking to use an action bar dropdown navigation but that seems like it's not designed for navigation and more so for switching between views of the same data:
Use a spinner in the main action bar if:
You don't want to give up the vertical screen real estate for a dedicated tab bar.
The user is switching between views of the same data set (for example: calendar events viewed by day, week, or month) or data sets of the same type (such as content for two different accounts).
Then I was going to use ActionBar tabs but it says that is more for swiping between items that are used often:
Use tabs if:
You expect your app's users to switch views frequently.
You want the user to be highly aware of the alternate views.
I guess the last option is to put the actions into the overflow menu but this seems like i'm going backwards.
Can anyone offer some insight?
Thanks
I have decided to go with a side drawer as per here:
http://developer.android.com/design/patterns/actionbar.html
Open a drawer from the main action bar if:
You want to provide direct navigation to a number of views within your app which don't have direct relationships between each other.
I want to create a app with a menu at the bottom of the screen. This menu should be visible any time the app is started.
Im working with fragments, so the menu is one fragment.
So I have only one Activity as controller which loads different fragments above the menu fragment.
Because I want to create clean code, i dont know how to solve the problem that the Activity class is too big.
In other words, i want to create different controller within the same activity. How to do that?
Is there another approach to solve this issue?
You should be using the split action bar This allows you to put the Actions and overflow menu on the bottom of the screen. I believe you can use Action Bar Sherlock for backwards compatibility to older versions of Android. See their site for detail.
Another possibility is to look into using fragments with the ViewPager . Here is a library that works with compatability as well ViewPageIndicator . Here is a blog post , like I indicated in my comment I got this working with the tabs showing at the bottom and the pages above.