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.
Related
I recently put my hands on Android development and hence have to ask here a query that I have.
In my test app I have a BottomNavigationView, which has 3 options to click. I have seen in many apps that if a selection is tapped it further slides up another sub menu. I couldn't find enough information about this feature.
Looking for a direction if anyone has came across such requirement in the past.
This feature is deprecated now. look at say goodbye to menu button
if you still want to perform some action on navigation buttons, Override onBackPressed method in your activity so that you are able to perform some action on click of back button of bottom navigation bar.
I am currently rewriting one of my iOS apps for Android, and I am working on adding tabbed navigation. The problem is, I haven't found a way to integrate tabs into an Android app without them being sliding (swipe left and right to switch tabs).
In the iOS version of my app, the middle of the three tabs contains a full-screen map view, so obviously in Android with the sliding tabs, the middle tab would not be slidable. I don't want this, as I would like to maintain consistency between the tabs.
Is there a way to deactivate the sliding on tabs? Or is there a way I could intercept the gesture in a similar way to the way a map would absorb it?
so obviously in Android with the sliding tabs, the middle tab would not be slidable
Actually, by default, it would be swipeable, though this would mean that the user cannot pan around the map. You have to take special steps to make a MapView get the touch events instead of the ViewPager, for reasons I have never fully understood.
I haven't found a way to integrate tabs into an Android app without them being sliding (swipe left and right to switch tabs)
Use FragmentTabHost. Or, use TabHost. Or, write your own tab implementation that toggles the visible view or fragment.
Note, though, that your users may expect to be able to swipe between tabs, if the tab content itself is not something that obviously would take precedence (e.g., the map). Users may prefer that your app be consistent with other Android apps, rather than be consistent with an app (your iOS app) that none of them use.
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.
Im creating an app with an action bar, and the tabs go to different web pages. When the user clicks on a different tab I want the previous tabs web page to stay in the same state (ie not reload when the tab is pressed again).
Whats the best way to do this? Separate activities? Fragments? Multiple web views in one activity?
Thanks
Use tabs in the ActionBar, which allows you to use Fragments. When changing tabs, the Fragments will replace, and the previous Fragment will hold its contents.
See Action Bar - Adding Navigation Tabs | Android Developers
I think you have to use one webview and store content of each page locally for example in DB and then make yourself some navigation bar and reload your webview content by navigation bar.
For example navigation bar can be orginized like LinearLayout with Buttons childs.
If you use this way - for example you can download 10 web pages at home with your wi-fi and then minimize your app and go for a walk and after some time (even if you use other apps) you can restore all your information from DB, but if you use only fragments in tabs you can loose you pages because of memory lack.
If you use fragments or atcitvities in tab - you can't be sure that previous content will be saved (but you can still do it by adapter and tabhost (there are quite enough samples how to use fragments + tabs)
PS. this is only my opinion and i haven't tried it yet, but i think local store is a best way to resolve your problem.