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
Related
If there is a toolbar, it is usually passed into setSupportActionBar(). Why?
As per docs
A Toolbar is a generalization of action bars for use within application layouts. While an action bar is traditionally part of an Activity's opaque window decor controlled by the framework, a Toolbar may be placed at any arbitrary level of nesting within a view hierarchy. An application may choose to designate a Toolbar as the action bar for an Activity using the setActionBar() method.
But in simple ways, this is a way of telling the Activity that you are interested in using the features related to Toolbar. It will delegate the functionalities related to your defined toolbar. It helps activity to understand the many of the requirements some of them mentioned below.
1) Setting menu options
2) Setting Navigation drawer
3) Setting common Toolbar
4) Setting back button on the top left
5) Using an icon for brand identification
6) Setting a common title or subtitle
7) And many more
If you don't mention for these functionalities by telling the activity using setSupportActionBar then you have to create all this by your self and support them back to the older version. With Toolbar it comes free and you have to just tell a activity to use it will take of supporting different functionalities itself.
if you want to apply your custom toolbar instead of default toolbar then to set toolbar into that specific screen/activity you must be use setSupportActionBar() along with your toolbar. ;)
I have a project using Drawer and Swipe tabs that I created using this tutorial. I'm using the support library to make Material Design available for older android versions. I'm also using ToolBar instead of ActionBar. I have a menu attatched to that ToolBar:
toolbar = (android.support.v7.widget.Toolbar) findViewById(R.id.toolbar);
toolbar.inflateMenu(R.menu.menu_main);
What I'm struggling with is having specific menus for each fragment. I tried many answers to other similar questions, like this and this to no avail. Most people are suggesting the implementation of these methods but they only seem to work for ActionBar and in my case I have a android.support.v7.widget.Toolbar.
I also tried using
toolbar.getMenu().findItem(R.id.menuitem).setVisible(false);
supportInvalidateOptionsMenu();
But it also does not work. In this case, my menu just disappears.
I've been searching and struggling with this for weeks to to avail. Am I doing something wrong?
How can I have specific menus for each fragment? I think that hiding menu items may be the easier choice to achieve that, but if you guys have any other way of accomplishing that, I would be grateful.
You should call setSupportActionBar(toolbar) when you setup your Toolbar (probably in onCreate) and inflate your menu as usual in onCreateOptionsMenu(Menu menu) method.
In this method you can handle the different Menus, whether it's by hiding the items or just inflating a different menu based on the fragment.
Then, as you said, call supportInvalidateOptionsMenu(); when you change between fragments to recreate the Menu.
I've been reading/youtubing a lot about how I should start my next app and found out that the activities suggested as start activities in Android Studio may contain deprecated elements such as the ActionBar, and that I should rather start from scratch without an activity, and use the newly lollipop-introduced "Toolbar".
My question is: As I need a top bar of a kind (ActionBar/Toolbar) and a navigation drawer in my app, should I invest the time it needs to build the Toolbar opposed to starting with a NavigationDrawer activity from the beggining?
Will using an NavigationDrawer activity (with an ActionBar) mean that I'm staring a new app with old-fashioned kind of top bar?
Very first thing ActionBar is not deprecated and not old style component. It still serves the purpose well. Toolbar only comes into existence when you need more than ActionBar, for instance, you want to increase the height of ActionBar and want to inflate some custom views then ActionBar might not be a right choice. If you just need an Activity with NavigationDrawer, I don't think so you need a ToolBar at all. Just create a new project from scratch and pick NavigationDrawer as a pre-configured option while creating the project and you are good to go. ActionBar is not going anywhere, at least for now. Hope it would help.
After Google introduced Material Design, I have heard about a new widget class called Toolbar.
What is the Toolbar, and what is the exact difference between ActionBar and ToolBar?
I found a good explanation from Android Developers Blog post.
In this release, Android introduces a new Toolbar widget. This is a generalization of the Action Bar pattern that gives you much more control and flexibility. Toolbar is a view in your hierarchy just like any other, making it easier to interleave with the rest of your views, animate it, and react to scroll events. You can also set it as your Activity’s action bar, meaning that your standard options menu actions will be display within it.
Yes, we, Android developers, needed more control over ActionBar, right? And Toolbar is just for it.
In other words, the ActionBar now became a special kind of Toolbar. This is an excerpt from Google's official Material Design spec document.
The app bar, formerly known as the action bar in Android, is a special kind of toolbar that’s used for branding, navigation, search, and actions.
More details like how to use Toolbar as an ActionBar are included in above blog post.
How can i archive a Tab layout like this in Android ? The Tab Navigation is part of that
Main ActionBar and is not below. PS: Im using ActionBar Sherlock
At the moment is just do:
actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS);
But i want a look like this:
Thanks for help,
Kitesurfer
I don't recommend doing this but you could override the ActionBar and ABS styles:
<bool name="abs__action_bar_embed_tabs">false</bool> //for ActionBarSherlock
<bool name="action_bar_embed_tabs">false</bool> //for default ActionBar
Tab will be displayed in actions bar but only if action bar has space. When you are in landscape mode your tabs will move to action bar because in landscape mode action bar has more room.
From this thread. On the topic of overriding the Action Bar tab functionality.
Jake Wharton
I am obligated to tell you this is probably a Bad Idea™ and I don't recommend it. When you fight the platform you almost always end up losing.
I am inclined to agree about fighting the platform. Instead I opted to abandon the stock tab navigation (from both the android platform and ABS library) and instead wrote a layout that looks basically the same as the tabs, and used it as a custom view, applying it using ActionBar.setCustomView(View) and ActionBar.setDisplayShowCustomEnabled(true) methods.
This uses the ActionBar api in the standard way (ie. Not fighting the platform) and, as is pointed out in that thread, the tab view is simply a LinearLayout.
Try this. This implements a method that will let you select whether you want the tabs in a separate row or in the top row, regardless of screen orientation.
For those who are using this code with the native ActionBar, simply omit the if (actionBar instanceof ActionBarWrapper) and the block underneath it.
Bear in mind, though, that this is somewhat of a hack and might break in future Android versions.