admin 管理员组文章数量: 1086019
会话Conversation是一种新的信息组织形式,不同于“传统功能”以发件箱\收件箱\草稿箱,等文件夹的方式来组织信息,会话会把上下文相关的“往<--->来”信息组织在一起,以方便用户查看管理。所谓上下文相关是指:若某条信息是对另一条信息的‘回复’,则认为它们是上下文相关的。
Messaging应用的首页就是会话列表页面——ConversationList,它列出了用户所有往来信息,及其未发出的草稿信息,这些内容都来自于ConversationListAdapter适配器。
与会话列表相关的查询操作封装在com.android.mms.data.Conversation类中,它是查询会话信息的接口,并在必要时创建新会话(一个全新信息还未有对应的上下文信息时)。该类在应用启动的第一时刻就已经用一个后台线程开始加载会话列表了(加载到Cache中):
MmsApp.onCreate()方法调用了Conversation.init()方法,而该初始化方法是实现如下:
Java代码- public static void init(final Context context) {
- new Thread(new Runnable() {
- public void run() {
- cacheAllThreads(context);
- }
- }).start();
- }
- public static void init(final Context context) {
- new Thread(new Runnable() {
- public void run() {
- cacheAllThreads(context);
- }
- }).start();
- }
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表)中创建对应的会话记录,使其正确的显示在会话列表页面。
本文标签: 概念 方法 Conversation
版权声明:本文标题:会话Conversation的概念及其实现方法 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://roclinux.cn/b/1738237971a1948489.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
发表评论