我很难在Android上优化SQLite数据库处理的向后兼容性，复杂性和最佳实践。我发现了两种不被弃用的方法来管理SQLite数据库和游标：
android.database.sqlite ContentProvider，CursorLoader和LoaderManager 我正在尝试设计数据库实现的未来证明。这意味着我想实施Google推广的最佳实践。关于实施ContentProvider和LoaderManager的{{3}}。
如果我遵循Lars Vogels提案，我的代码会被重复和不必要的复杂性所淹没。它对我的数据库中的某些表有意义。但是对于具有三个字段的映射表（例如）来实现它是没有意义的。此外，我遇到ActionbarSherlock和LoaderManager的回调接口问题（有一个解决方案，但它会使我的数据处理类加倍）。
通过android.database.sqlite直接处理数据库和游标会引发资源管理问题（关闭游标！）并让我负责任务处理。
我的问题：
你是如何在Android上处理SQLite数据库的？
你什么时候加倍努力并实施ContentProvider和LoaderManager？
你如何保持向后兼容？
我目前的做法：
我创建了一个将数据库I / O（通过android.database.sqlite）与活动分开的类。所有方法都会打开和关闭它们在执行期间使用的游标（在我的活动之外），并根据需要返回对象或数据（而不是游标）。 I / O操作在AsyncTasks中执行。这种方法似乎已被弃用。
答案 0 :(得分：4)
我最近有同样简单的sqllite / content提供商困境，看起来内容提供商是解决问题的最常用方法。
即使official doc表明
如果您不打算与其他应用程序共享数据，则无需开发自己的提供程序
他们添加了使用
创建未导出内容提供商的选项android:exported="false"
我读过的所有书籍，包括Reto Meier的专业Android开发4 ，建议使用内容提供商。
此外，以大量样板代码为代价，您可以忘记多线程和打开游标问题。
无论如何，我必须说，从内容提供程序/游标加载器组合中获得的最大优势是，只要底层数据发生更改，您的加载程序就会自动得到通知。
如果使用plain sqllite，则需要实现某种方式，以便在数据在后台更改时通知客户端类。例如，我使用广播来通知任何活动，即在intentservice中更新的表。
最后，我对你所咆哮的所有代码重复感到有些失望，我决定编写一个python脚本，仅使用数据模型的描述来生成内容提供程序。您可能必须修改生成的类（或更好，以扩展它），但我认为它可以节省相当多的时间。你可以找到它here
<强>结论：