是否不再需要setSupportActionbar?

问题描述

引入了新的工具栏小工具，它是AppCompat(android.support.v7.widget.Toolbar)版本可用，是否需要再调用setSupportActionbar(toolbar)?或调用setSupportActionbar有什么好处；现在，我们可以设置标题，副标题，导航图标，导航图标单击侦听器( getSupportActionBar().setDisplayHomeAsUpEnabled(true)替换)，菜单，菜单单击侦听器( options-menu替换).

With the new Toolbar widget introduced and it's AppCompat (android.support.v7.widget.Toolbar) version available, is it required to call setSupportActionbar(toolbar) anymore? Or is there any advantage of calling setSupportActionbar; as now we can set title, sub-title, navigation-icon, navigation-icon-click-listener (getSupportActionBar().setDisplayHomeAsUpEnabled(true) replacement), menu, menu-click-listener (options-menu replacement) etc directly on the toolbar without ever calling setSupportActionbar.

推荐答案

但是 setSupportActionbar()方法和 ActionBar API仍然记录的方式实现应用栏，它看起来像是使用工具栏，其中包含开发人员熟悉的API.实际上，ActionBar API仅使事情复杂化，请查看本文作为示例.

However setSupportActionbar() method and ActionBar API remains the documented way of implementing an app bar, it looks rather as a way to use Toolbar with the familiar API that developers are used to. In reality ActionBar API only complicates things often, take a look at this article for an example.

现在，当单个活动架构和导航组件是建议的实现Android应用程序的方法，设置片段工具栏很简单使用 NavigationUI 库，例如:

Nowadays, when a single activity architecture and navigation component are recommended ways of implementing Android applications, it's very easy to setup a fragment toolbar using NavigationUI library, for example:

<!-- my_fragment.xml -->
<androidx.constraintlayout.widget.ConstraintLayout ...>

  <com.google.android.material.appbar.MaterialToolbar
    ...
    android:id="@+id/toolbar"
    app:menu="@menu/my_menu" />

</androidx.constraintlayout.widget.ConstraintLayout>

class MyFragment : Fragment() {
  ...

  override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)

    val navController = findNavController()
    binding.toolbar.setupWithNavController(navController)
    binding.toolbar.setOnMenuItemClickListener { ... }
  }
}

就这么简单，结果您将获得一个带有自动设置标题，后退按钮和选项菜单的工具栏.此处，您可以找到完整的GitHub示例，该示例演示了最小的工具栏设置使用NavigationUI.

It's really that simple, as a result you'll get a toolbar with an auto set title, working back button and options menu. Here you can find the full GitHub sample which demonstrates a minimal Toolbar setup using NavigationUI.

那么，使用ActionBar API根本没有优势吗?也许我错了，但是唯一有用的情况就是一个 appwide 工具栏.在这种情况下，您可以将工具栏放入活动中，并在每个片段中进行不同的设置，例如，通过覆盖 onCreateOptionsMenu().但是根据我的经验，每个片段之间的工具栏往往会有很大的不同，因此每个片段都有一个单独的工具栏更加容易，有关选择的信息，请参见此主题.您还可以查看导航组件文档:支持应用栏的变化.

So, there's no advantages of using ActionBar API at all? Maybe I'm wrong, but the only situation I see it useful is a single app wide toolbar. In this case you can put a toolbar into your activity and setup it differently in each fragment, for example by overriding onCreateOptionsMenu(). But by my experience toolbars tend to vary significantly between fragments so it's easier to have a separate toolbar for each fragment, the choice is discussed in this thread. You can also take a look at the navigation component documentation: Support app bar variations.

这篇关于是否不再需要setSupportActionbar?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！