【笨鸟先飞】android重新学习日记7---传递数据的方法（contentProvider）

Broadcast是程序间通信使用最多的手段，同时也是单向的通知手段，使用起来简单，一个程序发送广播，就很简单，只需要注册好正确的intent然后发送出去。另外的程序接收广播，也简单，创建一个BroadcastReceiver类，重写一下onReceive方法。然后在开始注册一下，结束的时候注销一下就好了。

 

Broadcast是发送广播的，是一种单向传播，对于需要交流的数据就很难办了，而实际上有不少场景是需要数据交流的

 

最常见的是设置模块里面的很多设置是多入口设置，比如亮度，即可以在设置里面设，也可以在状态栏里面设。这一类的设置，设置会使用一个统一的contentProvider，不同的模块都与使用这个Provider，获取自己想要的参数，以及设定自己想要的参数。

 

假设这种情况。我有一个自动桌面布局的软件，可以对桌面的图标进行整理。

 

这个自动布局软件首先会获取桌面的布局，显示在软件的预览里面，并且提供用户一些快捷帮助手段。

 

然后进行一系列布局，做好之后，要让桌面更改它的实际桌面布局。这个改动就是涉及所有图标的位置。

 

那么这里面涉及到3种数据的交换:获取桌面的图标布局方式，删掉原有的桌面布局方式，更换新的布局方式。

 

如果用广播的话需要这么实现。首先，布局软件给桌面发送一个广播，“我想获得桌面布局”。 然后布局软件将布局放在广播的intent中，“这是布局软件”。然后布局软件在发送广播“这是实际布局”。桌面收到广播后，删除原有图标，新增现有图标。

 

这里面需要3个广播，双方都需要注册广播接收器，非常麻烦，而且对于桌面的图标，可以想象他涉及到的数据，每个图标都有，对于的应用程序intent（点击程序就StartActivity(intent)来启动程序），图标的名字，图标的图片，横坐标，纵坐标，以及放在第几个屏幕等。

 

而如果使用contentProvider就简单多了。桌面提供一个contentProvider的URI，然后，布局软件就可以使用这个URI对其进行获取，删除，添加操作。

 

如果这个软件不是修改布局，而只是应用商城这种更新图标的，那么则需要对桌面的contentProvider进行更新。

 

contentProvider的具体使用。

官方一共提供了四个方法：获取（Query），删除（Delete），添加（Insert），更新（Updata）

而使用contentProvider也就这4个方法。

 

Insert（URI,Values）;

Updata（URI,Values,selection,selectionArgs）;

 

Delete（URI,selection,selectionArgs）；

 

Query（URI,projection ,  selection, selectionArgs, sortOrder);

 

这四个方法共同点是有URI。URI是最重要的一部分，和intent一样，uri的最主要功能是用来标识目标程序，更准确的说是目标contentProvider。

 

URI的写法是content://自己取名字1/自己取名字2/自己取名字3

 

2和3 可有可没有，如果有用“/”分隔，一般名字123基本是packgeName保持很高的相似度，在配上这个content的含义。

 

这样对于两个或多个需要进行数据交互的场景，就可以使用contentProvider。

 

多个程序的数据交互也使用contentProvider，举一个多处控制的应用场景。

 

Google的安卓手机最近推出了一个负一平系统。就是在正常屏幕的基础上，往左滑还有一个额外的屏幕，（苹果手机也有，苹果是IOS，这里以安卓为例），这个屏幕默认用来显示一些最近常用程序，天气时间之类的。

 

这个屏幕实际可用任意编辑，甚至可以防止一个小游戏程序在里面。对于这个负一平，往往要求有多个开关同时控制是否可以使用。

 

最基本的地方是设置里面，应该有一个关于负一平东西的开关。其次在桌面或者状态栏，应该也有一个快捷开关通路，再次负一平对于应用程序本身也可能一个设置作为开关。

 

第三种情况是一个假设，假设一个可以点开的应用做了一个桌面可用的负一平。

 

这里我们假设有3个开关。共同控制着负一平是否显示。那么需要完成这么两个功能。

 

1：在任何一个开关点击关闭，负一平功能将会关闭，在任何一个开关点击打开，负一平功能将会打开。

2：在任何一个开关点击关闭，另外两个开关同步进入关闭状态。任何一个开关点击打开，另外两个开关同步进入打开状态。

 

上面应该叫做A、B、C三个程序，其中A可以直接通知负一平功能的开关，而B和C应该是间接的控制A的开关。

 

在B开关的时候，需要告知A关闭开关，且告知C，同步一下你的开关显示。

 

首先想到第一种方案，就是广播加接收器。有两个共同的广播“开”和“关”。ABC程序，进行开或关的时候，都发送一个广播，然后三个程序都有接收器，任何一个发送广播，所有程序都统一进行处理。

 

这个方法是可以的，对于单个的开关，用两个广播就好了。如果开关多的话，则不可用，每个开关对应两个广播。多个开关对应广播太多，维护，研发等等缺点太多。

 

开关多的时候，还是使用contentProvider，contentProvider有一个对于的监察器，叫做contentObserver。可以对contentProvider进行监控，该类的onchange方法可以跟着需要监控数据的变化，从而及时获取数据。

 

这样每个开关，对应一个参数。通过updata来修改参数。其他程序通过onchange来获得修改，然后通过Query获取开关的状态。

 

以上就是contentProvider的用法，以及contentProvider大多数是与数据库连接的，大多数时候，是给与其他程序修改数据库权限的组件。

 

关于数据的储存，明天详解。