android - 为什么加载器在 Android 中不好用

Question

我在这里和那里阅读了一些关于装载机不好的推文和评论，使用它们是“打自己脸”的好方法。 commonsguy 还宣布他将停止在他的库中的任何工作:Loaderex。 Commonsguy 还说“加载器是一个失败的抽象”。

我显然在这里遗漏了一些东西，我想了解更多信息并了解为什么加载器不好以及为什么要避免它们。

注意:我创建了一个 Android 应用程序(可能是中等复杂度)，我在其中使用了 Loaders，并且在使用 Loaders 时没有遇到任何问题。这就是为什么它让我感到困惑。

我还想了解其他更好的加载器替代品。提前致谢

Answer 1

why are Loaders bad and why should one avoid them

你会注意到这不是我说的。我说加载器是一个失败的抽象。有区别。

在尝试创建可重用的框架时，一般建议是设计和创建框架的三个离散实现。如果您的框架可以支持三种不同的方法，则该设计可能足够灵活，可以处理 future 的实现。

Loader归根结底，框架是围绕一种实现设计的:CursorLoader .时期。 Loader 没有其他具体实现在 SDK 中。特别是 Loader框架有一个合约，要求 Loader 的实现能够自动提供更新的结果。虽然从Loader 的用户 的角度来看，这是一份不错的契约(Contract)。框架，它使那些可能创建 Loader 的实现的人变得困难。框架。

我试图创建两个单独的 Loader 实现。框架，用于 SQLite 和 SharedPreferences (如果您单独计算适用于 Android 的 SQLCipher，则为三个)。 SQLite 很烂，因为自动重新加载的唯一方法是使用 Loader要知道需要重新加载什么，这很笨重。 SharedPreferences一个曾经工作，但有人指出，现在onLoadFinished()如果表示结果的对象(Cursor 的 CursorLoader ，SharedPreferences 的 SharedPreferencesLoader )与以前的对象相同，则不会被调用。这打破了SharedPreferencesLoader , 因为 SharedPreferences当偏好改变时，对象会原地更新。

写完我的Loader实现并使用它们一段时间，我得出结论认为它们不值得。我宁愿自己使用 AsyncTask 异步加载东西或 IntentService并使用消息总线(Otto、greenrobot 的 EventBus 等)通知相关方数据的变化。虽然我可以将这些东西包裹在 Loader 中，我不相信它会解决足够多的值得努力的问题。

现在，如果您使用的是 ContentProvider并希望使用 CursorLoader ， 没关系。它可能有其自身的问题，但至少它应该可以工作。

关于 CWAC-LoaderEx 库，我将停止使用它，因为:

• 我一天只有这么多小时，因此作为 CWAC 库的 AAR 化的一部分，我正在决定哪些库值得努力维护

• 我个人不使用 CWAC-LoaderEx，除了几个书本示例

• CWAC-LoaderEx 依赖于过多的 Loader 内部实现让我感到很自在，我将能够让它长期工作(见 SharedPreferencesLoader)

CWAC-LoaderEx 不会去任何地方，但我不会花更多时间在它上面。如果有人拥有维护/扩展的 fork 与我联系，我很乐意从项目 README 链接到他们的 fork 。

I would also like to know about other better alternatives to Loaders

全部是 Loader所做的是异步加载内容，在检测到内容更改时重新加载该内容，并在配置更改期间保留所述内容。保留的模型(或 headless ) fragment 可以做同样的事情，与 AsyncTask 一致。 .