With the new NavigationView
is it still recommended to use ActionBarDrawerToggle
or is this not "Material Design"? For instance previously we were supposed to hide action bar items when the drawer was opened but now the guidelines say that they should stay.
相关问题
- How can I create this custom Bottom Navigation on
- Bottom Navigation View gets Shrink Down
- How to make that the snackbar action button be sho
- Listening to outgoing sms not working android
- How to create Circular view on android wear?
相关文章
- android开发 怎么把图片放入drawable的文件夹下
- android上如何获取/storage/emulated/下的文件列表
- androidStudio有个箭头不认识
- SQLite不能创建表
- Windows - Android SDK manager not listing any plat
- Animate Recycler View grid when number of columns
- Why is the app closing suddenly without showing an
- Android OverlayItem.setMarker(): Change the marker
Yes. The two tackle two completely different aspects of the navigation drawer.
In total, there are generally three components to a navigation drawer:
DrawerLayout
The
DrawerLayout
is the layout that holds the navigation drawer content and your app's content. It is what allows you to pull the drawer in from the side and display the drawer over your app's content (the first child of theDrawerLayout
).Your navigation drawer content (the second child of your
DrawerLayout
) is typically a list of items that the user can click on. Previously, most implementations that I have seen used aListView
or aRecyclerView
and maybe a header of some sort.NavigationView
is a replacement for this, and is used to provide Material-compliant drawer contents.ActionBarDrawerToggle
is used to provide the hamburger icon in your app bar. It is what allows your users to tap on the icon to open or close your drawer.Completing the other answers, the Navigation View should be fit into the whole screen in terms of height so it will hide the hamburger icon when opened. Because of this, having the animation from burger to arrow or even just showing the arrow is not necessary.
But when clicking on the current screen it goes to another fragment, imagine a gallery of photos and clicking on a photo will show it bigger, there should be an animation from burger to arrow and the arrow should stay and when pressed there should be a reverse animation to the burger so the navigation view can be opened again.
You can achieve this with ActionBarDrawerToggle still, even with navigation view because it uses the same DrawerLayout as before. So it still has uses, but of course not necessary.
No, it's not required.
If you look at the "official" demo code for the new Design Library,
ActionBarDrawerToggle
is no longer used, since the newNavigationView
andAppCompatActivity
don't really need it.With the new v22 support library, you can strip out all of your
ActionBarDrawerToggle
code and just use the following to handle the interaction betweenNavigationDrawer
and theActionBar
/ToolBar
hamburger icon:You will need to provide your own "hamburger" drawable (
R.drawable.ic_menu
in my example). Besides that, the above code is all that's needed to handle opening of the drawer. Theandroid.R.id.home
case inonOptionsItemSelected()
represents your hamburger drawer button. It points to a built-in resource id (not something you add to you menu xml), and it's handled automatically.Besides that, you have to implement closing of the drawer by simply adding
closeDrawers()
to your click listener, like this:closeDrawers()
is a method of DrawerLayout, and takes care of everything. That's it. That's all the code you really need to properly handle navigation drawers now. No more messy code for flipping hamburgers and such!Of course, if you really want to, you can still use
NavigationView
withActionBarDrawerToggle
the old way. But you certainly don't have to.If you want drawer callbacks
Even though
ActionBarDrawerToggle
is not required to open/close the drawer, it may still be useful for handling additional callbacks (especially if you're using ActionBar already). Otherwise, you can implement your own by usingDrawerLayout.DrawerListener
or by usingDrawerLayout.SimpleDrawerListener()
, to handle other open/close related events.