ActionBarSherlock：通过方法调用以编程方式显示/隐藏操作项按钮答案

【问题标题】：ActionBarSherlock: Programmatically show / hide Action Item buttons via a method callActionBarSherlock：通过方法调用以编程方式显示/隐藏操作项按钮
【发布时间】：2012-07-22 19:05:01
【问题描述】：

我正在使用 ActionBarSherlock。我希望能够在操作栏中显示两个按钮以响应某个用户操作。用户操作与 Action Bar 完全无关。按钮的可见性需要通过调用方法来控制。此外，对单击这些按钮的响应应由我自己的应用程序代码处理。

理想情况下，按钮应该看起来就像使用android:showAsAction="ifRoom|withText" 将菜单项定义为操作项时创建的按钮一样，如图here 所示。

我的问题是，据我所知，标准的ActionBar API 没有提供这样的机制来随意显示或隐藏操作项按钮，并且唯一可以定义菜单项的时间是在onCreateOptionsMenu() 内这当然是由系统调用的。

我的信念是，我要添加这样的按钮并随意显示/隐藏它们的唯一方法是为它们创建自定义布局并利用.setCustomView() 将它们放置到操作栏中。人们普遍同意这一点，还是我遗漏了什么？

如果我确实使用.setCustomView()，我希望我的按钮看起来与ActionBarSherlock 为具有android:showAsAction="ifRoom|withText" 属性的菜单项显示的操作项按钮相同。为此，谁能告诉我我应该使用 ActionBarSherlock 库中的哪些特定主题、样式或布局？我已经尝试过使用R.layout.abs__action_menu_item_layout，但尝试膨胀此布局会在尝试膨胀布局包含的CapitalizingButton 时产生与colorStateList 相关的异常。

【问题讨论】：

标签： android android-actionbar actionbarsherlock

【解决方案1】：

您可以在MenuItem 实例上调用setVisibility。

documentation states 表示“您可以安全地保留菜单（以及从中创建的任何项目），根据需要对其进行修改，直到下次调用 onCreateOptionsMenu()。”

【讨论】：

谢谢，杰克（非常感谢 ABS - 虽然你现在可能已经厌倦了感谢它 :-)）。正如我对 MH 评论的那样，一个问题是我想强制文本标签始终显示。这是我可能只需要应用自定义视图的原因之一，但我会先尝试其中的一些建议。

【解决方案2】：

如果您希望这两个按钮具有菜单项的外观和感觉，那么您应该将它们设为菜单项。您认为菜单项只能在 onCreateOptionsMenu() 中定义的假设是不正确的，因为还有一个名为 onPrepareOptionsMenu() 的方法，每次在菜单显示之前都会调用该方法。结合活动的invalidateOptionsMenu() 方法，您可以轻松地创建一个实时反映当前状态的菜单数据。

另一种方法是保留对单个 MenuItem 对象的引用，因为文档说明它的保存以保留这些对象，并在适当时更改它们的可见性。您可能仍然需要致电invalidateOptionsMenu() 来更新菜单——我记不得了。（编辑： Jake 在这一点上击败了我）

就个人而言，我更喜欢第一种方法，因为您将所有与菜单相关的逻辑分组在一起，并且可见性基于某种状态/模型。第二个选项可能更容易实现，具体取决于您当前的代码，但可能会导致到处都是菜单。

【讨论】：

谢谢，MH。这里有几个我很感激的想法。还有一个问题让我想知道我是否还需要求助于.setCustomView()。问题是我希望文本标签始终显示，而不仅仅是图标。在我的 HTC One X 上，除了溢出图标和单个操作项之外，ABS 上什么都没有，操作项的文本标签仅以横向显示，即使在任一方向都有足够的空间。我意识到操作栏根据屏幕密度和栏宽应用逻辑来确定标签是否可见。我会对此进行更多调查。
Juse 使用您提供的建议在 Fragments 中重写了我的 MenuItem 逻辑 - 现在工作得更好。任何人都走这条路-一定要 setHasMenuOptions(true) 走@MH的路。建议（我同时做 onPrepareOptionsMenu 并保持对 MenuItem 对象的引用）。
“就个人而言，我更喜欢第一种方法，因为您将所有与菜单相关的逻辑组合在一起，并且可见性基于某种状态/模型。”是的，与其他一切一起，一起在上帝对象中，称为 Activity。而上帝对象是一种反模式。
@MiklosJakab：我真诚地怀疑这是对 Android 团队选择的模式发表意见的正确地方。无论如何，无论您选择哪种方法，菜单的生命周期都与其托管 Activity 的生命周期密切相关。显然，您可以从某种程度上抽象出来，但归根结底，这种关系只是框架的设置方式。所有模式总是有利有弊，并且对它们有更多不同的开放。这让我回到我最初的评论：这个 Q&A 可能不是那个讨论的正确地方。 :)
@MH：即使是谷歌也选择了其他模式，不一定好。正如您所说，“可以在某种程度上抽象”。它相信推动对不同设计模式的关注是常识发展的重要组成部分。我不希望遇到完全错误的代码（我并不是说上述代码完全错误），但是阅读这篇文章的人越多，我就越有可能。所以在这里展示其他意见就足够了。

【解决方案3】：

您检查过演示样本吗？

他们在“功能切换”上有这个功能。

【讨论】：