j2me进度条与线程化模型.docVIP

j2me进度条与线程化模型 在j2me的UI体系中，UI操作是在一个独立的线程中运行的。往往在api doc中要求程序员对接口方法立即返回。也就是说非阻塞的。你必须开启一个独立的线程来完成你自定义的复杂的工作，比如联网等可能发生阻塞的io操作。新的线程如果不和用户交流，告诉用户线程正在工作的话，将会显现的非常不友好。用户可能执行别的操作而扰乱程序的正常运行。一个简单的方法是提供一个进度条，这样用户就会愿意等待上一会，直到程序运行出结果。为了将程序员从前台进度条与后台线程的通信中解脱出来，专心于后台线程的开发，有必要设计一个进度条线程模型。 应该注意到进度条有多种的形式： A， 动画形式进度条，仅表示程序正在运行（自维护的） B， 可交互增量形式的进度条，后台线程通过调用进度条的相应方法在程序运行中不断的改变进度条的状态 C， 进度条的表现形式应该灵活，不要固定其实现 D， 进度条对象要重复利用 进度调和后台线程的交流也有好几种情况： A， 仅仅将进度条绘画在屏幕上，并等后台任务完成后，由后台线程跳转到成功画面。 B， 对于可取消的任务，用户可以通过点击进度条的按钮来试图cancel任务，后台任务应该尽快取消，并跳转到失败的画面 C， 对于不可跳转的任务，用户只有耐心等待 D， 如果背景线程运行失败，应自行跳转到失败的屏幕 进度条的设计（前台） 为了实现进度条的表现的多样性，首先抽象一个接口： //ProgressObserver.java package com.favo.ui; import javax.microedition.lcdui.Display; /** * @author Favo * * 这是仿照Smart Ticket制作的进度条观察者，这个模型的优点是 * 1，低耦合度。你可以通过Form,Canvas等来实现这个接口 * 2，支持可中断的任务，因为背景线程是无法强制性中断的， * 所以就 没有了在观察者中回调背景线程相应方法的必要， * 如果支持可中断的话，可以让背景线程来查询观察者的isStopped() * 3，可以说进度条仅仅将自己绘画在屏幕上，他对后台线程毫不关心 */ public interface ProgressObserver { /** * 将进度条复位 */ public void reset(); /** * 将进度条设置最大 */ public void setMax(); /* * 将自己绘制在屏幕上，如果进度条要开启自身的线程用于自动更新画面， * 也在这里构造并开启绘画线程（常用于动画滚动条） */ public void show(Display display); /** * 滚动条退出命令，如果进度条曾经开启自身的线程用于自动更新画面, * （常用于动画滚动条），在这里关闭动画线程 */ public void exit(); /** * 更新进度条 */ public void updateProgress(Object param1); public boolean isStoppable(); public void setStoppable(boolean stoppable); public boolean isStopped(); public void setStopped(boolean stopped); public void setTitle(String title); public void setPrompt(String prompt); }每个方法都很一幕了然，我解释两点： 1）“2，支持可中断的任务，因为背景线程是无法强制性中断的， 所以就 没有了在观察者中回调背景线程相应方法的必要， 如果支持可中断的话，可以让背景线程来查询观察者的isStopped()” 如果要支持可中断线程的话，想当然的，我们希望用户按下按钮后回调后台线程的某个方法来停止线程，并且这个方法要立即返回（前面提过UI的用户响应不能够阻塞）。但是细细想想，线程是无法被强制停止的，而且即使能够被强制停止也很不安全。所以这个方法也只能够是通过设置某个flag,然后立即返回。这样的话线程就和前台的UI紧密的耦合在一起了。与其这样，倒不如让后台线程去查询UI的状态。这样UI并不关心到底是谁在后台维护他状态。 2）如果要实现一个不交互动画UI，那么显然这个UI