内容提供者：用静态外观包装？

Question

我遇到了一些设计难题，我一直以 Android 2.3.3 为目标，并且有一个 ContentProvider 的自定义实现。然后我有一类静态方法来抽象内容提供者——根据我的查询为我提供代表每个实体（行）的对象。有一段时间我对这样的工作感到非常自在，直到我开始想在许多地方使用整个集合，以执行“命中测试”并在屏幕上绘图。然后，我为保持我的对象表示是最新的而头疼，此时我决定我需要退后一步，重新考虑把它放在哪里。

正如我所说，我目前正在使用 2.3.3，并意识到在 3.0 中 CursorLoader 克服了我遇到的许多问题。不过，我仍然需要支持智能手机，所以除非有向后移植，否则我无法做到这一点。

作为临时解决方案，我开始注册 notifyChange 侦听器，以便我可以使用原始查询重建集合，但这让我觉得 CPU 非常密集并且可能很慢。我还没有决定是否应该回滚使用我的静态外观，而是使用来自 Activity 的现已过时的 managedQuery 调用。

因此我有两个问题：

1) 是否有更好的方法来避免处理基于 contentProvider 的集合时出现的问题？

2) 您对在活动中使用原始光标有什么建议吗？我应该用它们制作对象还是按原样使用光标？我当然觉得它们在执行查询时应该在 AsynTask 中，但之后我可以在任何地方使用它们吗？

Answer 1

好的，我做出了一个决定，它运行可靠。

1) 有没有更好的方法来避免 反对工作的问题 基于一个集合 内容提供者？

我认为我采取的方法是正确的；在我的情况下，最好对 ContentProvider 进行缓存而不是维护游标（管理或不管理）；这使我可以重用方法并减少需要测试的代码量。在使用 3.0+ 之前，NotifyChange 侦听器很重要，这意味着我应该保证调用 NotifyChange - 集中所有这些代码的另一个参数，以便它确实在预期时触发更改。

2) 您对合作有什么建议吗？ 活动中的原始光标？我是不是该 用它们制作物品或 按原样使用光标？我 当然觉得他们应该在 AsyncTask 在执行查询时， 但在那之后我可以使用它们吗 在哪里？

在我的用例中，我决定考虑一下我打算创建什么 - 避免不必要的工作，例如返回不必要的行和字段以及可能创建不必要的对象。如果我希望创建条目名称和条目 ID 的映射，那么我也不应该获取所有其他字段。从集合中提取是好的，但它必须是轻量级的，并考虑到数据的使用方式——无论是一次性的还是可以重复使用的。重要的是，它是为性能而非完整性而编写的。