解读ContentResolver和ContentProvider

转自：http://cthhqu.blog.51cto.com/7598297/1281217

1. ContentProvider的概述
ContentProvider：
（Official Definition）Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security. Content providers are the standard interface that connects data in one process with code running in another process.
由官方的定义我们可以得知它是一个管理访问结构化数据的机制。我们系统中有些数据很重要，不能让人随便访问，但是因为比较有价值，所以很多应用程序需要用到它，这是就可通过ContentProvider这个机制，压缩数据，提供安全定义、访问数据的机制。该机制提供一个借口，使得应用程序能从该进程访问另外一个应用程序的数据。
不仅是系统重要的数据，如果我们开发过程中有数据也是比较重要，但是需要提供给多个程序访问，这个时候也可以用到ContentProvider机制，把我们的数据的增删改查分装在ContentProvider的增删改查中，并增加相应的安全机制，使得用户可我们规定的安全机制下访问我们的数据。
ContentProvider还有一个重要的特点就是它是可以使得某些数据可以被跨进程访问，一般我们的数据库是不可跨进程被访问，因为数据库一般的数据是属于某个应用程序的，如果其他程序可以随意访问其数据库，这是很危险的，但是如果该应用程序的数据想分享给其他应用程序，那么就可以通过建立一个ContentProvider，规定一些安全机制，屏蔽一些比较重要的数据被访问，或是规定访问权限，比如只可读不可写等，使其他应用程序在有限制的前提下访问我们的数据。这样做就会起到对数据进行保护同时又能使得有用的数据能被分享的作用。
2. ContentResolver和ContentProvider的使用方法
2.1 ContentResolver的使用方法：
首先，我们得了解如何通过ContentResolver来对系统或我们自定义的ContentProvider进行交互，通常，我们常用到的是访问系统的数据，常见的有通讯录、日历、短信、多媒体等，下面以通过ContentResolver获取系统的通讯录为例子，简单演示是如何使用ContentResolver的：
使用方法归纳：

1、从当前Activity获取系统的ContentResolver；
2、使用ContentProvider的insert、delete、update、query方法对ContentProvider的内容进行增删改查；
3、如果是使用query是的到一个Cursor的结果集，通过该结果集可以获得我们查询的结果。

源代码示例：

2.2 常用的系统URI
访问系统提供的其他数据方法基本类似，只是传入的URI有所区别，这些URI都是API里面提供的，通过系统规定的不同URI可访问系统不同的数据。系统常用的URI如下：

联系人的URI：
ContactsContract.Contacts.CONTENT_URI 管理联系人的Uri
ContactsContract.CommonDataKinds.Phone.CONTENT_URI 管理联系人的电话的Uri
ContactsContract.CommonDataKinds.Email.CONTENT_URI 管理联系人的Email的Uri
（注：Contacts有两个表，分别是rawContact和Data，rawContact记录了用户的id和name，

其中id栏名称 为：ContactsContract.Contacts._ID，name名称栏为ContactContract.Contracts.DISPLAY_NAME，

电话信息表的外键id为 ContactsContract.CommonDataKinds.Phone.CONTACT_ID，

电话号码栏名称为：ContactsContract.CommonDataKinds.Phone.NUMBER。

data表中Email地址栏名称为：ContactsContract.CommonDataKinds.Email.DATA
其外键栏为：ContactsContract.CommonDataKinds.Email.CONTACT_ID)

多媒体的ContentProvider的Uri如下：
MediaStore.Audio.Media.EXTERNAL_CONTENT_URI 存储在sd卡上的音频文件
MediaStore.Audio.Media.INTERNAL_CONTENT_URI 存储在手机内部存储器上的音频文件

MediaStore.Audio.Images.EXTERNAL_CONTENT_URI SD卡上的图片文件内容
MediaStore.Audio.Images.INTERNAL_CONTENT_URI 手机内部存储器上的图片
MediaStore.Audio.Video.EXTERNAL_CONTENT_URI SD卡上的视频
MediaStore.Audio.Video.INTERNAL_CONTENT_URI 手机内部存储器上的视频

(注：图片的显示名栏：Media.DISPLAY_NAME，图片的详细描述栏为：Media.DESCRIPTION 图片的保存位置：Media.DATA

短信URI： Content://sms

发送箱中的短信URI： Content://sms/outbox

2.3 ContentProvider的使用方法：

那么我们是如何自定义ContentProvider来对其他程序提供访问我们数据的接口的呢？

一般我们如果有数据想被跨进程共享，就可以定义个ContentProvider，并在该ContentProvider定义访问该数据的方法，这些方法只允许外界传入一个URI和其他附加信息，该URI用于定位想操作数据的对象，而附加信息一般就是操作对象里具体数据的条件（例如SQL里面的where语句或者是SharedPreferences的键值对）。这样，就能做到对外界屏蔽了访问数据的方法，单纯开发URI和附加信息的接口，使得其他应用程序是在我们规定的机制下访问数据。这样既能做到跨进程数据共享，又能消除访问不同类型数据时访问方法的差异性，用户可不用管访问的数据类型是数据库或是其他类型而单纯用URI和附加信息定位操作数据对象，同时有提高了安全性。
2.3.1 URI简介：
安卓中系统和用户自定义ContentProvider不止一个，那么当我们想访问某个ContentProvider时，我们是怎么定位到的呢？由上文可知我们是通过URI定位到我们具体想访问的数据，这时我们得先了解用于定位ContentProvider的URI的构成以及各部分的意义。官网API文档是这样介绍的：
Content URIs have the syntax

content://authority/path/id

content:

The scheme portion of the URI. This is always set to

ContentResolver.SCHEME_CONTENT

(value

content://

). authorityA string that identifies the entire content provider. All the content URIs for the provider start with this string.To guarantee a unique authority, providers should consider using an authority that is the same as the provider class' package identifier. pathZero or more segments, separated by a forward slash (

/

), that identify some subset of the provider's data. Most providers use the path part to identify individual tables. Individual segments in the path are often called "directories" although they do not refer to file directories. The right-most segment in a path is often called a "twig" idA unique numeric identifier for a single row in the subset of data identified by the preceding path part. Most providers recognize content URIs that contain an id part and give them special handling.A table that contains a column named

_ID

often expects the id part to be a particular value for that column.
由上述我们可以得到该URI分为四部分：

第一部分：“content：//”是系统规定的；

第二部分：authority是一个标志整个内容提供者的字符串，也就是该内容提供者的标识符，相当于我们每个人都有的姓名；

第三部分：是内容提供者提供数据的某个子集，因为内容提供者有时会提供多个数据，我们具体是要访问那个子集，需要把具体路径标出来；

第四部分：是一个标志数据子集中具体某一行数据的数字，一般我们数据库都会有ID这一项，通过该字段可直接定位到表中的某一行。如果不知道或用不到该项可不填。

Android里面提供了两个类对URI进行操作，一个是UriMatcher，该类专用于在ContentProvider中建立匹配器，从安卓的API文档我们得知该匹配器用于在ContentProvider类的最开始建立匹配器并添加匹配规则，在后面的方法覆盖过程，需要用到该类的match方法进行匹配，返回匹配到的标志位。

void	addURI(String authority, String path, int code) // 三个参数，第一个是授权信息，第二个是路径，第三个就是当匹配该规则是返回的标志位 Add a URI to match, and the code to return when this URI is matched.

另外一个是ContentUri类，该类仅有的三个方法都是静态类，它是一个提供对URI和ID进行操作的工具类。常用的主要是parseId：用于取得URI中的Id，其实内部实现方法就是取得Uri PATH部分后面的值；withAppendedId用于把ID拼接到一个Uri的后面。

Public Methods
static Uri.Builder	appendId(Uri.Builder builder, long id) Appends the given ID to the end of the path.
static long	parseId(Uri contentUri) Converts the last path segment to a long.
static Uri	withAppendedId(Uri contentUri, long id) Appends the given ID to the end of the path.

2.3.2 ContentProvider的使用方法：

了解了什么是URI就可以自定义一个ContentProvider，对外提供访问我们数据的接口了。下面以ContentProvider最常封装的数据类型——数据库为例子进行说明。

整个自定义ContentProvider的过程分为两大步，第一步当然是建立数据源，第二部则是建立访问数据源的内容提供者，这里以SQL数据库为例：

第一步：首先我们需要先建一个SQLiteOpenHelper的子类：

第二步：有了数据源，我们接下来就得建立访问数据源的ContentProvider，建立ContentProvider的步骤通常分为：建立匹配器并添加匹配规则，重写各种操作数据的方法。添加匹配规则必需在所有方法和构造函数的执行前执行，因为有时候我们需要在匹配成功后才建立数据库的SQLiteOpenHelper。所以这里必须使用静态代码块添加匹配规则。而重写访问数据的方法主要有增删改查四种，重写的步骤基本遵循： 对Uri进行匹配 --> 获取读或写数据库对象 --> 根据匹配结果利用switch语句判断该执行哪种操作 --> 返回结果。一下是ContentProvider的源码示例：

最后，ContentProvider也是安卓的四大组件之一，所以我们要在Manifest文件的application标签中对其进行注册。这样，一个内容提供者就建立好了。我们可以另外建立一个测试工程，对其进行跨进程访问，不过需要注意的是我们对其进行访问前必须确定该ContentProvider是存在的，所以必须先运行ContentProvider的工程，然后就可以使用测试工程对其进行访问了。这里需要注意的是，当我们把ContentProvider进程关闭后，我们还是可以对其数据进行访问的。一下是测试工程的代码：