Android应用程序组件Content Provider应用实例 / 憋错料

文章转载至CSDN社区罗升阳的安卓之旅，原文地址：http://blog.csdn.net/luoshengyang/article/details/6950440

文简要介绍了Android应用程序组件Content Provider在应用程序间共享数据的原理，但是没有进一步研究它的实现。本文将实现两个应用程序，其中一个以Content Provider的形式来提供数据访问入口，另一个通过这个Content Provider来访问这些数据。本文的例子不仅可以为下文分析Content Provider的实现原理准备好使用情景，还可以学习到它的一个未公开接口。

本文中的应用程序是按照上一篇文章Android应用程序组件Content Provider简要介绍和学习计划中提到的一般应用程序架构方法来设计的。本文包含两个应用程序，其中，第一个应用程序命名为ArticlesProvider，它使用了SQLite数据库来维护一个文章信息列表，同时，它定义了访问这个文章信息列表的URI，这样，我们就可以通过一个Content Provider组件来向第三方应用程序提供访问这个文章信息列表的接口；第二个应用程序命名为Article，它提供了管理保存在 ArticlesProvider应用程序中的文章信息的界面入口，在这个应用程序中，用户可以添加、删除和修改这些文章信息。接下来我们就分别介绍这两个应用程序的实现。

1. ArticlesProvider应用程序的实现

首先是参照在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务一文，在packages/experimental目录下建立工程文件目录ArticlesProvider。在继续介绍这个应用程序的实现之前，我们先介绍一下这个应用程序用来保存文章信息的数据库的设计。

我们知道，在Android系统中，内置了一款轻型的数据库SQLite。SQLite是专门为嵌入式产品而设计的，它具有占用资源低的特点，而且是开源的，非常适合在Android平台中使用，关于SQLite的更多信息可以访问官方网站http://www.sqlite.org。

ArticlesProvider应用程序就是使用SQLite来作为数据库保存文章信息的，数据库文件命名为Articles.db，它里面只有一张表ArticlesTable，表的结构如下所示：

-------------------------------------------------------------

| -- _id -- | -- _title -- | -- _abstrat -- | -- _url -- |

-------------------------------------------------------------

| | | | |

它由四个字段表示，第一个字段_id表示文章的ID，类型为自动递增的integer，它作为表的key值；第二个字段_title表示文章的题目，类型为text；第三个字段_abstract表示文章的摘要，类型为text；第四个字段_url表示文章的URL，类型为text。注意，当我们打算将数据库表的某一列的数据作为一个数据行的ID时，就约定它的列名为_id。这是因为我们经常需要从数据库中获取一批数据，这些数据以Cursor的形式返回，对这些返回来的数据我们一般用一个ListView来显示，而这个 ListView需要一个数据适配器Adapter来作为数据源，这时候就我们就可以以这个Cursor来构造一个Adapter。有些Adapter，例如android.widget.CursorAdapter，它们在实现自己的getItemId成员函数来获取指定数据行的ID时，就必须要从这个 Cursor中相应的行里面取出列名为_id的字段的内容出来作为这个数据行的ID返回给调用者。当然，我们不在数据库表中定义这个_id列名也是可以的，不过这样从数据库中查询数据后得到的Cursor适合性就变差了，因此，建议我们在设计数据库表时，尽量设置其中一个列名字_id，并且保证这一列的内容是在数据库表中是唯一的。

下面我们就开始介绍这个应用程序的实现了。这个应用程序只有两个源文件，分别是Articles.java和ArticlesProvider，都是放在shy.luo.providers.articles这个package下面。在Articles.java文件里面，主要是定义了一些常量，例如用来访问文章信息数据的URI、MIME（Multipurpose Internet Mail Extensions）类型以及格式等，这些常量是第三方应用程序访问这些文章信息数据时要使用到的，因此，我们把它定义在一个单独的文件中，稍后我们会介绍如果把这个Articles.java文件打包成一个jar文件，然后第三方应用程序就可以引用这个常量了，这样也避免了直接把这个源代码文件暴露给第三方应用程序。

源文件Articles.java位于src/shy/luo/providers/articles目录下，它的内容如下所示：

[java] view plain copy

package shy.luo.providers.articles;
import android.net.Uri;
public class Articles {
/*Data Field*/
public static final String ID = "_id";
public static final String TITLE = "_title";
public static final String ABSTRACT = "_abstract";
public static final String URL = "_url";
/*Default sort order*/
public static final String DEFAULT_SORT_ORDER = "_id asc";
/*Call Method*/
public static final String METHOD_GET_ITEM_COUNT = "METHOD_GET_ITEM_COUNT";
public static final String KEY_ITEM_COUNT = "KEY_ITEM_COUNT";
/*Authority*/
public static final String AUTHORITY = "shy.luo.providers.articles";
/*Match Code*/
public static final int ITEM = 1;
public static final int ITEM_ID = 2;
public static final int ITEM_POS = 3;
/*MIME*/
public static final String CONTENT_TYPE = "vnd.android.cursor.dir/vnd.shy.luo.article";
public static final String CONTENT_ITEM_TYPE = "vnd.android.cursor.item/vnd.shy.luo.article";
/*Content URI*/
public static final Uri CONTENT_URI = Uri.parse("content://" + AUTHORITY + "/item");
public static final Uri CONTENT_POS_URI = Uri.parse("content://" + AUTHORITY + "/pos");
}

ID、TITLE、ABSTRACT和URL四个常量前面已经解释过了，它是我们用来保存文章信息的数据表的四个列名；DEFAULT_SORT_ORDER常量是调用ContentProvider接口的query函数来查询数据时用的，它表示对查询结果按照_id 列的值从小到大排列；METHOD_GET_ITEM_COUNT和KEY_ITEM_COUNT两个常量是调用ContentProvider接口的一个未公开函数call来查询数据时用的，它类似于微软COM中的IDispatch接口的Invoke函数，使用这个call函数时，传入参数 METHOD_GET_ITEM_COUNT表示我们要调用我们自定义的ContentProvider子类中的getItemCount函数来获取数据库中的文章信息条目的数量，结果放在一个Bundle中以KEY_ITEM_COUNT为关键字的域中。

剩下的常量都是跟数据URI相关的，这个需要详细解释一下。URI的全称是Universal Resource Identifier，即通用资源标志符，通过它用来唯一标志某个资源在网络中的位置，它的结构和我们常见的HTTP形式URL是一样的，其实我们可以把常见的HTTP形式的URL看成是URI结构的一个实例，URI是在更高一个层次上的抽象。在Android系统中，它也定义了自己的用来定痊某个特定的 Content Provider的URI结构，它通常由四个组件来组成，如下所示：

[content://][shy.luo.providers.articles][/item][/123]

|------A------|-----------------B-------------------|---C---|---D--|

A组件称为Scheme，它固定为content://，表示它后面的路径所表示的资源是由Content Provider来提供的。

B组件称为Authority，它唯一地标识了一个特定的Content Provider，因此，这部分内容一般使用Content Provider所在的package来命名，使得它是唯一的。

C组件称为资源路径，它表示所请求的资源的类型，这部分内容是可选的。如果我们自己所实现的Content Provider只提供一种类型的资源访问，那么这部分内部就可以忽略；如果我们自己实现的Content Provider同时提供了多种类型的资源访问，那么这部分内容就不可以忽略了。例如，我们有两种电脑资源可以提供给用户访问，一种是笔记本电脑，一种是平板电脑，我们就把分别它们定义为notebook和pad；如果我们想进一步按照系统类型来进一步细分这两种电脑资源，对笔记本电脑来说，一种是安装了 windows系统的，一种是安装了linux系统的，我们就分别把它们定义为notebook/windows和notebook/linux；对平板电脑来说，一种是安装了ios系统的，一种是安装了android系统的，我们就分别把它们定义为pad/ios和pad/android。

D组件称为资源ID，它表示所请求的是一个特定的资源，它通常是一个数字，对应前面我们所介绍的数据库表中的_id字段的内容，它唯一地标志了某一种资源下的一个特定的实例。继续以前面的电脑资源为例，如果我们请求的是编号为123的装了android系统的平板电脑，我们就把它定义为 pad/android/123。当忽略这部分内容时，它有可能是表示请求某一种资源下的所有实例，取决于我们的URI匹配规则，后面我们将会进一步解释如何设置URI匹配规则。

回到上面的Articles.java源文件中，我们定义了两个URI，分别用COTENT_URI和CONTENT_POS_URI两个常量来表示，它们的Authority组件均指定为shy.luo.providers.articles。其中，COTENT_URI常量表示的URI表示是通过 ID来访问文章信息的，而CONTENT_POS_URI常量表示的URI表示是通过位置来访问文章信息的。例如，content://shy.luo.providers.articles/item表示访问所有的文章信息条目；content: //shy.luo.providers.articles/item/123表示只访问ID值为123的文章信息条目；content: //shy.luo.providers.articles/pos/1表示访问数据库表中的第1条文章信息条目，这条文章信息条目的ID值不一定为1。通过常量CONTENT_POS_URI来访问文章信息条目时，必须要指定位置，这也是我们设置的URI匹配规则来指定的，后面我们将会看到。

此外，我们还需要定义与URI对应的资源的MIME类型。每个MIME类型由两部分组成，前面是数据的大类别，后面定义具体的种类。在Content Provider中，URI所对应的资源的MIME类型的大类别根据同时访问的资源的数量分为两种，对于访问单个资源的URI，它的大类别就为 vnd.android.cursor.item，而对于同时访问多个资源的URI，它的大类别就为vnd.android.cursor.dir。 Content Provider的URI所对应的资源的MIME类型的具体类别就需要由Content Provider的提供者来设置了，它的格式一般为vnd.[company name].[resource type]的形式。例如，在我们的例子中，CONTENT_TYPE和COTENT_ITEM_TYPE两个常量分别定义了两种MIME类型，它们的大类别分别为vnd.android.cursor.dir和vnd.android.cursor.item，而具体类别均为 vdn.shy.luo.article，其中shy.luo就是表示公司名了，而article表示资源的类型为文章。这两个MIME类型常量主要是在实现ContentProvider的getType函数时用到的，后面我们将会看到。

最后，ITEM、ITEM_ID和POS_ID三个常量分别定了三个URI匹配规则的匹配码。如果URI的形式为 content://shy.luo.providers.articles/item，则匹配规则返回的匹配码为ITEM；如果URI的形式为 content://shy.luo.providers.articles/item/#，其中#表示任意一个数字，则匹配规则返回的匹配码为 ITEM_ID；如果URI的形式为#也是表示任意一个数字，则匹配规则返回的匹配码为ITEM_POS。这三个常量的用法我们在后面也将会看到。

这样，Articles.java文件的内容就介绍完了。下面我们再接着介绍位于src/shy/luo/providers/articles目录下的ArticlesProvider.java文件，它的内容如下所示：

[java] view plain copy

import java.util.HashMap;
import android.content.ContentValues;
import android.content.Context;
import android.content.UriMatcher;
import android.content.ContentProvider;
import android.content.ContentUris;
import android.content.ContentResolver;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteDatabase.CursorFactory;
import android.database.sqlite.SQLiteException;
import android.database.sqlite.SQLiteOpenHelper;
import android.database.sqlite.SQLiteQueryBuilder;
import android.net.Uri;
import android.os.Bundle;
import android.text.TextUtils;
import android.util.Log;
public class ArticlesProvider extends ContentProvider {
private static final String LOG_TAG = "shy.luo.providers.articles.ArticlesProvider";
private static final String DB_NAME = "Articles.db";
private static final String DB_TABLE = "ArticlesTable";
private static final int DB_VERSION = 1;
private static final String DB_CREATE = "create table " + DB_TABLE +
" (" + Articles.ID + " integer primary key autoincrement, " +
Articles.TITLE + " text not null, " +
Articles.ABSTRACT + " text not null, " +
Articles.URL + " text not null);";
private static final UriMatcher uriMatcher;
static {
uriMatcher = new UriMatcher(UriMatcher.NO_MATCH);
uriMatcher.addURI(Articles.AUTHORITY, "item", Articles.ITEM);
uriMatcher.addURI(Articles.AUTHORITY, "item/#", Articles.ITEM_ID);
uriMatcher.addURI(Articles.AUTHORITY, "pos/#", Articles.ITEM_POS);
}
private static final HashMap<String, String> articleProjectionMap;
static {
articleProjectionMap = new HashMap<String, String>();
articleProjectionMap.put(Articles.ID, Articles.ID);
articleProjectionMap.put(Articles.TITLE, Articles.TITLE);
articleProjectionMap.put(Articles.ABSTRACT, Articles.ABSTRACT);
articleProjectionMap.put(Articles.URL, Articles.URL);
}
private DBHelper dbHelper = null;
private ContentResolver resolver = null;
@Override
public boolean onCreate() {
Context context = getContext();
resolver = context.getContentResolver();
dbHelper = new DBHelper(context, DB_NAME, null, DB_VERSION);
Log.i(LOG_TAG, "Articles Provider Create");
return true;
}
@Override
public String getType(Uri uri) {
switch (uriMatcher.match(uri)) {
case Articles.ITEM:
return Articles.CONTENT_TYPE;
case Articles.ITEM_ID:
case Articles.ITEM_POS:
return Articles.CONTENT_ITEM_TYPE;
default:
throw new IllegalArgumentException("Error Uri: " + uri);
}
}
@Override
public Uri insert(Uri uri, ContentValues values) {
if(uriMatcher.match(uri) != Articles.ITEM) {
throw new IllegalArgumentException("Error Uri: " + uri);
}
SQLiteDatabase db = dbHelper.getWritableDatabase();
long id = db.insert(DB_TABLE, Articles.ID, values);
if(id < 0) {
throw new SQLiteException("Unable to insert " + values + " for " + uri);
}
Uri newUri = ContentUris.withAppendedId(uri, id);
resolver.notifyChange(newUri, null);
return newUri;
}
@Override
public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
SQLiteDatabase db = dbHelper.getWritableDatabase();
int count = 0;
switch(uriMatcher.match(uri)) {
case Articles.ITEM: {
count = db.update(DB_TABLE, values, selection, selectionArgs);
break;
}
case Articles.ITEM_ID: {
String id = uri.getPathSegments().get(1);
count = db.update(DB_TABLE, values, Articles.ID + "=" + id
+ (!TextUtils.isEmpty(selection) ? " and (" + selection + ‘)‘ : ""), selectionArgs);
break;
}
default:
throw new IllegalArgumentException("Error Uri: " + uri);
}
resolver.notifyChange(uri, null);
return count;
}
@Override
public int delete(Uri uri, String selection, String[] selectionArgs) {
SQLiteDatabase db = dbHelper.getWritableDatabase();
int count = 0;
switch(uriMatcher.match(uri)) {
case Articles.ITEM: {
count = db.delete(DB_TABLE, selection, selectionArgs);
break;
}
case Articles.ITEM_ID: {
String id = uri.getPathSegments().get(1);
count = db.delete(DB_TABLE, Articles.ID + "=" + id
+ (!TextUtils.isEmpty(selection) ? " and (" + selection + ‘)‘ : ""), selectionArgs);
break;
}
default:
throw new IllegalArgumentException("Error Uri: " + uri);
}
resolver.notifyChange(uri, null);
return count;
}
@Override
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs, String sortOrder) {
Log.i(LOG_TAG, "ArticlesProvider.query: " + uri);
SQLiteDatabase db = dbHelper.getReadableDatabase();
SQLiteQueryBuilder sqlBuilder = new SQLiteQueryBuilder();
String limit = null;
switch (uriMatcher.match(uri)) {
case Articles.ITEM: {
sqlBuilder.setTables(DB_TABLE);
sqlBuilder.setProjectionMap(articleProjectionMap);
break;
}
case Articles.ITEM_ID: {
String id = uri.getPathSegments().get(1);
sqlBuilder.setTables(DB_TABLE);
sqlBuilder.setProjectionMap(articleProjectionMap);
sqlBuilder.appendWhere(Articles.ID + "=" + id);
break;
}
case Articles.ITEM_POS: {
String pos = uri.getPathSegments().get(1);
sqlBuilder.setTables(DB_TABLE);
sqlBuilder.setProjectionMap(articleProjectionMap);
limit = pos + ", 1";
break;
}
default:
throw new IllegalArgumentException("Error Uri: " + uri);
}
Cursor cursor = sqlBuilder.query(db, projection, selection, selectionArgs, null, null, TextUtils.isEmpty(sortOrder) ? Articles.DEFAULT_SORT_ORDER : sortOrder, limit);
cursor.setNotificationUri(resolver, uri);
return cursor;
}
@Override
public Bundle call(String method, String request, Bundle args) {
Log.i(LOG_TAG, "ArticlesProvider.call: " + method);
if(method.equals(Articles.METHOD_GET_ITEM_COUNT)) {
return getItemCount();
}
throw new IllegalArgumentException("Error method call: " + method);
}
private Bundle getItemCount() {
Log.i(LOG_TAG, "ArticlesProvider.getItemCount");
SQLiteDatabase db = dbHelper.getReadableDatabase();
Cursor cursor = db.rawQuery("select count(*) from " + DB_TABLE, null);
int count = 0;
if (cursor.moveToFirst()) {
count = cursor.getInt(0);
}
Bundle bundle = new Bundle();
bundle.putInt(Articles.KEY_ITEM_COUNT, count);
cursor.close();
db.close();
return bundle;
}
private static class DBHelper extends SQLiteOpenHelper {
public DBHelper(Context context, String name, CursorFactory factory, int version) {
super(context, name, factory, version);
}
@Override
public void onCreate(SQLiteDatabase db) {
db.execSQL(DB_CREATE);
}
@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
db.execSQL("DROP TABLE IF EXISTS " + DB_TABLE);
onCreate(db);
}
}
}

我们在实现自己的Content Provider时，必须继承于ContentProvider类，并且实现以下六个函数：

-- onCreate()，用来执行一些初始化的工作。

-- query(Uri, String[], String, String[], String)，用来返回数据给调用者。

-- insert(Uri, ContentValues)，用来插入新的数据。

-- update(Uri, ContentValues, String, String[])，用来更新已有的数据。

-- delete(Uri, String, String[])，用来删除数据。

-- getType(Uri)，用来返回数据的MIME类型。

这些函数的实现都比较简单，这里我们就不详细介绍了，主要解释五个要点。

第一点是我们在ArticlesProvider类的内部中定义了一个DBHelper类，它继承于SQLiteOpenHelper类，它用是用辅助我们操作数据库的。使用这个DBHelper类来辅助操作数据库的好处是只有当我们第一次对数据库时行操作时，系统才会执行打开数据库文件的操作。拿我们这个例子来说，只有第三方应用程序第一次调用query、insert、update或者delete函数来操作数据库时，我们才会真正去打开相应的数据库文件。这样在onCreate函数里，就不用执行打开数据库的操作，因为这是一个耗时的操作，而在onCreate函数中，要避免执行这些耗时的操作。

第二点是设置URI匹配规则。因为我们是根据URI来操作数据库的，不同的URI对应不同的操作，所以我们首先要定义好URI匹配规则，这样，当我们获得一个URI时，就能快速地判断出要如何去操作数据库。设置URI匹配规则的代码如下所示：

[java] view plain copy

private static final UriMatcher uriMatcher;
static {
uriMatcher = new UriMatcher(UriMatcher.NO_MATCH);
uriMatcher.addURI(Articles.AUTHORITY, "item", Articles.ITEM);
uriMatcher.addURI(Articles.AUTHORITY, "item/#", Articles.ITEM_ID);
uriMatcher.addURI(Articles.AUTHORITY, "pos/#", Articles.ITEM_POS);
}

在创建UriMatcher对象uriMatcher时，我们传给构造函数的参数为UriMatcher.NO_MATCH，它表示当 uriMatcher不能匹配指定的URI时，就返回代码UriMatcher.NO_MATCH。接下来增加了三个匹配规则，分别是 content://shy.luo.providers.articles/item、content: //shy.luo.providers.articles/item/#和content://shy.luo.providers.articles /pos/#，它们的匹配码分别是Articles.ITEM、Articles.ITEM_ID和Articles.ITEM_POS，其中，符号#表示匹配任何数字。

第三点是SQLiteQueryBuilder的使用。在query函数中，我们使用SQLiteQueryBuilder来辅助数据库查询操作，使用这个类的好处是我们可以不把数据库表的字段暴露出来，而是提供别名给第三方应用程序使用，这样就可以把数据库表内部设计隐藏起来，方便后续扩展和维护。列别名到真实列名的映射是由下面这个HashMap成员变量来实现的：

[java] view plain copy

private static final HashMap<String, String> articleProjectionMap;
static {
articleProjectionMap = new HashMap<String, String>();
articleProjectionMap.put(Articles.ID, Articles.ID);
articleProjectionMap.put(Articles.TITLE, Articles.TITLE);
articleProjectionMap.put(Articles.ABSTRACT, Articles.ABSTRACT);
articleProjectionMap.put(Articles.URL, Articles.URL);
}

在上面的put函数中，第一个参数表示列的别名，第二个参数表示列的真实名称。在这个例子中，我们把列的别名和和真实名称都设置成一样的。

第四点是数据更新机制的使用。执行insert、update和delete三个函数时，都会导致数据库中的数据发生变化，所以这时候要通过调用 ContentResolver接口的notifyChange函数来通知那些注册了监控特定URI的ContentObserver对象，使得它们可以相应地执行一些处理，例如更新数据在界面上的显示。在query函数中，最终返回给调用者的是一个Cursor，调用者获得这个Cursor以后，可以通过它的deleteRow或者commitUpdates来执行一些更新数据库的操作，这时候也要通知那些注册了相应的URI的 ContentObserver来作相应的处理，因此，这里在返回Cursor之前，要通过Cursor类的setNotificationUri函数来把当前上下文的ContentResolver对象保存到Curosr里面去，以便当通过这个Cursor来改变数据库中的数据时，可以通知相应的 ContentObserver来处理。不过这种用法已经过时了，即不建议通过这个Cursor来改变数据库的数据，要把Cursor中的数据看作是只读数据。这里调用Cursor类的setNotificationUri函数还有另外一个作用，我们注意到它的第二个参数uri，对应的是Cursor中的内容，当把这个uri传给Cursor时，Cursor就会注册自己的ContentObserver来监控这个uri对应的数据的变化。一旦这个uri 对应的数据发生变化，这个Cursor对应的数据就不是再新的了，这时候就需要采取一些操作来更新内容了。

第五点我们实现了ContentProvider的call函数。这个函数是一个未公开的函数，第三方应用程序只有Android源代码环境下开发，才能使用这个函数。设计这个函数的目的是什么呢？我们知道，当我们需要从Content Provider中获得数据时，一般都是要通过调用它的query函数来获得的，而这个函数将数据放在Cursor中来返回给调用者。以前面一篇文章Android应用程序组件Content Provider简要介绍和学习计划中，我们提到，Content Provider传给第三方应用程序的数据，是通过匿名共享内存来传输的。当要传输的数据量大的时候，使用匿名共享内存来传输数据是有好处的，它可以减入数据的拷贝，提高传输效率。但是，当要传输的数据量小时，使用匿名共享内存来作为媒介就有点用牛刀来杀鸡的味道了，因为匿名共享内存并不是免费的午餐，系统创建和匿名共享内存也是有开销的。因此，Content Provider提供了call函数来让第三方应用程序来获取一些自定义数据，这些数据一般都比较小，例如，只是传输一个整数，这样就可以用较小的代价来达到相同的数据传输的目的。

至此，ArticlesProvider的源代码就分析完了，下面我们还要在AndroidManifest.xml文件中配置这个ArticlesProvider类才能正常使用。AndroidManifest.xml文件的内容如下所示：

Android应用程序组件Content Provider应用实例

Android应用程序组件Content Provider应用实例的相关文章