I was wondering if it is possible to implement an expandable menu for NavigationView like we would use with expandable ListView. Right now i am just clueless where to even start.
The NavigationView is purposely limited, so it it likely difficult to customize it in the way you are asking (but not impossible, as anything can be done with enough effort and hacking).
The limited nature of the NavigationView is by design - it is supposed to be the main navigation control for your app, and be very simple. You shouldn't try to customize it in the way you are asking, and instead see if you can fit your navigation into the existing model.
This is designed to be hard to customize, so you will keep it standard (and your app will stay consistent to Material Design standards).
Bottom line, see if you can fit into the existing model, instead of trying to customize it (and thus be non-standard).
Related
I've run into a very peculiar problem with Toolbars. The way my team currently uses the Toolbar is via a wrapper class, let's call it WrapToolbar.
So WrapToolbar will internally setup a Toolbar, and exposes some common Toolbar functions. Things like setTitle, getTitle, etc are available.
This WrapToolbar also sets up a default icon. This way all usages of the WrapToolbar will have this icon available for the screens that need it.
The problem with this approach is that for screens that require additional icons, have to add them via a Menu XML and the onCreateOptionsMenu function.
When we do that, the default icon setup with WrapToolbar gets pushed to the left, and the new icons from the Menu XML get added at the end.
This has worked fine for us until recently when requirements changed, and now are asking for the default icon to be at the end all the time.
I'm currently wrestling with the idea of doing a custom wrapper around Toolbar that exposes the ability to add icons, get the title, set the title, etc. This way we can put the icons in any order, and have ultimate flexibility in how our Toolbar looks.
I'm looking for some guidance on what that might look like. I also want to get some feedback on whether my initial idea to solve for this is flawed in some way I haven't foreseen.
Menus have a built in ordering based on the android:menuCategory attribute - you can use android:menuCategory="secondary" to push a menu item (like your default icon) to the end of the list - all MenuItems without a menuCategory will appear to the left of it.
I am new to android i didn't understand what is the use of toolbar. In place of toolbar we can use any layout like relativelayout then we can design it.
And in toolbar if you want add any button we are creating menu folder and we are doing so many nonsense thing
So inplace of taking toolbar better to take layout.
Please anyone give me the answer why we are using toolbar and actionbar
Toolbars are useful because you can use them in layouts, apply any themes and even create a menu. Toolbars extend viewgroup - that's makes them extra flexible. They are used in layouts to create material designed themed apps. Why does that matter? That's what the users on Android are used to and if you have a custom toolbar you might confuse your potential users. And you get all of this functionality for free, instead of using a layout and manually setting the styles and menus.
So why should you use the supplied toolbar? It's the same with using any component created for use on Android; Don't Repeat Yourself. DRY is the golden rule of software development, and by using these layouts across apps it makes it easier for the users of your apps to understand how to use your apps
It's not an absolute requirement to have a Toolbar, but it has been a staple of the material design paradigm for a while. On many apps, it's used to show the app title, or to house navigation components for example. I suggest you take some time and read the material design rationale for the Toolbar. https://material.io/develop/web/components/toolbar/
The documentation provides some context and suggested usages of the ToolBar in the first sentence of the description.
MDC (Material Design Component) Toolbar acts as a container for multiple rows containing items such as application title, navigation menu, and tabs, among other things.
I have my app UI something like below but with a difference being it's a deck of flash cards.
Now that means I'm making use of material design principles and features. My questions are:
Where should the FloatingActionButton be placed (in activity_main.xml or fragment_main.xml), when the point is to add/remove cards to favourites list, that can be reviewd later.
Where should the TextView element be placed (in activity_main.xml or fragment_main.xml)?
I intend to use ViewPager for swiping cards. And construct the entire UI as part of the fragment_main.xml. And I avoid the temptation of using AppBarLayout and Toolbar; instead use the regular ActionBar.
As I see things this would make code design simple and easy to maintain. Correct?
The best thing to do is to continue taking advantage of fragments for any and all content that is going to share the same layout while also being somewhat independent.
Fragments are reusable, modular bits that can be placed in many activities, For example an Action Bar with an "Add to Favorites Button" used on all Activities can 'live' in its own fragment.
You can define many different Fragments as well, that is, one for the Action Bar named fragment_actionbar and another named fragment_flashcard, each with the needed space and items for information. This gives you further freedom down the road, for example leaving a fragment_actionbar off of layouts bigger than a certain size/density. This will allows you to "make code design simple and easy to maintain."
More on Fragments
As for Material Design, As long as you are taking advantage of the principles taught and shared inline with Material Design, you are following the practice. Broadly, Material Design asks creators to make designs with paper and ink as inspiration, with light, surface and movement being the key drivers to this design approach. Simple Shadows, Bold and Solid Colors, Motion as Meaning, Large Type and utilizing Negative Space are also characteristics of Material Design. Best advise, stick with Androids predefined modules for now and materiel design practices are already being followed/utilized.
More on Material Design
I need to incorporate a youtube like drawer navigation drawer for both(left,right) sides. AFAIK android apis don't provide means for the right-to-left drawer functionality. There're quite a lot of implementations out there(sliding menu) which do.
This sliding menu feature seems to present a performance issue. Should I try to rewrite original NavigationDrawer, which I expect to be the least performance-impact solution, or there is another performance-optimal library?
Thanks.
I would choose NavigationDrawer. I used both and I find NavigationDrawer smoother. If you try to mimic google UX then with NavigationDrawer should be enought for your needs.
I recently made a project/demo to implement NavigationDrawer with ActionBarSherlock for pre Honeycomb devices because I need for an app.
SherlockNavigationDrawer impl
Another thing to take in mind is that if you use NavigationDrawer try to avoid Tabs because all the tabs items could fit perfectly as a listview in NavigationDrawer.
Actually NavigationDrawer supports drawers on both edges.
You have to supply the two drawer views inside your layout xml; one with gravity:left and one with gravity:right.
Then, in your Activity you call setDrawerLockMode(DrawerLayout.LOCK_MODE_UNLOCKED) on your DrawerLayout object.
This will enable swiping either from left or right edge.
#Michał The question is actually implementation of both left as well as the right drawer.
#midnight NavigationDrawer right now only implements one-sided menu which you can place either on the left or the right. If you want to implement the other pane also you can make your content layout as SlidingPaneLayout.
This was also added to the latest support library along with the NavgationDrawer. For an implemented example you can look at the newest Hangouts app on how they are using it. This layout will probably suit your purposes better rather than rewriting the NavigationDrawer. In any case i'd hold off on re-writing it since it is the first release of the Layout and may undergo changes fairly quickly.
Since the last version of SupportLibrary there is a NavigationDrawer in Android.
Recently I became the proud owner of an Android 4.0 tablet and have been snooping around trying to create some apps. Now that I have the basics covered, I'm diving more into the "what's good/what's wrong" parts.
As far as I understand, the old "menu/settings"-button is deprecated (in the sense that you shouldn't use it anymore) and now the ActionBar is the way to go. Upon reading further, I came across this: http://developer.android.com/resources/samples/ActionBarCompat/index.html
It shows how to use the ActionBar on pre-API 11 systems. On the left you can see the typical menu where all options are shown a developer decided weren't important enough to be in the actual UI (the "wrong" way, but programmed using the newer ActionBar API). On the right, that same menu is now on the ActionBar.
My question is: Since it's been said such an "overflow"-menu is bad design on older mobile devices, is it also bad design when it's on the ActionBar as a button like shown on the right screenshot? Or is it only considered bad design because on a lot of devices it required you to press a physical off-screen button which makes it a non-issue when it's a virtual button on the ActionBar?
In short: Should I avoid it or not? Frankly, I like the idea of having a menu on the far right with all options that either don't fit or aren't important enough to be their own entity on the ActionBar.
Please also point out if any of the information I gathered and explained here is wrong.
The options menu hasn't been removed, it's just moved. It used to be hidden "behind" the Menu button on the device, but it's now moved to the ActionBar. Items on the menu either show as icons on the ActionBar, or on the overflow menu. You use exactly the same code to add items, whether to the old style menu, or the new style ActionBar.
A big part of the improvement that's been made is there is now a visible button on the top-right of the screen to open the "menu" (ActionBar overflow), which is right next to the other options. this is much better than before where the menu button had no visual connection to the app.
I suggest you look at ActionBarSherlock, http://www.actionbarsherlock.com, as it makes it pretty easy to add the full ActionBar to pre Android v3.0 devices.
http://developer.android.com/design/patterns/actionbar.html
Finally, I'd suggest that you follow the UI guidelines from Google. If they say the ActionBar is the right approach for navigation, then use it. It's best to use the provided UI patterns, and focus on the domain-specific stuff in your app.