I have an application that is using the ActionBarCompat library as well as the NavigationDrawer support library.
I have managed to set up ActionBarDrawerToggle to get the drawer indicator on ICS+ devices, but it doesn't automatically enable it on Gingerbread devices with the ActionbarCompat.
Does anybody know of a way, or what changes I would need to make to the ActionBarCompat to enable the drawer indicator for those devices?
I managed to solve this by manually adding an image view as the first item in the ActionBarCompat, by modifying the construction of the compatibility bar in the library itself.
I believe the particular class in question is ActionBarHelperBase.java
Once this is in place, I animate it (similar to the real one) by translating the image in drawer open/close callbacks.
I say "similar" because the difference with my "hack" is that it will not animate until the drawer has finished opening/closing whereas the real one opens/closes WHILE the drawer is opening closing. it is a minor difference and doesn't/shouldn't cause too much issue.
There is not need to do conditional checking within the class because the code is only ever called for "compatible" ActionBars (i.e. pre-honeycomb).
Related
Alright, I am trying to understand what I would lose if I use Toolbar as a self-managed ActionBar and not use setSupportActionBar.
AFAIK, all that ActionBar does is, provide placeholders for logo, navigation and menu items and also let Fragments add/customize the menu items.
The same functionality could be achieved using Toolbar.setLogo(), Toolbar.setNavigationIcon(), Toolbar.setNavigationOnClickListener() and Toolbar.inflateMenu() apis. Of course, directing the menu handling logic to Fragments might be lost but I think that is not that big of deal if the Activity knows which Fragment is on top and changes the menu items accordingly.
I am trying to make sure :
If I can achieve every ActionBar capability just by using Toolbar and MenuItems (and not using setSupportActionBar()).
Is it ok to not have an exhaustive knowledge of ActionBar apis. Some of the ActionBar apis are very confusing. Using setHomeAsUp api to show hamburger icon, back icon etc., doesn't feel right. If someone starts learning android today, do they even need to understand the framework's ActionBar apis?
Update : In the article Android Design Support Library under section CoordinatorLayout and the app bar, I learnt that the new paradigm app bar is a replacement for the action bar paradigm. I think action bar will soon be deprecated and we should get used to the new app bar paradigm which covers the new material design user experiences.
Yes you can use achieve similar capabilities of ActionBar in Toolbar.
Mainly the difference lies is Toolbar becomes part of View so we can much more fun playing with them to get Scrolling Techniques
You can use Toolbar separately as View & perform ActionBar alike functionalities. For example, in one of my app I use 2 Toolbar one which is set to setSupportActionBar() while other is just used for some other functionalities.
Conclusion: Well it depends upon your requirements if you want to use Toolbar as self or framework. None the less you can use it as both.
I hope this answers your question well.
To me you are right.
From AppCompatDelegate source code, method setSupportActionBar(),
When set to a non-null value the getSupportActionBar() method will return
an ActionBar object that can be used to control the given toolbar as if it were
a traditional window decor action bar. The toolbar's menu will be populated with the
Activity's options menu and the navigation button will be wired through the standard
android.R.id.home menu select action.
So these are most, if not all, the benefits you will have. As you said, it is easy to implement navigation and menu inflating through Toolbar APIs. However, I don't see what you would gain by not calling setSupportActionBar().
YES YES YES
using setSupportToolBar() is the same old Actionbar the only reason ToolBar is ToolBar is for versatility,same as Fragments is to Views, all lies on how you implement stuff, and also the old Actionbar is kinda boring and much restricted as to Toolbar
I'm working on a project where I need to change the actionbar color within a single activity multiple times according to the content. This is done using
bar.setBackgroundDrawable(colorDrawable);
WITH this line, a portion of the actionbar turns transparent/grey (base theme is #style/Theme.AppCompat.Light.DarkActionBar) as soon as the navigation drawer is opened.
WITHOUT it, the background stays solid as expected even when the navigation drawer is opened. However, this does not allow for diffrent colored pages.
I'm using the support actionbar from appcompat 7, but it can be reproduced with a Toolbar as well as on multiple android versions.
Any ideas WHY this happens? Have I just messed up or is this in fact a bug?
Any workarounds, apart from setting a fixed color for the actionbar?
Note the right area of the actionbar that has become grey/transparent after opening the navigation drawer
I solved it. Kind of...
Please post other solutions if you can improve on this, as it is not the cleanest solution.
Changing the above mentioned
bar.setBackgroundDrawable(colorDrawable);
to
bar.setBackgroundDrawable(new ColorDrawable(((ColorDrawable) colorDrawable).getColor()));
solved the problem for me. This really should not have to be done though.
I am displaying ListView in Navigation Drawer. When Navigation Drawer is open and I press back hardware button then Navigation Drawer was not getting closed but the whole Activity got finished.
Interestingly instead of ListView when I directly used LinearLayout with Buttons, it was working fine. I checked out the Navigation Drawer sample provided by Android which uses ListView and surprisingly it works fine. After putting enough efforts, I identified that I was using Support Library V4 Revision 20 and the sample was using the old one, I still don't know the exact version of Support library used by sample.
Has anybody faced the same problem or know the solution to fix this problem? I have temporarily solved this problem by overriding onBackPressed() API of Activity and closing Navigation Drawer explicitly from there. But still curious to understand the problem.
I am working on an application, in which I need to implement navigation drawer. We have two different ways of implement navigation drawer in android as shown in attached screen shots :
In first way the sliding list is over main content. In second type, sliding list becomes visible and make main content to slide left to right with Navigation Drawer list.
I goggled a lot about this and only got solution of first type. I want to implement Navigation drawer like second type in attached screenshot. So please tell me what changes I need to make.
Thanks.
For the first case google's official Navigation Drawer is there.
And for the second case there's a third party library on github.
here's the link: https://github.com/jfeinstein10/SlidingMenu
Also I feel you've to use ActionBarSherlock (again a third party library) in order to implement the second case.
Moreover the google's drawer method is the recommended one as it supports a stable action bar, from where you can choose items even when the drawer is open. Also the design + app flow is slick and faster in this case as compared to the third party lib.
The SlidingMenu library is an excellent third party library and I've already used it for a long time. Now I know Android provides a new navigation pattern using Navigation Drawer. It looks like the sliding menu. So is there anyone who already uses these two both? What is the difference and what are the pros and cons? Thanks a lot.
SlidingMenu library is a third party api which uses a RelativeLayout inside. The main advantage is customization according to your requirement. Buy your layouts have to be based on a viewgroup, unfortunatly this negates the <merge> optimisations.
Navigation Drawer is available in the Support Library of android it uses DrawerLayout inside. The main advantage is improved performance.
They also have different visual effects. SlidingMenu looks like horizontal scroll view. Sliding it in will push the main content out.
Pros :
It comes with cool entrance / exit animations for the menu content.
Depending on what Activity you use it on, it can be placed below the Action Bar or next to it (pushing the Action Bar too)
You can explicitly set the touch mode via a setter: margin or full screen. In full screen mode touching anywhere on the screen will open the menu. In margin, only when you slide from the edge of screen will the menu open.
Cons :
You can only control the shadow of the side menu
Navigation Drawer / Drawer Layout looks like an additional top level view in a frame layout. Sliding it in will mask the main content.
Pros :
If you use v4 support lib then it's already there.
You can control both the side menu shadow and obscure the main
content via setScrimColor e.g when the drawer is opened, a fade-in
alpha layer will appear above the main content. This is good to visually separate the content and the menu especially when both have a same color.
Cons:
It can only be placed below ActionBar
There is no setter for touch mode and by default you can only do margin touch mode. Doing a full screen touch mode (like Youtube) involves a lot of work
I think the best advantage is that It is official Google code, I mean it just works and works excellent.
The main disadvantage is that it is very basic to use, I mean... you cannot put two navigation drawer in the same activity or fragment, you can only use one in left and that's it.
You already said it yourself. Sliding menu is third party. Navigation drawer is official. Both have the same purpose, but third party libraries might implementing it slightly differently, depending on which one you use.