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 回答