Android 2.0之后的Contacts API--ContactsContract

联系人信息的存储结构：

从Android 2.0(API Level 5)开始，Android平台提供了一个改进的Contacts API，以适应一个联系人能够有多个账户的需求，好比说手机通信录和GMAIL通信录，两个通信录中的两条记录能够是同一我的。新的Contacts API主要是由ContactsContract及其相关的类来管理，旧的API(android.provider.Contacts）已不同意使用，但为了兼容仍可使用，只不过像之前同样，只能返回第一个账户的信息。

在新的Contacts API中，联系人数据被放到三张表中：Contacts、RawContacts和Data。这样能够帮助系统更好地存储与管理一个联系人的多个账户的信息。

Data：

Data表存储了联系人的详细信息，表中的每一行存储一个特定类型的信息，好比Email、Address或Phone。每一行经过一个mimetype_id的字段来表示该行存储的是什么类型的数据，该字段引用了mimetyps表，此表存储了经常使用的数据类型。Data表的字段主要有：

mimetype_id 表示该行存储的信息的类型
raw_contact_id 表示该行所属的RawContact
is_primary 多个data数据组成一个raw contact，该字段表示此data是不是其所属的raw contact的主data，即其display name会做为raw contact的display name
is_super_primary 该data是不是其所属的contact的主data，若是is_super_primary为1则is_primary必定为1
data1~data15 15个数据字段，对于不一样类型的信息，表示不一样的含义，ContactsContract.CommomDataKinds类中定义了与经常使用的数据类型相对应的一些类，这些类中分别定义了相应数据类型中这些字段表示的含义。通常data1表是主信息（如电话，Email地址等），data2表示副信息，data15表示Blob数据。
data_sync1~data_sync4 sync_adapter要用的字段（sync_adapter用于数据的同步，好比你手机中的Gmail账户与Google服务器的同步）。
data_version 数据的版本，用于数据的同步。

 

RawContact：

RawContact表中的一行存储Data表中一些数据行的集合及一些其余的信息，表示一个联系人某一特定账户的信息，好比Facebook或Exchange的一个联系人。

当插入一个raw contact或当一个raw contact所属的一个data改变时，系统会检查这个raw contact跟其余的raw contact是否能够匹配（好比若是两个raw contact的data包含相同的电话号码或名字），若是匹配他们就会被综合到一块儿，也就是说他们会属于同一个cantact，表现为在RawContact表中他们引用的cantact_id是同样的。

联系人姓名、组织、电话号码、Email或昵称的改变会引起raw contact的从新聚合。有两个方法控制聚合的行为Aggregaton Mode与ContactsContract.AggregationExceptions。

Aggregaton Mode：

RawContact表中有一个字段aggregation_mode，经过向特定raw contact行中插入这个字段能够修改系统对这个raw contact的聚合行为，其容许的值以下：

AGGREGATION_MODE_DEFAULT：正常模式，容许自动聚合；
AGGREGATION_MODE_DISABLE：不容许聚合；
AGGREGATION_MODE_SUSPENDED：当一个raw contact的aggregation mode修改成suspended时，若是其已经是一个已聚合的contact的一部分，那么它仍会保持与原来聚合到一块儿的raw contact的关系，即便它已改变再也不跟其余raw contact匹配。

AGGREGATIONEXCEPTIONS：

在数据库中存在一个表：agg_exceptions。经过字段raw_contact_id一、raw_contact_id二、mode存储两个raw contact聚合的方法，系统定义的聚合行为有3个：

TYPE_AUTOMATIC=0　　由系统决定聚合行为，默认值。
TYPE_KEEP_SEPARATE=2　　不聚合
TYPE_KEEP_TOGETHER=1　　聚合

 

Contact：

Contact表中的一行表示一个联系人，它是RawContact表中的一行或多行的数据的组合，这些RawContact表中的行表示同一我的的不一样的账户信息。Contact中的数据由系统组合RawContact表中的数据自动生成。

不能够直接向这个表中插入数据，当一个raw contact被插入的时候，系统会首先查找Contact表看是否有记录跟插入的raw contact表示同一我的，若是找到了，则把找到的这个contact的_ID插入raw contact记录的CONTACT_ID字段，若是没有找到，则系统自动插入一个Contact记录并把它的_ID插入新插入的raw contact的CONTACT_ID列。

Contact表中只有TIMES_CONTACTED、LAST_TIME_CONTACTED、STARRED、CUSTOM_RINGTONE、SENE_TO_VOICEMAIL列可更改，这些列的更改会致使相应的raw contact被更改。

当删除Contact表中的记录时，会删除一个联系人的全部账户的信息，也就是说，其对应的全部raw contacts也会被删除，各raw contact对应的data也就被删除了，sync adapter同步时也会删除服务器端的相应记录。

若是须要读取一个联系人的信息用CONTENT_LOOKUP_RUI代替CONTENT_URI（见后面）；

若是须要经过电话号码查找一个联系人，用PhoneLookup.CONTENT_FIILTER_URI，这个URI为这个目的进行了优化；

若是须要经过部分名字的匹配查找，用CONTENT_FILTER_URI；

若是须要经过email，address等信息查找，查找表ContactsContract.Data，结果包含contact ID，名字...

 

android.provider.ontactsContract.Data类

其定义以下：

public final static class Data implements DataColumnsWithJoins { private Data() {} public static final Uri CONTENT_URI = Uri.withAppendedPath(AUTHORITY_URI, "data"); public static final String CONTENT_TYPE = "vnd.android.cursor.dir/data"; //This flag is useful (currently) only for vCard exporter in Contacts app  public static final String FOR_EXPORT_ONLY = "for_export_only"; /*Build a CONTENT_LOOKUP_URI style Uri for the parent ContactsContract.Contacts entry of the given ContactsContract.Data entry.*/ public static Uri getContactLookupUri(ContentResolver resolver, Uri dataUri) {...}
    }

Data类定义了CONTENT_URI及CONTENT_TYPE，主要是继承了DataColumnsWithJoins接口中的字段。DataColumnsWithJoins定义以下：

protected interface DataColumnsWithJoins extends BaseColumns, DataColumns, StatusColumns,
            RawContactsColumns, ContactsColumns, ContactNameColumns, ContactOptionsColumns,
            ContactStatusColumns {
    }

该接口只是综合了一些接口，其中：

BaseColumns定义了_ID与_COUNT字段，ContentProvider查询中都要用到的字段。

DataColumns定义了与Data表中字段一一对应的常量

RawContactsColumns, ContactsColumns, ContactNameColumns, ContactOptionsColumns表示RawContact与Contact中的一些字段，定义到此类中以方便访问。

因为联系人的信息都是按类别存储到了这个Data表中，因此咱们要查找联系人的信息只须要查这个表。Data类中的Data.CONTACT_ID与Data.RAW_CONTACT_ID分别表示该表项对应的联系人在Contact与RawContract表中的ID，咱们只须要知道某一个联系人的contactId或rawContractId，并根据其查找的数据的类型就能够查到相应类型的信息。

Cursor c = getContentResolver().query(Data.CONTENT_URI, new String[] {Data._ID, Phone.NUMBER, Phone.TYPE, Phone.LABEL},
          Data.CONTACT_ID + "=?" + " AND "
                  + Data.MIMETYPE + "='" + Phone.CONTENT_ITEM_TYPE + "'", new String[] {String.valueOf(contactId)}, null);

以上代码根据联系人的contractId，并经过设置其MIMETYPE为Phone.CONTENT_ITEM_TYPE查到了该联系人的电话号码，把Data.CONTACT_ID换为Data.RAW_CONTACT_ID便可查找相应rawContactId对应的电话号码。其中用到了Phone.CONTENT_ITEM_TYPE，这是什么呢？

CommonDataKinds类

在前面讲Data表的结构时讲到，Data的data1~data15字段用于存储各种型的数据信息，那么这15个字段分别表示什么信息呢？

前面提到了，Data表中有一个mimetype_id字段，经过这个字段关联mimetypes表表示该行表明的信息类型，由于Data表中的每一行能够表示如Phone或Address等不一样类型的信息，因此对于不一样类型的信息，data1~data15这15列表示不一样的含义，若是要靠记忆记住这15列对于特定的类型分别表示什么意义天然不行，因而Google就预约义了一些类，每个类对应一些预先定义好的数据类型，在每一个类中定义了一些语义地、方便记忆的常量，用来对应这15个字段，好比在CommonDataKinds.Email类中有以下定义

public static final String ADDRESS = DATA1; public static final String DISPLAY_NAME = DATA4;

DATA1与DATA4为继承自DataColumns中的常量，在DataColumns中是这样定义的：

public static final String DATA1 = "data1"; public static final String DATA4 = "data4";

这样，当于们要查找Email地址时，只须要经过ContactsContract.CommonDataKinds.Email.ADDRESS引用，而不须要知道它是存储在Data表中的data1列中。

回到上一个问题，上面查询电话号码的例子中用到了Phone.CONTENT_ITEM_TYPE，便是表示CommonDataKinds.Phone.CONTENT_ITEM_TYPE，在Phone类中有以下定义

public static final String CONTENT_ITEM_TYPE = "vnd.android.cursor.item/phone_v2";

vnd.android.cursor.item/phone_v2 就是表示Data表中相应的行存储的是电话号码的信息，经过相应类型（如Phone、Email）的CONTENT_ITEM_TYPE，咱们就能够指定要查询的MIMETYPE，即要查询的数据类型。

其实在上面的例子中还有更简单的方法：

Cursor phone = getContentResolver().query(ContactsContract.CommonDataKinds.Phone.CONTENT_URI, new String[] { CommonDataKinds.Phone.NUMBER }, CommonDataKinds.Phone.CONTACT_ID + " =? ", new String[] { String.valueOf(contactId) }, null);

只需把query的第一个参数处传递想查找的数据类型的相应的类中的CONTENT_URI就能够了。

 

 Lookup Key

在新的Contact API中，为contact引入了lookup key的概念，当你的程序须要保存对联系人的引用时，用lookup key而别用row id，lookup key是contacts表中的一列，当你有一个lookup key时，能够这样构造一个Uri：

Uri lookupUri = Uri.withAppendedPath(Contacts.CONTENT_LOOKUP_URI, lookupKey);

而后用这个Uri查询：

Cursor c = getContentResolver().query(lookupUri, new String[]{Contacts.DISPLAY_NAME}, ...); try {
    c.moveToFirst();
    String displayName = c.getString(0);
} finally {
    c.close();
}

用lookup key 而不用row id的缘由是由于row id容易改变，用户把原先两个联系人合并成一个或由于同步的问题都会致使row id的改变。lookup key是一个字符串，它由raw contact的标识链接组成。

使用row id会比使用lookup key效率高，你能够同时保存两者，而后联合两者生成一个lookup uri：

Uri lookupUri = getLookupUri(contactId, lookupKey)

当同时有row id跟lookup key时，系统会优先以row id查询，若是无查找结果或找到的结果跟lookup key不匹配，则再用lookup key查找。

 

 

 

初学android，连android代码都没写过几行，想学习一下Contact API，发现说2.0后API改了，2.0之前的机子基本上也被淘汰了吧，就只看一下2.0之后的API吧，在网上找一点有用的资料都没有，找来找去就那几个帖子，均可以说是SDK上的例子，本想找点参考的，最后发现仍是只有SDK，看的晕头转行的，只有了一些最基本的理解，像跟IM有关的StatusColumns之类的还有Directory等就只粗略看了一眼就过去了。毕竟刚接触android，SDK的文档即便每一句话都能看懂也不太了解意思，不知道在哪用，先把看懂的记一下吧，省得之后又忘了。只是把SDK中分散到各页面的东西综合了一下。有错的方但愿别误导了人。