关于ConentResolver与AIDL

AIDL,已经不必多言.

不知道猿猴们自己写过AIDL没有.我说的是自己写,不是用googleAIDL工具生成的,如果你仅仅听从google说没有必要自己动手写这句话的话,可能你错过了很多优秀的交互功能,是的,写aidl接口是十分枯燥的,因为很多都是copy,但是,你这样认为的话我觉得你错了,因为不只是枯燥,aidl很注重你的逻辑是否混乱,虽然我写了aidl很久,但是,有时候也会陷进去,因为你需要不断的在客户端与服务端进行逻辑转换,很是头疼.

从我认识android那天开始,我的世界就改变了,本来没有复用的概念,内存的概念.一夜之间忽然存在了,现在写代码,能节省内存绝不浪费,能null就null,能用一个对象就尽量用一个对象,真的很是操蛋,忽然从java中的挥霍变成了拮据.还真有点不习惯.

说道ContentResolver的问题,是我一直很头疼的,因为他其中的ContentObserver只是仅仅的通知你改变了,改变了什么,还需要你自己去实现数据匹配,这也太让人尴尬了,明明自己的ContentProvider端已经适配了数据,还要在Ui端再适配一次,每每想起这种让我头痛的事情,我就很是愤慨google的API,

其实为此我想了很多策略,将具体的数据传递出去.

首先想到的是最笨的方法,接收到ContentChanged.便去匹配一次,这也是我之前项目里做的,当初是接受的System的ContentProvider事件,所以也只能去匹配.

但是现在是自己定义的ContentProvider改变,尤其很恶心的就是我的ContentProvider也需要接受System的ContentProvider,也就是我的ContentProvider需要匹配一遍,然后,通知我的ContentObserver,再进行一次匹配..我当初一眼看到这么耗时的操作,也是很头疼.于是,想到了使用数据库中的字段来进行,但是,当你的数据很多,速度慢的可怕.想到android中的联系人删除就行了.

于是我又想到了AIDL,一开始我打算直接在项目中定制一个算了,但是,回头一想,这样根本无法去适应以后的状况,于是,我写了一个类似于ContentServicer的框架.

名其约 AppContentResolver,

是一种类似于服务器端与客户端交互的模式.,

服务端寄生在ContentProvider,而客户端则没有限制.

当内容发生改变,使用AppContentResolver中的notification方法,进行内部的AppContentObserver改变,

notification方法目前我设置了,四个参数:

int action, Uri notigicationUri, Uriuri,Bundledata, boolean syncToNetwork

action:标记当前增删改的动作

notificationUri:具体通知的Uri.

uri:仅仅是为了方便单一改变而不必使用Bundle的情况

data:更新或者事务后需要交接大量数据的情况.

由于考虑到速度问题,所以,我并不支持Uri的全匹模式,也就是system中的ContentResolver的notifyForDescendents方法.

详见:https://github.com/Maizer/AppContentResolver