可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
I have been using ToolBar
since it was added into Support v7 library. And I think I used it well. But there is a point I can't understand. Why would Google create such a widget? I mean we can do anything ToolBar
can do by using ActionBar
. Why do we have to use ToolBar
? What are advantages of ToolBar
over ActionBar
if any? Is it necessary to replace ActionBar
by ToolBar
?
Any tips are appreciated. And thanks in advance.
PS: I found ToolBar
is a decandant of ViewGroup
. So, how could we use ToolBar
like a Layout
? Could somebody post some codes of that?
回答1:
Yes, you should replace ActionBar with new toolbar.
Reasons
It looks modern and it follows new material design.
Unlike Action bar, toolbar is not part of window decor. You define it and place it just like any other widget... therefore, you have freedom to place it anywhere in the parent layout.
You have freedom to put any widget inside toolbar.
You can define multiple toolbars.
EDIT
What i meant is you can place other widgets (views) inside toolbar.
Create a separate layout file for the toolbar (good for reusability). In my case file name is main_toolbar.xml
<?xml version="1.0" encoding="utf-8"?>
<android.support.v7.widget.Toolbar
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
xmlns:App="http://schemas.android.com/apk/res-auto"
xmlns:segmentedgroup="http://schemas.android.com/apk/res-auto"
android:id="@+id/toolbar"
android:layout_width="match_parent"
App:theme="@style/ToolbarColoredBackArrow"
android:layout_height="56dp"
android:background="@color/primary_color" >
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:textSize="@dimen/drawer_fntsize"
android:text="Title"
android:id="@+id/lbl_title"
android:textColor="@color/title_text_color"
android:layout_gravity="center" />
</android.support.v7.widget.Toolbar>
Then include this toolbar in your main layout like this
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<include
android:id="@+id/toolbar"
layout="@layout/main_toolbar" />
<FrameLayout
android:id="@+id/content_frame"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_below="@+id/toolbar" />
</RelativeLayout>
As you can see in this example i placed TextView inside the toolbar
回答2:
why Android would create such a widget?
Imagine, if you will, an Android tablet.
This tablet is running an app. That app has, in the lower-right corner of the screen, a rich text editor, where one can enter in some comments and format them with bold, italic, etc.
In a desktop or Web app, a typical approach for those formatting options, besides keyboard shortcuts, would be a toolbar, like the one you see above the answer text area here on Stack Overflow.
Prior to Toolbar
, Android developers had to either roll their own toolbar, or put the formatting actions in the action bar. While the latter approach is easy, it puts a strain on the user of the aforementioned fictional app, as the user has to keep switching her visual focus from the editor (bottom of screen) to the action bar (top of screen).
Why have we to use ToolBar?
You do not have to use Toolbar
. I have ~300 sample apps as part of my book, and at the moment, precisely zero of them use Toolbar
. I'll have to correct that at some point, as I have not yet written a chapter on Toolbar
.
Is it necessary to replace ActionBar by ToolBar?
No. There is a way to do this, but it is not necessary.
回答3:
Toolbar is much more flexible than standard ActionBar, you can add much more tools in a Toolbar (as it extends ViewGroup), and follow Material Design Guidelines.
For example, with a Toolbar, you can do the following :
A regular ActionBar isn't intended to be expanded this way.
Also, you can better manipulate Toolbar content as you can include it in your Activity layout xml file. Personally, I use a LinearLayout or a RelativeLayout with at the top, the Toolbar, and below, filling the leftover space, a FrameLayout where my Fragments will be added.
Finally, you can place your Toolbar anywhere you want as you set it in your layout file.
UPDATE:
Google released Android Design Support Library. The recommended way to get an extended Appbar is to wrap Toolbar
with AppBarLayout
, and add additional view such as TabLayout
in. To get a FAB over the Toolbar like in this screenshot, you can use CoordinatorLayout
to wrap your layout content, and then use anchor attributes on the FAB.
回答4:
A standard toolbar
is for use within application content.
A Toolbar
is a generalization of action bar
s 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.
Toolbar
supports a more focused feature set than ActionBar
. From start to end, a toolbar
may contain a combination of the following optional elements:
- A navigation button. This may be an
Up arrow
, navigation menu toggle,
close, collapse, done or another glyph of the app's choosing. This
button should always be used to access other navigational
destinations within the container of the Toolbar
and its signified
content or otherwise leave the current context signified by the
Toolbar
. The navigation button is vertically aligned within the
Toolbar
's minimum height, if set.
- A branded logo image. This may extend to the height of the bar and
can be arbitrarily wide.
- A title and subtitle. The title should be a signpost for the
Toolbar
's current position in the navigation hierarchy and the
content contained there. The subtitle
, if present should indicate any
extended information about the current content. If an app uses a logo
image
it should strongly consider omitting a title
and subtitle
.
- One or more custom views. The application may add arbitrary child
views to the
Toolbar
. They will appear at this position within the
layout. If a child view's Toolbar
.LayoutParams
indicates a Gravity
value of CENTER_HORIZONTAL
the view will attempt to center within the
available space remaining in the Toolbar
after all other elements
have been measured.
- An action menu. The
menu
of actions will pin to the end of the
Toolbar
offering a few frequent, important or typical actions along
with an optional overflow menu
for additional actions. Action
buttons
are vertically aligned within the Toolbar
's minimum height, if set.
In modern Android
UIs developers should lean more on a visually distinct color scheme for toolbars than on their application icon. The use of application icon plus title as a standard layout is discouraged on API 21 devices and newer.
回答5:
Why have we to use ToolBar
?
Toolbar is use for pre-devices and backport compatibility that the old support library does not provide. Remember ActionbarSherlock
, android made there own to support actionbar on low level API devices.
What are advantages of ToolBar
over ActionBar
if any?
You can easy add custom view with in the XML of toolbar like a relative layout view, specially a custom title and icons with animations. You have more control on your toolbar rather than the old conventional actionbar.
Is it necessary to replace ActionBar
by ToolBar
?
If you are going to support actionbar on devices lower than 2.0 then yes, you need a back-port compatibility for action bar.
回答6:
- You can easily customize toolbar.
- You can add many widgets inside toolbar.
- You can add many toolbar in your view.
- You have freedom to place it anywhere in the parent layout.
- They have own handling/managing of it child view.
回答7:
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. You can find more info here. We replaced our actionbar, as it was easier to customize toolbar for material design. Color palettes and disappearing animation behavior for example.
Personally, I don't understand why android throws away old controls and create new one. Another example would be RecyclerView. Don't understand why they just didn't improve old API.
回答8:
Note: Both will support general app navigation, icons and have backward support.
The answer depends on what user interaction(animating toolbar) your designs calls for. That being said you should implement animations on the toolbar to make it Material.
ActionBar:
If you simply want a static bar at the top that can host icons, back button and you can theme.
Toolbar:
If you want to do anything beyond a static bar such as animations.
A common implementation and Google design recommendation is to hide the toolbar when scrolling.
Material Design checklist: hiding app bar on scroll?
回答9:
Yes
The support Toolbar
gives you so much more flexibility and freedom, at practically no added extra cost, that there's no reason I can think of not to make the transition. Transitioning to the new Toolbar
is actually one of the first steps to porting existing apps to a more Material design, due to the simplicity of the task, and the immediate effect it has on the overall look and feel of the app.
回答10:
Here is the documentation link -- http://developer.android.com/training/appbar/setting-up.html
Note that it doesn't include the code where you include it in your other layout files:
<include
android:id="@+id/toolbar"
layout="@layout/tool_bar"/>
Why I changed to Toolbar -- One of the reasons I changed a recent app to Toolbar was that when we wanted to customise the action bar, it wouldn't work on different Android versions or when we extended certain classes (making it transparent or showing an icon instead of the app name). Toolbars have allowed us the customisation options we want.