再议j2me进度条与线程化模型
再议j2me进度条与线程化模型
作者：FavoYang Email：favoyang@yahoo.com 欢迎交流
KeyWords：线程化模型 j2me UI设计
内容提要：
本文是《j2me进度条与线程化模型》一文的续（以后简称原文，没看过的建议看一下）。
讨论了原文中使用的线程模型的不足，并针对她的缺点提出了新的改进办法并给出了改进后的实现。因原文中UI部分有灵活的扩展性，未作更改。
版权声明：
本文同时发表在www.j2medev.com和我的Blog（blog.csdn.net/alikeboy）上，如果需要转载，有三个途径：1）联系我并经我同意；2）和www.j2medev.com有转载文章合作协议的 3）通过rss聚合我的Blog。另外转载需要全文转发(包括文章的头部)，不要断章取义。
正文：
前台UI如何和后台线程交互
原文中模型，是一个前台的PRogressGaugeUI与后台线程无关的模型。这样设计的时候最大程度上的化简了通信的复杂性，实际上是一种单方向的模型（由BackgroundTask 向 PGUI通信）。按照这种模式的要求，程序员在Override BackgroundTask 的runTask()方法时，有义务定期的去查训前台的PGUI的运行情况，并根据这种情况做出反映。这样这种模式完全相信后台线程，将是否响应用户cancel命令的权利交给了后台线程，如果后台线程陷入麻烦没有响应了（比如访问一个很昂贵的网络连接），此时用户试图cancel也没有用，程序将会暂时的死锁，直到后台线程有时间去检查前台的状态。并且在实际情况中，到底什么时候去查询，多大的频率都是问题。在代码段中过多的此类代码，会影响对正常的流程的理解。
从下面的这个顺序图，可以看到这个具体流程：
我们需要一个方法，让我们能够强制的结束Task。这个方法由背景线程自己提供，取名叫做cancel()。当然没有任何一个方法可以强迫线程立即结束（曾经有，因为安全性问题而被取消）。所以cancel()方法往往通过关闭的资源（一个连接,一个流等）来迫使runTask发生异常被中断，runTask有义务根据自己的约定捕捉此类异常并立即退出。一图胜千言，让我们看看这种方法的流程。
很显然的，关键在于前台的线程对后台的线程进行了回调，这样就可以解决问题了。但是新的问题来了，这样做迫使我们将前台与后台线程紧密的耦合在了一起（因为要回调嘛）。能不能既实现回调又避免前台UI与后台线程的紧密耦合呢？
通过Cancelable接口降低耦合度
幸好，我门可以利用接口来实现这一点。
先前的模型是这样的：
为了降低耦合，我们建立一个接口
public interface Cancelable {
/**
* 本方法非阻塞，应该立即返回（如有必要开启新的线程）
* 此外应避免对此方法的重复调用
*/
public void cancel();
}
接下来在ProgressObserver加入对这个方法的支持
public interface ProgressObserver {
……
……
/**
* 设置取消Task时回调的函数对象
* @param co
*/
public void setCancelalbeObject(Cancelable co);
}
这样，就可以在用户按下取消按钮的时候，就可以进行对Cancelable.cancel()的回调。这样灵活性大大增强了。
新代码
更新后的代码如下，除了改用以上的模型外，还对部分的BUG进行了更正，更改的地方会用不同的颜色表示。详细的用法可参见注释
点击浏览该文件
（出处：http://www.knowsky.com）