当前位置: 编程技术>移动开发
本页文章导读:
▪他们所说的、session跟cache的区别 他们所说的、session和cache的区别以前实现数据的缓存有很多种方法，有客户端的Cookie，有服务器端的Session和Application。
其中Cookie是保存在客户端的一组数据，主要用来保存用户名等个人信息.........
▪ 软件工程师面试逻辑题解析 程序员面试逻辑题解析
《程序员面试逻辑题解析》
基本信息
原书名：Puzzles for Programmers and Pro
作者： (美)Dennis E. Shasha [作译者介绍]
译者： 费若愚 朱学武
出版社：人民邮电出版社
ISBN.........
▪ 联系人信息的储存结构 联系人信息的存储结构
转载（http://www.cnblogs.com/angeldevil/archive/2011/11/23/2259336.html）联系人信息的存储结构：从Android 2.0(API Level 5)开始，Android平台提供了一个改进的Contacts API，以适应一个联.........
[1]他们所说的、session跟cache的区别
来源: 互联网 发布时间: 2014-02-18
他们所说的、session和cache的区别
以前实现数据的缓存有很多种方法，有客户端的Cookie，有服务器端的Session和Application。
其中Cookie是保存在客户端的一组数据，主要用来保存用户名等个人信息。
Session则保存对话信息。Application则是保存在整个应用程序范围内的信息，相当于全局变量。
Session
Session用来保存每一个用户的专有信息
Session的生存期是用户持续请求时间加上一段时间（一般是20分钟左右）
Session信息是保存在Web服务器内存中的，保存数据量可大可小
由于用户停止使用应用程序之后它仍在内存中存留一段时间，因此这种方法效率较低
代码：
Session[“UserID”]=”test”;
String UserName=Session[“UserID”].ToString();
Cookie
Cookie用来保存客户浏览器请求服务器页面的请求信息
我们可以存放非敏感的用户信息，保存时间可以根据需要设置
如果没有设置Cookie失效日期，它的生命周期保存到关闭浏览器为止
Cookie对象的Expires属性设置为MinValue表示永不过期
Cookie存储的数据量受限制，大多数的浏览器为4K因此不要存放大数据
由于并非所有的浏览器都支持Cookie，数据将以明文的形式保存在客户端
代码：
Resopnse.Cookies[“UserID”]=”test”;
String UserName= Resopnse.Cookies [“UserID”].ToString();
Cache
Cache用于在Http请求期间保存页面或者数据
Cache的使用可以大大的提高整个应用程序的效率
它允许将频繁访问的服务器资源存储在内存中，当用户发出相同的请求后,服务器不是再次处理而是将Cache中保存的数据直接返回给用户
可以看出Cache节省的是时间—服务器处理时间
Cache实例是每一个应用程序专有的，其生命周期==该应用程序周期
应用程序重启将重新创建其实例
注意：如果要使用缓存的清理、到期管理、依赖项等功能必须使用Insert 或者Add方法方法添加信息
代码：
Cache[”ID”]=”cc”;或者Cache.Insert(“ID”,”test”);
String ID =Cache[“ID”].ToString();
通常使用最频繁的是Session，那么Session和Cache又有什么区别呢？
Session缓存和Cache缓存的区别。
（1）最大的区别是Cache提供缓存依赖来更新数据，而Session只能依靠定义的缓存时间来判断缓存数据是否有效。
（2）即使应用程序终止，只要Cache.Add方法中定义的缓存时间未过期，下次开启应用程序时，缓存的数据依然存在。而Session缓存只是存在于一次会话中，会话结束后，数据也就失效了。
（3）Session容易丢失，导致数据的不确定性，而Cache不会出现这种情况。
（4）由于Session是每次会话就被加载，所以不适宜存放大量信息，否则会导致服务器的性能降低。而Cache则主要用来保存大容量信息，如数据库中的多个表。
（5）Session目前只能保存在内存中，对其性能有影响。
[2] 软件工程师面试逻辑题解析
来源: 互联网 发布时间: 2014-02-18
程序员面试逻辑题解析
《程序员面试逻辑题解析》
基本信息
原书名：Puzzles for Programmers and Pro
作者： (美)Dennis E. Shasha [作译者介绍]
译者： 费若愚 朱学武
出版社：人民邮电出版社
ISBN：9787115301956
上架时间：2012-12-21
出版日期：2013 年1月
开本：16开
页码：1
版次：1-1
所属分类：计算机
更多关于 》》》《程序员面试逻辑题解析》
内容简介
书籍
计算机书籍
《程序员面试逻辑题解析》共分为3 个部分。第一部分从有趣且锻炼头脑的谜题入手，继而给出解题思路和详细答案，更有“热身问题”给大家提供充分的思考空间。第二部分综合了不同类型的谜题，如数独、调度问题及概率题等。神秘的第三部分带领大家不断历险，开动脑筋，解决大量密码及银行账户等方面的问题。几十道简洁的小谜题不仅充分锻炼了我们的思维方式，更为提高面试成功率奠定了基础。
《程序员面试逻辑题解析》不仅适合程序员阅读，更是谜题爱好者的饕餮盛宴。
目录
《程序员面试逻辑题解析》
第一部分 智力游戏
第1章 竞赛——不可能都是赢家 2
1.1 甜食爱好者 3
1.2 拜占庭赌徒 5
1.3 “碰碰”运气 7
1.4 信息增益 9
1.5 直冲云霄！ 11
1.6 政治分肥 13
1.7 社会博弈 14
1.8 猫鼠游戏 17
1.9 流感中的数学 19
第2章 设计——想象力决定一切 21
2.1 冰上历险 22
2.2 最佳术语 26
2.3 巧分弹珠 28
2.4 颜色反转 30
2.5 赛程编排 31
2.6 生物中的分形学 32
2.7 轻松分馅饼 34
.第3章 运气——获得幸运之神的垂青 36
3.1 幸运赌 37
3.2 法律逻辑 39
3.3 筹码盒游戏 42
3.4 反馈系数 44
第4章 推理——你在想什么 46
4.1 数字线索 47
4.2 智力游戏 49
4.3 “拒”中生智 52
4.4 棘手的迷宫 55
4.5 疯狂配比 57
第5章 优化——达到事半功倍 59
5.1 寻找地道 60
5.2 天生一对 62
5.3 概不找零 65
5.4 寂静深海 67
第6章 前5章难题解答 68
6.1 甜食爱好者 70
6.2 拜占庭赌徒 71
6.3 “碰碰”运气 73
6.4 信息增益 75
6.5 直冲云霄！ 76
6.6 政治分肥 77
6.7 社会博弈 78
6.8 猫鼠游戏 80
6.9 流感中的数学 82
6.10 冰上历险 83
6.11 最佳术语 85
6.12 巧分弹珠 87
6.13 颜色反转 89
6.14 赛程编排 90
6.15 生物中的分形学 91
6.16 轻松分馅饼 94
6.17 幸运赌 96
6.18 法律逻辑 97
6.19 筹码盒游戏 98
6.20 反馈系数 103
6.21 数字线索 104
6.22 智力游戏 105
6.23 “拒”中生智 109
6.24 棘手的迷宫 111
6.25 疯狂配比 112
6.26 寻找地道 114
6.27 天生一对 117
6.28 概不找零 118
6.29 寂静深海 119
第二部分 解题密钥
第7章 谜题 124
7.1 年龄排位 125
7.2 城市规划 127
7.3 任务调度 129
7.4 海底寻宝 131
7.5 数独 136
7.6 数字编码 143
7.7 选择性贪心 146
7.8 最优包装 151
7.9 重温旅行推销员问题 154
7.10 超载系统的任务调度与冻结晶体 159
7.11 单词接龙 165
7.12 同盟最大化 168
7.13 决胜老虎 171
7.14 骰子的奥秘 174
7.15 西瓜还是芝麻 177
第三部分 冒险故事
第8章 忠诚的敌人 182
本图书信息来源：中国互动出版网
[3] 联系人信息的储存结构
来源: 互联网 发布时间: 2014-02-18
联系人信息的存储结构
转载（http://www.cnblogs.com/angeldevil/archive/2011/11/23/2259336.html）
联系人信息的存储结构：
从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_id1、raw_contact_id2、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中分散到各页面的东西综合了一下。有错的方希望别误导了人。
转载（http://www.cnblogs.com/angeldevil/archive/2011/11/23/2259336.html）
联系人信息的存储结构：
从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_id1、raw_contact_id2、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中分散到各页面的东西综合了一下。有错的方希望别误导了人。
最新技术文章: