Android的Content Provider

  Content Provider和文件、数据库、Shared Preferences这些一样，提供了一种存取数据的方式。

  Content Provide的特点就是能够面向所有应用，也就是能跨应用，因而它的访问地址是统一编址的，也就是采用“content://...”这样的形式，而且每一个地址只能由唯一的Content Provider来处理。如果有多个Provider试图对应处理同一个地址，那么在安装的时候就会失败。

  Content Provide在存取方式上采用类似数据库的接口。使用时，主要是使用ContentResolver的query/insert/update/delete方法。实现上，则可以使用数据库（使用其他方式就需要自己来组织数据了）。

  扩展ContentProvider类，在实现query/insert/update/delete这些接口时，可直接映射到SQLiteDatabase的相应方法（有点不同的是ContentProvider的insert()方法要求返回Uri）。另外，系统还提供了SQLiteOpenHelper类，对处理数据库版本变化，以及打开数据库进行了简单封装，便于使用数据库。

  getType()方法由于在ContentProvider类中是抽象方法，所以也必须实现，它主要是要与<intent-filter>中设置的data部分的mimetype一致（Intent可以通过构造函数或者setData()设置Uri类型的data）。如果使用显式调用方式，即没用到intent filter就可以解析intent的话，这个方法直接返回null其实也没啥问题。一般实现的话，如果是对应多条记录，返回“vnd.android.cursor.dir/vnd.yourcompanyname.contenttype”这样的格式，如果是单条记录的话，返回“vnd.android.cursor.item/vnd.yourcompanyname.contenttype”这样的的格式。当然本质上getType()可以返回更多的MIME类型。譬如Email应用，就可以把附件保存成文件，然后赋予其一个Uri，这样getType()可以按Uri对应的文件的文件类型返回“image/png”,"audio/midi"这些mimetype，也就可以利用不同的应用来打开这些附件了。总之，按实际使用需要来决定。

  说到Uri和文件的对应关系，还需要注意的一个方法是openFile(Uri uri, String mode)这个方法，缺省地实现是抛出FileNotFoundException。这个其实是对应ContentResolver的openInputStream(Uri uri)/openOutputStream(Uri uri)方法。也就是说Uri对应哪个文件不是系统缺省赋予的，而是ContentProvider的实现者决定的。ContentProvider类提供了一个openFileHelper()方法，如果在表里添加_data字段，并把Uri对应的文件路径存放在这个字段中，那么openFile()可以通过直接调用openFileHelper()来实现。

  另外，系统提供了许多Content Provider，譬如Media，Contact，Calendar这些，使用时需要了解相应的字段和含义。如果能够复用系统的Content Provider，也就没必要定义自己的Content Provider了，否则还需考虑如何提供Content Uri、Column Name等等。