为什么微信、QQ、淘宝等App都能访问联系人(通讯录)呢?是因为Android存在一种应用之间的数据共享机制,即ContentProvider,ContentProvider作为Android四大组件之一,为存储和获取数据提供统一的接口,可以在不同的应用程序之间共享数据。对于ContentProvier而言,无论数据的来源是什么,它都认为是种表(同时也支持文件数据,只是表格形式用得比较多),然后把数据组织成表格返回给使用者。
自定义ContentProvider
step1、自定义类继承于ContentProvider,实现要求的方法
step2、在配置文件中通过provider标签配置,通过android:name属性指定待配置的类,通过android:authorities属性授权,指定当前内容提供者的uri标识,必须唯一。
下面来展示一个B应用来操作A应用中的数据的例子:
首先在ContentProviderDemo这个工程里写一个名为MyContentProvider的ContentProvider:
1 | public class MyContentProvider extends ContentProvider { |
对于四大组件之一的ContentProvider同样需要在AndroidManifest.xml中声明:
1 |
|
必须通过android:name属性指定待配置的类,通过android:authorities属性授权,指定当前内容提供者的uri标识,必须唯一,因为对于使用ContentProvier的App来说,这是唯一可以找到该ContentProvier的信息,就像坐标一样,是唯一可以确定你的位置的信息。
可以看到在这个类里面主要包含了CRUD等方法,还有getType()方法和onCreate()方法。所以为什么说对于ContentProvier而言,无论数据的来源是什么,它都认为是种表,然后把数据组织成表格。因为这恰好对应了表中数据的CRUD。至于getType()方法是做什么现在可以不管,整个MyContentProvider不过是在初始化的时候创建了数据库,拿到了SQLiteDatabase对象,然后MyContentProvider其中的CRUD方法实现成了数据库的操作方法而已。如果对数据库不太熟悉,可以参考之前的文章《SQLite原理与运用》,里面有具体介绍使用方法。
值得注意的是,虽然我们在MyContentProvider的CRUD中使用了SQLite数据库,但是其实这和ContentProvider本身并没有关系,数据的增删改查我们完全也可以用HashMap这种数据结构存在内存中,或者存成文件的形式,一行文本就代表一个数据对象,这里为了方便演示所以直接采用了SQLite。
ContentProviderDemo这个工程就结束了,因为作为内容提供者,它无需提供操作界面。下面看看使用者,也就是图中的OtherApplication。当然在这个示例中,这个工程名称为ContentAcquireDemo,界面和《SQLite原理与运用》中的界面一模一样,只不过是在CRUD的时候不再是操作本地SQLite,而是操作ContentProviderDemo中的MyContentProvider:
1 | public class MainActivity extends AppCompatActivity { |
可以看到,其实使用content://cn.tim.myprovider这个ContentProvider同样达到了CRUD的效果,需要注意的就是别把URI写错了就行,所以下面来看看URI的解析:
Uri匹配之UriMatcher
UriMatcher:在ContentProvider创建时,制定好匹配规则,当调用了ContentProvider中的操作方法时,利用匹配类去匹配传的uri,根据不同的uri给出不同的处理。
现在在MyContentProvider的onCrate()方法中定义一个UriMatcher匹配器,并且给出匹配规则如下:
1 | public class MyContentProvider extends ContentProvider { |
这样在另一个App中使用MyContentProvider的delete()方法的时候就会进行URI匹配判断:
1 | contentResolver.delete(Uri.parse("content://cn.tim.myprovider/hello"), null, null); |
大家在今后的开发中可能会用到更多的匹配模式,接下来我们学习UriMatcher更多匹配:
UriMatcher还可以使用匹配通配符来匹配任意不确定的值:
1 | matcher = new UriMatcher(UriMatcher.NO_MATCH); |
Uri与Uri自带的解析方法
使用Uri自带的解析方法
现在ContentAcquireDemo假设添加方法是这样调用的,即把参数写在Uri里面,这样在ContentProviderDemo工程的MyContentProvider中又是如何解析的呢?
1 | Uri insertUri = Uri.parse("content://cn.tim.myprovider/whatever?name=Tim&age=22&gender=男"); |
MyContentProvider.java的关键代码:
1 |
|
果然通过这样的Uri自带的解析方式来传递参数也是OK的。
关于Uri必须知道的
这样的解析方式涉及到Uri的组成和结构问题,首先来说一说URI和Uri是什么关系吧,Uri是Android的API,扩展了JavaSE中URI的一些功能来特定的适用于Android开发,所以大家在开发时,只使用Android 提供的Uri即可。
Uri统一资源标识符(Uniform Resource Identifier),有时我们又看到URL这样的东西,他们之间的又是什么关系呢?统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来,比如想要标识一个我国公民,只要用身份证号就可以作为唯一标识,但是使用其他方式也可以用来标识唯一个人,比如:个人定位协议://中华人名共和国/陕西省/西安市/临潼区/斜口街道/西安工程大学/8#宿舍/A120/邹长林, 这个字符串同样标识出了唯一的一个人,起到了URI的作用,所以URL是URI的子集。URL是以描述人的位置来唯一确定一个人的。
所以统一资源标志符URI就是在某一规则下能把一个资源独一无二地标识出来,URL就是某主机上的某路径上的文件来唯一确定一个资源,也就是定位的方式来实现的URI,即URL是URI的一种实现。
关于更多Uri结构和代码提取的资料可以参考《Uri详解之——Uri结构与代码提取》。
使用系统的ContentProvider
下面是通过读写系统通讯录和读取短信的几个小例子,作为ContentProvider使用练习:
读取通讯录
1 | public void visitAddressBook(View view) { |
添加通讯录
1 | public class MainActivity extends AppCompatActivity { |
读取短信
短信类型 | Uri |
---|---|
短信箱 | content://sms |
收件箱 | content://sms/inbox |
发件箱 | content://sms/sent |
草稿箱 | content://sms/draft |
1 | public class MainActivity extends AppCompatActivity { |
在AndroidManifest.xml配置一下权限:
1 | <uses-permission android:name="android.permission.READ_SMS"/> |
ContentProvider的优点
ContentProvider的底层实现是Binder,更多关于Binder的内容可以参考官方文档《Binder》。ContentProvider为应用间的数据交互提供了一个安全的环境:允许把自己的应用数据根据需求开放给其他应用进行CRUD,而不用担心因为直接开放数据库权限而带来的安全问题。而其他对外共享数据的方式,数据访问方式会因数据存储的方式而不同而发生变化,底层存储方式变更会影响上层,使访问数据变得更加复杂。而采用ContentProvider方式,其解耦了底层数据的存储方式,使得无论底层数据存储采用何种方式,外界对数据的访问方式都是统一的,这使得访问简单且高效。
原文地址:《探究ContentProvider》
- 本文作者: Tim
- 本文链接: https://zouchanglin.cn/2020/12/09/24594.html
- 版权声明: 本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 许可协议。转载请注明出处!