I have a custom video player,when user enters into fullscreen i am hiding actionbar but due to its animations its being delayed.
how to avoid it in normal ActionBar or SherlockActionBar ?
I recommend to make use of Material Design with the new support library. By doing so you can replace your ActionBar with a Toolbar which gives you a lot more control. By using the Toolbar you can achieve your goal with the setVisibility() method.
Related
I am newbie in android app developing and learning android UI design.I am trying to make a toolbar like below image.But i don't now what is the xml code for below image toolbar.
Two options. Personally I'd go for the first.
Overriding the view
First approach is overriding the default toolbar / action bar. This has the advantage of being able to use AndroidX navigation, automatic back stack navigation, etc, with the disadvantage of a bit less control.
All you need to do is enable custom views on your action bar, apply a custom view, hide the default title, then set the elevation to 0 so there's no shadow. This will be something like:
ActionBar actionBar = getSupportActionBar();
actionBar.setDisplayShowCustomEnabled(true);
actionBar.setCustomView(R.layout.your_custom_layout);
actionBar.setDisplayShowTitleEnabled(false);
actionBar.elevation = 0f;
R.layout.your_custom_layout can then be whatever layout you want, so long as it fits in the same space. I've written a full tutorial on this previously, as well as a sample project in Kotlin.
Defining your own
The second approach is ignoring the built in toolbar / action bar, and just rolling your own. This gives you full control, and allows setting the bar to any height, but you lose all built in functionality. For this, just use themes without a toolbar, and draw your own bar (perhaps in an activity that then swaps in fragments).
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
When I tried to use ActionBar and specify the navigationMode eclipse says it is deprecated without suggesting the recommende one to use instead.
what should i use instead of this.actionBar.setNavigationMode(mode)?
There is no alternate method to use from the now deprecated setNavigationMode since the Toolbar is basically a stripped down version of the actionbar where you put in the views you want inside the toolbar.
for example if you wanted to replicate the Dropdown navigation mode you would put a spinner inside your toolbar
I know that I could hide and show ABS like:
getSupportActionBar().hide();
getSupportActionBar().show();
However this makes it hide and show with animation and I don't like it. I need it to hide and show immediately like if set visibility property to its view (View.VISIBLE/View.GONE/View.INVISIBLE). How could I achieve that? Or is there a way to hide()/show() without animation (show()/hide() doesn't accept any parameters)? Or is there a way to get ABS view so I could use setVisibility() on it?
No, you can not disable Actionbar show/hide animation.
Up to project requirements there should not be an ActionBar in the application, but I need to to use Navigation Drawer. Is it possible to use it without ActionBar?
yes it should be possible. Programmatically call getSupportActionBar().hide()