Android. Content provider or Database?

旧时模样 提交于 2019-11-28 05:20:19

There certainly are worthwhile problems for which a provider is a solution, particularly for cross-app data publishing. For example, you need to use a content provider to supply search suggestions to a Quick Search Box.

However, for internal use within an application, I am not a fan. The benefits IMHO are outweighed by the costs (e.g., reduced flexibility, additional overhead).

If you do implement a content provider, bear in mind that they are accessible by other applications by default. You need to include android:exported="false" in the <provider> element to make them private to your app.

Using a content provider will give you a more modular design, and make your life easier if you at some point in future would like to reach the data from other applications. If you are certain that the data will only ever be needed from one application, you might as well operate directly on the database.

There is one particular SQLite limitation you should be aware of and that is that SQLite is single-user only. What this really means is that you will need to guard your database from being accessed from multiple threads at the same time. This is generally not a problem in a content provider, since they almost always have a single-threaded implementation.

Reasons to use content provider are here.

In summary:

  1. Easily change the underlying data source (you can change your db from Sqlite to Mongo or to a JSON file without any app changes)
  2. Leverage functionality of some Android Classes (SyncAdapter, Loaders, CursorAdapter) - These classes require content provider and you cant use them if you dont have one
  3. Allow many apps to access, use and modify a single data securely. (which is really the main reason for using it)
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!