2

如您所知，Action Bar Sherlock 虽然是一个整洁的库，但有两到三个非常具有侵入性的元素：

  1. 它迫使您从 SherlockFragments 和 SherlockActivities 继承您的片段和活动。这是一个稀疏资源，您不能将其用于另一个可能需要您执行相同操作的方便库。幸运的是，compat 库不是其中之一（实际上它是，但 Sherlock 建立在它之上）。

  2. 它使用一个 Android 库项目。由于这些工具还不能称为非常稳定，因此您可能会很快遇到问题。事实上，我遇到了 Eclipse 错误。

  3. 它是另一个使 Proguard 的工作更加困难并增加您的 apk 大小的库。Apk 大小对于某些用户来说仍然是一个巨大的限制，其中包括 Google TV 用户。

因此，如果我选择使用 Action Bar Sherlock，我会排除哪些其他可能的（未来）库，包括 3rd 方库？我还缺少任何其他限制吗？

4

2 回答 2

1

  1. 正如@Jake Wharton 本人指出的那样，这不是真的。使用现有代码和示例，它是创建自定义 ABS 活动和片段的简单且相当快速的实现。

  2. 我广泛使用图书馆项目，包括有深入多个层次的图书馆项目参考。我遇到了一些问题，但没有什么是破坏交易的。Eclipse 有时在重建时会感到困惑，但通常清理所有项目可以让一切都整理好。图书馆项目一直在变得越来越稳定。

  3. 这实际上是两点，但具有相似的主题——对于任何库，而不仅仅是 ABS，您必须权衡从包含库的功能中获得的价值与这样做的成本。我觉得现在界面的价值值得付出额外的努力和 apk 大小。这是一个价值决策，需要在每个应用程序的基础上做出。

@Ahmad 是正确的，ABS 显然对 3rd 方库没有限制。集成可能需要一些编码，但它们应该一起工作。此外，ABS 的使用在未来会自然消退。它是一个兼容性库，因此随着设备分发越来越多地转移到 Android 3+ 设备，在 2.X 设备上支持操作栏 UI 的需求将不再是问题。

于 2012-12-24T02:50:38.943 回答
1

因此，如果我选择使用 Action Bar Sherlock，我会排除哪些其他可能的（未来）库，包括 3rd 方库？我还缺少任何其他限制吗？

坦白说，我什么都不知道。大多数使用自定义实现的库Activity（比如 ActionBarSherlock 也在做）很可能会扩展SherlockActivity（因为几乎每个人都使用 ABS），或者如果没有，那么你可以自己修改它。所以不，据我所知，不会有任何限制。

于 2012-12-24T01:14:33.763 回答