会话Conversation的概念及其实现方法

会话Conversation是一种新的信息组织形式，不同于“传统功能”以发件箱\收件箱\草稿箱，等文件夹的方式来组织信息，会话会把上下文相关的“往<--->来”信息组织在一起，以方便用户查看管理。所谓上下文相关是指：若某条信息是对另一条信息的‘回复’，则认为它们是上下文相关的。

Messaging应用的首页就是会话列表页面——ConversationList，它列出了用户所有往来信息，及其未发出的草稿信息，这些内容都来自于ConversationListAdapter适配器。

与会话列表相关的查询操作封装在com.android.mms.data.Conversation类中，它是查询会话信息的接口，并在必要时创建新会话(一个全新信息还未有对应的上下文信息时)。该类在应用启动的第一时刻就已经用一个后台线程开始加载会话列表了(加载到Cache中)：

MmsApp.onCreate()方法调用了Conversation.init()方法，而该初始化方法是实现如下：

Java代码

1. public static void init(final Context context) {
2. new Thread(new Runnable() {
3. public void run() {
4. cacheAllThreads(context);
5. }
6. }).start();
7. }

[java] view plain copy print ?

1. public static void init(final Context context) {
2. new Thread(new Runnable() {
3. public void run() {
4. cacheAllThreads(context);
5. }
6. }).start();
7. }

public static void init(final Context context) {
	new Thread(new Runnable() {
		public void run() {
			cacheAllThreads(context);
		}
	}).start();
} 

cacheAllThreads()方法是关键，它将从content://mms-sms/conversations/位置查询数据，并在查询过程中标示了正在loading的状态——mLoadingThreads=true，它将查询出来的数据构建成Conversation对象放入Cache(或更新已存在于Cache中的对象)，最后清理掉在Cache中存在，而未存在于查询结果中存在的Conversation对象(即清理无效的会话数据)。

然而令我奇怪的是，listView中显示的数据并非来自Cache中，而始于异步查询工具AsyncQueryHandler的子类ThreadListQueryHandler 它以异步方式查询并得到会话列表，该查询开始于对Conversation.startAsyncQuery()方法的调用。查询完成后，在mQueryHandler中回调了mListAdapter.changeCursor(cursor)，而此时才真正为Adapter注入了有效的Cursor对象。

草稿信息也会在会话列表中出现，因为在保存草稿信息时，WorkingMessage.saveDraft()会最终呼叫到Conversation.ensureThreadId方法，它会保证在数据表（mmssms.db中的threads表）中创建对应的会话记录，使其正确的显示在会话列表页面。