Android数据库最佳实践？

什么是实现数据库框架的“Android方式”？Android数据库最佳实践？

这两个目标：

它应该是足够通用的，所以说“数据库”可以通过网络SQLite数据库什么的。
它应该是多线程安全的。（更新：通过“线程安全”，我的意思是它不应该在主UI线程中运行，数据库调用不应该相互冲突，并且系统应该知道如何将结果通信回主UI线程。）
更新时间：应该了解的配置改变（如改变手机方向）

这就是我从这里聚集和Android文档：

但是，如何创建，更新和删除数据？据我所知，LoaderManager仅用于查询。我应该使用AsyncQueryHandler吗？

更新： AsyncQueryHandler不知道配置更改。我读过碎片可能是要走的路。或者...我必须确保我的AsyncQueryHandler实现处理配置更改。

2013-07-11 U Avalos

关于目标1：相当困难的，但肯定的，ContentProvider的可以提供从远程数据库中，而不是本地SQLite数据库的内容。听起来像是一个很好的抽象使用 – zapl

我想问题是，所有这些似乎对我来说是碎片化的。我期待一个LoaderManager处理所有CRUD –

装载机的一点是，他们是异步加载数据到主线程的效用。他们不打算对C，U或D做任何事情。只是帮助R（eading）。如果你想坚持Android的现有抽象系统，使用ContentProvider，因为这是一个通用的CRUD接口，不限于任何类型的数据库。 – zapl

（1）非常简单：只需在ContentProvider和实现所有低级CRUD的数据之间添加一个额外的类即可。例如，一个类可以处理sqlite数据库，另一个具有相同接口的类可以处理Google驱动器的后端。

做了一些研究之后，这里是你如何处理（2）和（3）与Android类：

的AsyncTask - 不幸的是，的AsyncTask不知道配置更改，所以你必须编写你自己（它变得丑陋）。
无头碎片 - 没有UI的碎片。你基本上必须编写你自己的AsyncTaskLoader，这样才能打破这一点。（见这里http://blogactivity.wordpress.com/2011/09/01/proper-use-of-asynctask/）
AsyncTaskLoader - 似乎是去

装载机的方式被设计来加载数据，但你可以破解一个Loader也处理插入/更新。（你可以在loadInBackground（）方法中做任何你想做的事情。）

问题是，在HoneyComb之前，所有的Loaders共享一个线程池来并行地执行请求。（在HoneyComb之后，Loaders按顺序执行任务）。这意味着不仅是彼此之后立即执行的任务不能保证按顺序执行，而且如果不能正确处理多线程，将会出现数据一致性问题。

如果你在更新数据库后台运行一个服务，你还是会担心在后蜂窝多线程。

的底线是，似乎没有将Android框架，它抽象掉的“数据库调用不应该相互冲突”的问题。你必须自己处理。

2013-07-14 00:15:06

回答