我已经阅读过几条推文和评论，关于装载机坏了并使用它们是一种“射击自己”的好方法。此外 commonsguy 宣布他将停止对其图书馆的任何工作： Loaderex 。 Commonsguy 也说“装载机是一个失败的抽象”。
我显然在这里遗漏了一些东西，我想了解更多，并了解为什么装载机坏了，为什么要避免它们。
注意：我已经创建了一个Android应用程序（可能是中等复杂度），我使用Loaders并且没有任何加载器的麻烦。这就是为什么它让我感到困惑。
我还想了解其他更好的 替代 加载程序。提前致谢
答案 0 :(得分：28)
为什么装载机坏了，为什么要避免它们
你会注意到这不是我所说的。我说加载器是一个失败的抽象。有区别。
在尝试创建重要重用框架时，一般建议是设计和创建框架的三个独立实现。如果您的框架可以支持三种不同的方法，那么设计可能足够灵活，可以处理未来的实现。
Loader框架在一天结束时围绕一个实现设计：CursorLoader。期。 SDK中没有Loader的其他具体实现。特别是，Loader框架的合同要求Loader的实施能够自动提供更新的结果。虽然从Loader框架的用户的角度来看，这是一个可爱的合同，但对于那些可能创建{{1>} {em>实现的人来说却很困难。 } framework。
我尝试为SQLite和Loader创建Loader框架的两个单独实现（如果您分别计算Android的SQLCipher，则为三个）。 SQLite很糟糕，因为执行自动重载的唯一方法是让SharedPreferences知道需要重新加载什么，这很笨重。曾经工作的Loader，但有人指出，如果表示结果的对象（SharedPreferences，onLoadFinished()，Cursor，CursorLoader将不会被调用1}} for SharedPreferences）是与以前相同的对象。这会中断SharedPreferencesLoader，因为当更改首选项时，SharedPreferencesLoader对象会在原地更新 。
在编写了我的SharedPreferences实现并稍稍使用它之后，我得出结论认为它们不值得。我宁愿使用Loader或AsyncTask异步加载内容，并使用消息总线（Otto，greenrobot的EventBus等）通知感兴趣的各方数据的变化。虽然我可能将这些内容包装在IntentService内，但我不相信它会解决足够的问题值得付出努力。
现在，如果您使用Loader并希望使用ContentProvider，那很好。它可能有自己的问题，但至少它应该有效。
关于CWAC-LoaderEx库，我暂停了它，因为：
我一天只有这么多小时，所以作为CWAC图书馆伟大的AAR化的一部分，我决定哪些图书馆值得努力维护
除了几本书中的例子，我不会亲自使用CWAC-LoaderEx
CWAC-LoaderEx取决于CursorLoader的过多内部实施让我感到舒服，我将能够长期保持工作（见Loader）
CWAC-LoaderEx不会去任何地方，但我不会花更多的时间。如果有维护/扩展分叉的人与我联系，我很乐意从项目README链接到他们的分支。
我还想了解其他更好的装载机替代方案
所有SharedPreferencesLoader都会异步加载内容，在检测到内容发生更改时重新加载该内容，并在配置更改中保留所述内容。保留的模型（或无头）片段可以与Loader一起执行相同的操作。