异步查询AsyncQueryHandler的用法

AsyncQueryHandler是Handler的子类，文档上说，如果处理ContentProvider相关的内容，不用需要自行定义
一套东西，而可以简单的使用async方式。我想指代的就应该是AsyncQueryHandler类。该类是一个典型的模板类，为
ContentProvider
的增删改查提供了很好的接口，提供了一个解决架构，final了一些方法，置空了一些方法。通过派生，实例化一些方法（不是每个对
ContentProvider的处理多需要全部做增删改查，我想这也是该类默认置空一些方法而不是抽象一些方法的原因），来达到这个目的。在内部，该类
隐藏了多线程处理的细节，当你使用时，你会感觉异常便利。以query为例，你可以这么来用：
// 定义一个handler，采用的是匿名类的方式，只处理query，因此只重写了onQueryComplete函数：
queryHandler = new AsyncQueryHandler(this.getContentResolver()){ // 传入的是一个ContentResolver实例，所以必须在OnCreate后实例化该Handler类
@Override
protected void onQueryComplete(int token, Object cookie, Cursor cursor) {
        // 在这里你可以获得一个cursor和你传入的附加的token和cookie。
        // 该方法在当前线程下（如果传入的是默认的Looper话），可以自由设定UI信息
    }
};
　调用时只需要调用startQuery(int token, Object cookie, ContentURI uri,
String[] projection, String selection, String[] selectionArgs, String
sortOrder)函数即可：
queryHandler.startQuery(token, cookie, uri, projection, selection, selectionArgs, sortBy);
　　可见，该类的使用是多么简单（其实现可不会很容易，因为我尝试做了一次造车轮的工作*_*），比直接用Handler简单无数倍。但让我倍感孤
独的是，不知道是没人做异步的ContentProvider访问，还是这个类使用太过于弱智（这个使用方法可是我摸索了半天的啊，难道我真的如此的弱
@_@），抑或是大家都各有高招，从SDK到网上，没有任何关于该类的有点用的说明。而我又恰巧悲伤的发现，这个类其实有很多的问题，比如他吃掉异常，有
错误时只是简单的返回null指针（这个其实不能怪他，你可以看看这里...）；当你传一个null的ContentResolver进去的时候，没有任
何异常，只是莫名其妙的丢弃所有消息，使你陷入苦苦的等待而不知其因；更愤慨的是，他的token传递竟然有Bug（难道还是我使用不
对&_&），从startXX传入的token，到了onXXComplete里面一律变成1，而文档上明明写着两个是一个东西（我的解
决方法是用cookie做token，这个不会丢*_*）。不过我暂时还没有遗弃它的打算，虽然没人理睬，虽然有一堆问题，虽然我按图索骥造了个新轮子，
但为了节省剩下的一些无聊的工作，我决定苟且偷生了。。。
　　还是习惯性跑题了，其实，我是想通过我对这个类的无数次Debugger跟进，说说它的多线程异步处理的解决策略的。他的基本策略如下：
　　1. 当你实例化一个AsyncQueryHandler类时（包括其子类...），它会单件构造一个线程（后面会详述...），这个线程里面会构建一个消息循环。
　　2. 获得该消息循环的指针，用它做参数实例化另一个Handler类，该类为内部类。至此，就有了两个线程，各自有一个Handler来处理消息。
　　3. 当调用onXXX的时候，在XXX函数内部会将请求封装成一个内部的参数类，将其作为消息的参数，将此消息发送至另一个线程。
　　4. 在该线程的Handler中，接受该消息，并分析传入的参数，用初始化时传入的ContentResolver进行XXX操作，并返回Cursor或其他返回值。
　　5. 构造一个消息，将上述返回值以及其他相关内容绑定在该消息上，发送回主线程。
　　6. 主线程默认的AsyncQueryHandler类的handleMessage方法（可自定义，但由于都是内部类，基本没有意义...）会分析该消息，并转发给对应的onXXXComplete方法。
　　7. 用户重写的onXXXComplete方法开始工作。
　　这就是它偷偷摸摸做过的事情，基本还是很好理解的。我唯一好奇的是它的线程管理方式，我猜测他是用的单件模式。第一个
AsyncQueryHandler的实例化会导致创建一个线程，从此该线程成为不死老处男，所有的ContentResolver相关的工作，都由该线
程统一完成。个人觉得这种解决方式很赞。本来这个线程的生命周期就很难估量，并且，当你有一个ContentProvider的请求的时候，判断你会做更
多的类似操作并不过分。就算错了，花费的也只是一个不死的线程（与进程同生死共存亡...），换来的却是简单的生命周期管理和无数次线程生死开销的节约。
同时另外一个很重要的问题，他并会涉及到单件中数据同步的问题，每个类都有各自的Handler类，彼此互不干扰，分发可以分别进行。当多个数据请求的时
候，在同一个ContentResolver上进行的可能微乎其微，这就避免了堵塞。总而言之，这套解决办法和Android的整体设计算是天作之合了。

ConversationAsyncQuery asyncQuery=new ConversationAsyncQuery(getContentResolver());
asyncQuery.startQuery(0,null,Sms.CONVERSATION_URI, CONVERSATION_PROJECTIN,null,null, "date desc");

class ConversationAsyncQuery extends AsyncQueryHandler{

public ConversationAsyncQuery(ContentResolver cr) {
super(cr);
// TODO Auto-generated constructor stub
}



/**
* token 区分是那一次查询
* cookie 额外信息
* cursor 查询的结果集
*/
@Override
protected void onQueryComplete(int token, Object cookie, Cursor cursor) {

        //在此方法中对查询到的结果集进行相应处理
// TODO Auto-generated method stub
// super.onQueryComplete(token, cookie, cursor);

// Utils.printCursor(cursor);
mAdapter.changeCursor(cursor);
}



}