Android Content Provider基础

最新推荐文章于 2023-05-19 19:35:33 发布

weixin_33915554

最新推荐文章于 2023-05-19 19:35:33 发布

阅读量122

点赞数

文章标签：移动开发人工智能

Android Content Provider基础

Content Providers

　　Content providers管理对一个结构化的数据集合的访问。它们封装了数据，并且提供了保护数据安全性的机制。

　　Content providers是连接跨进程数据的标准接口。

　　当你需要访问一个content provider中的数据时：

　　你在应用的Context中，使用ContentResolver对象作为一个客户端(client)，来和provider通信。

　　而provider是实现了ContentProvider的一个类的实例，它接收来自客户端的请求，执行请求的动作，然后返回结果。

　　一般情况下如果你不想和其他应用分享数据的话，是不用开发你自己的content provider的，但是，如果你在你的应用中需要自定义搜索建议，或者实现复制粘贴复杂数据或者文件到其他应用中，你还是需要自己实现provider。

　　Android本身包含了一些content providers，他们管理音频、视频、图像、联系人信息等数据。

　　你可以从这个包中（android.provider）看到它们。

　　这些providers可以在一些限制条件下，被任何Android应用访问。

Content Provider Basics

　　Content provider最初就是想提供给其他应用来访问的，providers和provider clients提供了一个一致、标准的接口来访问数据，同时也处理了跨进程的通信和数据访问的安全问题。

　　下面讨论几个基础问题。

数据保存形式

　　Content provider向外部应用提供数据，用一个或多个table的形式，和关系型数据中的表（table）是类似的，一行就代表了一条数据实例，而这行中的每一列代表了这个实例中的一项数据。表中每一列的header是列名。

　　注意：一个provider是不要求有主键（primary key）的，如果有主键，也不要求非要用_ID这个名字。

　　但是，如果你想要把provider的数据和一个ListView绑定，必须有一列叫_ID，原因在 Displaying query results部分解释。

访问一个provider

　　Provider是一个 ContentProvider类的具体子类的实例。

　　要访问provider，需要通过一个客户端对象，即一个 ContentResolver 对象。这个对象中含有一些方法，名字和provider中的相同。

　　ContentResolver中的方法提供了基本的CRUD(create, retrieve, update, and delete)功能。

　　客户端应用中的ContentResolver对象和拥有provider的应用中的ContentProvider对象自动地处理跨进程的通信（inter-process communication）。

　　Provider也扮演一个抽象层，位置处在repository of data和作为data外部表现的tables之间。　　

　　注意：要访问一个provider，你的应用通常需要请求一些特定的权限，这些在Content Provider Permissions部分讨论。

Content URIs

　　Content URI是一个URI，它用来确定识别（identify）provider中的数据的。

　　Content URIs包含了provider的标志符号名（authority）和一个指向表的名字（path）。

　　当你调用一个客户端方法访问provider中的table时，content URI就是其中一个参数。

　　 ContentResolver对象会解析出URI的authority，通过和系统中已知的providers的表进行对比，决议找出需要的provider。

　　之后，ContentResolver对象将会向正确的provider分发（dispatch）查询的参数。

　　ContentProvider使用URI的path部分来选择要访问的table，通常每一个table都有一个path。

　　一个完整的URI例子：

　　content://user_dictionary/words

　　其中user_dictionary为authority，words为table的path，content:// (the scheme)必须有，它说明这个URI是一个content URI。　　

　　有很多的provider允许你在URI中附加ID值来访问table中的某一行，比如：

Uri singleUri = ContentUris.withAppendedId(UserDictionary.Words.CONTENT_URI,4);

　　注意： Uri 和 Uri.Builder 类包含了很多方法可以从字符串构造URI；ContentUris 提供了方便的方法可以给URI附加id值。

Retrieving Data from the Provider

　　从provider中取数据，基本的步骤如下：

　　1.请求向provider获取数据的权限。

　　2.定义代码，向provider发送查询。

　　权限的获取不能是运行时请求的，必须在manifest文件中说明你需要这种权限，使用<uses-permission> 元素，然后用provider定义的权限名。

　　更多关于provider的权限的讨论参见：Content Provider Permissions.

　　构造查询：查询类似于SQL查询，包含了要返回的一些列（The set of columns that the query should return is called a projection），一个选择标准的集合，以及排序的顺序。

Displaying query results

　　客户端方法 ContentResolver.query() 总是返回Cursor，包含了满足选择标准的行中的由projection指定的列（containing the columns specified by the query's projection for the rows that match the query's selection criteria）。

　　Cursor 提供了对其包含的行和列的随机访问。

　　使用 Cursor 类的方法，可以迭代访问结果中的行，决定每一列的数据类型，从列中取得数据，检验结果的其他特性等。

　　一些Cursor类的实现会在provider中的数据改变时自动地更新对象，或者在Cursor改变的时候，触发一些观察者对象的方法，或者二者都有。

　　注意：一个provider有可能会根据发出查询的对象的本质，限制对列的访问。

　　比如，Contacts Provider对sync adapters限制了对某些列的访问，所以它不会把这些列发送给一个activity或者service。

　　如果没有行满足查询条件，provider会返回一个空的Cursor对象，即它的 Cursor.getCount() 是0。

　　如果查询失败，查询的结果取决于具体的provider，它可以选择返回null，也可能是抛出异常。

　　由于一个 Cursor是一个行的列表，一个显示它的内容的不错的方法就是用一个SimpleCursorAdapter把 Cursor和 ListView 连接起来。

　　注意，要用ListView显示时，Cursor必须包含一个列叫做_ID。因此，很多providers中，每一个表都有一个_ID列。

　　和从provider查取数据类似，你也可以使用客户端和provider的交互方式来修改数据。

　　你调用一个 ContentResolver的方法，传递参数，接着就被传到 ContentProvider中的对应方法中去，provider和provider client会自动地处理安全性和跨进程通信问题。

　　具体参见：Inserting, Updating, and Deleting Data