简易搜索功能小记
自从上个版本软件中加入了列表的搜索功能，现在是个列表的地方产品都要给提供搜索。
@_@
类似联系人、短信或者文件等的集合数据，用户输入关键字，然后根据标题或者内容文本去匹配。
搜索相关的问题：
- 发起搜索。
- 本地搜索。
- 请求服务器进行搜索。
- 同步搜索（单线程）。
- 异步搜索（多线程）。
- 结果分页加载。
要点1：发起搜索
搜索功能第一步就是处理用户输入，然后发起搜索。
有两种：
1、输入内容后点击搜索按钮发起搜索
这种交互比较简单，用户主动点击按钮进行搜索，可以点击返回进行取消，新的搜索请求自动取消之前的请求等。
2、输入过程中自动发起搜索
类似网页中常见的搜索功能，在输入关键字过程中会即时显示对应的搜索结果，无需等待输入完毕后主动发起搜索。
这种情况下，本地搜索，或者网络情况很好时体验还不错，但是，每次搜索都很耗时的话，输入过程中的搜索很可能就没有多少——建议了。
在监听输入框的变化时，可以避免短时间快速输入时文本变动发起不必要的搜索——因为搜索结果用户甚至来不及看，如果搜索是同步的话，那么结果的显示就会阻塞输入，或者快速输入过程中用户看到列表的闪烁。。。
所以，输入过程中进行自动搜索，需要一个延迟进行搜索的效果。 代码不复杂，但是算是一个输入体验的小细节：
//监听EditText的变化，使用handler延迟400毫秒后对搜索逻辑进行发起
onTextChanged(...) {
mTextChangeNum++;
mSearchHandler.sendEmptyMessageDelayed(1, 400);
}
//
handleMessage(Message msg...) {
mTextChangeNum--;
if (mTextChangeNum == 0) {
//说明截至目前，400毫秒内没有新的文本的变化，发起搜索
String keywords = mSearchBox.getText().toString().trim();
doSearch(keywords);
}
}
因为整个过程是在主线程中进行的，无需任何同步，通过handler进行延迟决定是否发起搜索，可以实现快速输入时——两次输入字符间隔在400毫秒内——不搜索。
要点2：异步搜索
搜索比较耗时时，如网络在线搜索，或者文件查找等，都是要考虑异步进行搜索逻辑的执行的。
如果搜索逻辑是同步执行的，那么每次发起搜索到显示搜索逻辑是一个完整的过程——没有打断。搜索时间必须短——否则卡界面。
以网络请求服务器搜索结果为例，从ui一致性的角度——搜索结果应该是用户最后输入的关键字对应的结果：
所以只有最好的网络请求需要更新数据和ui，因为总是需要对最新的搜索进行响应，异步搜索的方案就是——每次新的请求发出，就取消上一个搜索请求。
Volley中的网络请求抽象为两种状态：pending和flying。所以上一个搜索请求可能还未实际被发出，或者是在等待服务器响应中。无论哪种情况——旧的请求是一定被取消掉的。
类似Volley这样的网络框架提供了很好的api去取消已发出的网络请求——这样其结束处理也就自然消失了。其它情况下，自己通过一个主线程上标志的集合来维护各个异步请求的 “丢弃状态” ，这样，即使请求刚好返回了，那么继续回到ui部分的 “结束代码” 就可以根据状态来立即停止。 瞬时操作，需要同步的状态，保证其在ui线程被执行最好了。
OK，一句话就是异步请求时，只留最后一个请求即可——和ui保持一致。
要点3：分页和ui切换
当数据量很大时，分页是必须的。
不同于PC上的 “上一页” “下一页” 这样去查看指定页面，移动端更多是流行 “加载更多” 这样的交互方式来 不断加载新的内容。
下拉刷新去重新请求搜索，加载更多用来分页显示数据。
比较麻烦的就是页面切换了——当然体验要求是应该的： 加载中，网络错误，服务器返回错误，无数据，正常返回一些结果——这些不同的情况下，分别用不同的视图来展示给用户。