分类： LINUX
2008-11-26 14:06:31
ContentProvider，顾名思义，就是数据内容的供应者。在Android中它是一 个数据源，屏蔽了具体底层数据源的细节，在ContentProvider内部你可以用Android支持的任何手段进行数据的存储和操作，可能比较常用 的方式是基于Android的SQLite数据库（恩，文档中和示例代码都是以此为例）。无论如何，ContentProvider是一个重要的数据源， 可以预见无论是使用和定制ContentProvider都会很多。于是花了点时间仔细看了看。
数据库操作
从我目前掌握的知识来看，SQLite比较轻量（没有存储过程之类的繁杂手段），用起来也比较简单。实例化一个
SQLiteDatabase类对象，通过它的APIs可以搞定大部分的操作。从sample中看，Android中对db的使用有一种比较简单的模式，
即派生一个 ContentProviderDatabaseHelper类来进行SQLiteDatabase对象实例的获取工作。基本上，
ContentProviderDatabaseHelper类扮演了一个singleton的角色，提供单一的实例化入口点，并屏蔽了数据库创建、打开
升级等细节。在ContentProvider中只需要调用ContentProviderDatabaseHelper的openDatabase方法
获取SQLiteDatabase的实例就好，而不需要进行数据库状态的判断。
URI
像进行数据库操作需要用SQL一样，对ContentProivder进行增删改查等操作都是通过一种特定模式的URI来进行的
（ig：content:
//provider/item/id），URI的能力与URL类似，具体细节可以查看SDK。建立自己的ContentProvider，只需要派生
ContentProivder类并实现insert, delete,
update等抽象函数即可。在这些接口中比较特殊的是getType(uri)。根据传入的uri，该方法按照MIME格式返回一个字符串（==!没听
过的诡异格式...）唯一标识该uri的类型。所谓uri的类型，就是描述这个uri所进行的操作的种类，比如content://xx/a与
content://xx/a/1不是一个类型（前者是多值操作，后者是单值），但content://xx/a/1和content://xx/a/2
就会是一个类型（只是id号不同而已）。
在ContentProvider通常都会实例化一个ContentURIPraser来辅助解析和操作
传入的URI。你需要事先（在static域内）为该ContentURIPraser建立一个uri的语法树，之后就可以简单调用
ContentURIPraser类的相关方法进行uri类型判断（match方法），获取加载在uri中的参数等操作。但我看来，这只是在使用上简化了
相关操作（不然就需要自己做人肉解析了...），但并没有改变类型判定的模式。你依然需要用switch...case...对uri的类型进行判断，并
进行相关后续的操作。从模式来看，这样无疑是具有强烈的坏味道，类似的switch...case...代码要出现N此，每次一个
ContentProvider做uri类型的增减都会需要遍历修改每一个switch...case...，当然，如果你使用模式（策略模式...）进
行改造对手机程序来说无疑是崩溃似的（类型膨胀，效率降低...），所以，只能是忍一忍了（恩，还好不会扩散到别的类中，维护性上不会有杀人性的麻
烦...）。
增删改查
ContentProvider
和所有数据源一样，向外提供增删改查操作接口，这些都是基于uri的指令。进行insert操作的时候，你需要传入一个uri和
ContentValues。uri的作用基本就限于指明增减条目的类型（从数据库层面来看就是table名），ContentValues是一个
key/value表的封装，提供方便的API进行插入数据类型和数据值的设置和获取。在数据库层面上来看，这应该是column
name与value的对应。但为了屏蔽ContentProvider用户涉及到具体数据库的细节，在Android的示例中，用了一个小小的模式。它
为每一个表建一个基于BaseColumn类的派生类（其实完全可以不派生自BaseColumn，特别当你的表不基于默认的自动id做主键的时候），这
个类通常包括一个描述该表的ContentURI对象和形如 public static final TITLE =
"title"这样的column到类数据的对应。从改变上角度来看，你可以修改column的名字而不需要更改用户上层代码，增加了灵活性。
insert方法如果成功会返回一个uri，该uri会在原有的uri基础上增加有一个row id。对于为什么使用row id而不是key
id我想破了脑袋。到最后，我发现我傻了，因为ContentProvider不一定需要使用数据库，使用数据库对应的表也可以没有主键，只有row
id，才能在任何底层介质下做索引标识。
但，基于row
id在删除和修改操作是会造成一定的混乱。删除和修改操作类似。删除操作需要传入一个uri，一个where字串，一组where的参数（做条件判
定...），而修改操作会多一个ContentValues做更新值。着两个操作的uri都支持在末尾添加一个row
id。于是混乱就出现了。当在where参数中指明了key id，而在uri中提供了row id，并且row id和key
id所指函数不一致的时候，你听谁的？示例代码中的做法是完全无视row
id（无语...），如此野蛮的方式我估计也只能在示例中出现，在实际中该如何用，恩，我也不知道。幸运的是，我看了下上层对
ContentProvider的删除操作，其实都不会直接进行，而是通过调用Cursor的delete方法进行，在这前提下，我想Cursor会处理
好这些东西吧。
最后一个操作是查询操作，可以想见，查询的参数是最多的，包括uri和一组条件参数。条件参数类型和标准的sql类似，包括
sort, projection
之类的。从这些参数到sql语句的生成，可以寻求QueryBuilder类的帮助，它提供了一组操作接口，简化了参数到sql的生成工作，哪怕你不懂
sql都完全没有问题（这话说的我自己都觉得有点悬...）。查询返回一个Cursor。Cursor是一个支持随机读写的指针，不仅如此，它还提供了方
便的删除和修改的API，是上层对ContentProvider进行操作一个重要对象，需要仔细掌握（Cursor还可以绑定到view上，直接送显，
并与用户进行交互，真是程序越往上，封装越好，工作越机械没有复杂性了...）。
数据模型
在与界面打交道的Cursor、ContentResolver等数据操作层中，大量采用观察者模式建立数据层与显示层的联系。一
个显示层的视图，可以做成某一种观察者注册到Cursor或ContentResolver等数据中间层中，在实现底层ContentProvider
中，我们需要特别注意在对数据进行修改操作（包括增删改...）后，调用相应类型的notify函数，帮助表层对象进行刷新（还有一种刷新方式是从一个
view发起的）。可以看到
Android的整体数据显示框架有点像MVC的方式（贫瘠了...叫不出名）。Cursor、ContentResolver相当于控制层，数据层和显
示层的交互通过控制层来掌管，而且控制层很稳定不需要特别定制，通常工作只在定制数据层和显示层空间，还是比较方便和清晰的。
一个设计问题
现在有个设计问题，比如我要扩充一个已有的ContentProvider（第三方提供），我是建立一个
ContentProvider，只保留第三方
ContentProvider的key信息，并为其添加更多的信息，在表层维护这两个ContentProvider的联系好；还是建议一个
ContentProvider，以第三方的ContentProvider做一部分底层数据源，像表层提供一个ContentProvider好。
前者无疑在实现上简单一些，如果第三方改变，灵活性也更好，只是需要仔细维护表层的相关代码。后者实现上需要付出大量的苦力劳动，当表层使用会简单多了。我举棋不定，期待你的意见。。。
