内容提供商:用静态外观包装?

时间:2011-03-17 15:25:25

标签: android architecture android-contentprovider

我正在经历一些设计困境,我一直瞄准Android 2.3.3并且有一个ContentProvider的自定义实现。然后,我有一类静态方法来抽象内容提供程序 - 根据我的查询向我提供表示每个实体(行)的对象。有一段时间我很喜欢这样的工作,直到我开始想要在很多地方使用整个系列,进行“命中测试”和绘制到屏幕上。然后我头疼的是保持我的对象表示是最新的,并且在这一点上已经决定我需要退后一步并重新考虑在哪里采取这个。

正如我所说,我目前正在使用2.3.3,并意识到在3.0中CursorLoader克服了我遇到的很多问题。我仍然需要支持智能手机,所以除非有后退,否则我不能这样做。

作为一个临时解决方案,我开始注册notifyChange监听器,这样我就可以使用原始查询重建一个集合,但这会让我感到非常耗费CPU并且可能很慢。我还没有决定是否应该使用我的静态外观回滚,而是使用Activity中现在过时的managedQuery调用。

因此我有两个问题:

1)是否有一种可取的方法来避免基于contentProvider处理集合的问题?

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

1 个答案:

答案 0 :(得分:1)

好的,我做出了决定,而且工作正常。

  

1)有没有更好的方法可以避免   反对的问题   基于a的集合   的ContentProvider?

我已经决定采取的方法是正确的;在我的情况下,最好是创建一个缓存而不是维护一个光标(托管或不托管)到ContentProvider;这允许我重用方法并减少需要测试的代码量。 NotifyChange监听器在使用3.0+之前很重要,这意味着我应该保证调用NotifyChange - 另一个用于集中所有代码的参数,以便它确实在预期时触发更改。

  

2)你有任何关于工作的建议   活动中的原始游标?我是不是该   从他们那里制造物品   按原样使用光标?一世   当然觉得他们应该在一个   执行查询时AsyncTask,   但之后我可以使用它们   任何地方?

在我的用例中,我已经决定考虑我打算创建什么 - 避免不必要的工作,关于返回不必要的行和&字段并可能创建不必要的对象。如果我想创建一个条目名称和条目ID的地图,那么我也不应该获得所有其他字段。从集合中抽象是好的,但它必须是轻量级的,并考虑如何使用数据 - 无论是一次性还是可以反复使用。重要的是它是为了性能而不是完整性而编写的。