Action Bar를 ToolBar로 대체해야합니까?

Action Bar를 ToolBar로 대체해야합니까?

---

지원 v7 라이브러리ToolBar 에 추가 된 이후 로 사용 하고 있습니다 . 그리고 잘 사용했다고 생각합니다. 하지만 이해할 수없는 점이 있습니다. Google은 왜 그런 위젯을 만들까요? ToolBar을 사용하여 무엇이든 할 수 있습니다 ActionBar. 왜 우리는 사용해야 ToolBar합니까? ToolBarover의 장점은 무엇입니까 ActionBar? 그것은 교체 할 필요가 ActionBar에 의해 ToolBar?

모든 팁을 주셔서 감사합니다. 그리고 미리 감사드립니다.

추신 : 나는 발견 ToolBar의 decandant입니다 ViewGroup. 그래서 우리는 어떻게 ToolBar처럼 사용할 수 Layout있습니까? 누군가 그 코드를 게시 할 수 있습니까?

---

예, ActionBar를 새 도구 모음으로 바꿔야합니다.

원인

1. 현대적으로 보이며 새로운 소재 디자인을 따릅니다.

2. 작업 표시 줄과 달리 도구 모음은 창 장식의 일부가 아닙니다. 당신은 그것을 정의하고 다른 위젯과 마찬가지로 배치합니다. 따라서 부모 레이아웃의 어느 곳에 나 배치 할 수 있습니다.

3. 툴바 안에 위젯을 자유롭게 넣을 수 있습니다.

4. 여러 도구 모음을 정의 할 수 있습니다.

편집하다

내가 의미하는 바는 툴바 안에 다른 위젯 (보기)을 배치 할 수 있다는 것입니다.

도구 모음에 대해 별도의 레이아웃 파일을 만듭니다 (재사용에 적합). 제 경우 파일 이름은 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>

그런 다음 다음과 같이 기본 레이아웃에이 도구 모음을 포함합니다.

<?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>

이 예제에서 볼 수 있듯이 툴바 안에 TextView를 배치했습니다.

---

Android가 왜 그런 위젯을 만들까요?

원한다면 Android 태블릿을 상상해보십시오.

이 태블릿은 앱을 실행 중입니다. 이 앱에는 화면 오른쪽 하단에 서식있는 텍스트 편집기가 있으며, 여기에서 주석을 입력하고 굵게 , 기울임 꼴 등 으로 서식을 지정할 수 있습니다 .

데스크톱 또는 웹 앱에서 이러한 서식 옵션에 대한 일반적인 접근 방식은 바로 가기 키 외에 여기 Stack Overflow의 답변 텍스트 영역 위에 표시되는 도구 모음과 같습니다.

이전에 ToolbarAndroid 개발자는 자신의 툴바를 굴 리거나 작업 표시 줄에 서식 지정 작업을 배치해야했습니다. 후자의 접근 방식은 쉽지만, 사용자가 편집기 (화면 하단)에서 작업 표시 줄 (화면 상단)로 시각적 초점을 계속 전환해야하기 때문에 앞서 언급 한 가상 앱 사용자에게 부담을줍니다.

ToolBar를 사용해야하는 이유는 무엇입니까?

를 사용할 필요가 없습니다 Toolbar. 내가 가진 ~ 300 샘플 애플리케이션을 의 일환으로 내 책 , 그리고 순간에, 그들의 정확하게 제로 사용 Toolbar. 에 대한 장을 아직 작성하지 않았기 때문에 어느 시점에서 수정해야 할 것입니다 Toolbar.

ActionBar를 ToolBar로 대체해야합니까?

아니요. 이렇게하는 방법이 있지만 반드시 필요한 것은 아닙니다.

---

툴바는 표준 ActionBar보다 훨씬 더 유연하며, 툴바에 더 많은 도구를 추가 할 수 있으며 (ViewGroup을 확장하므로) 머티리얼 디자인 지침을 따릅니다.

예를 들어 툴바를 사용하면 다음을 수행 할 수 있습니다.

일반 ActionBar는 이러한 방식으로 확장 할 수 없습니다.

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.

---

A standard toolbar is for use within application content.

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.

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.

---

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.

---

1. You can easily customize toolbar.
2. You can add many widgets inside toolbar.
3. You can add many toolbar in your view.
4. You have freedom to place it anywhere in the parent layout.
5. They have own handling/managing of it child view.

---

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.

---

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?

---

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.

---

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"/>

툴바로 변경 한 이유-최근 앱을 툴바로 변경 한 이유 중 하나는 작업 표시 줄을 맞춤 설정하려고 할 때 다른 Android 버전에서 작동하지 않거나 특정 클래스를 확장했을 때 (투명하게 만들거나 앱 이름 대신 아이콘). 툴바는 우리가 원하는 사용자 정의 옵션을 허용했습니다.

참조 URL : https://stackoverflow.com/questions/29813474/should-we-replace-action-bar-by-toolbar