内容提要:
在手机这么小的屏幕上开发应用,难点之一就是频繁的屏幕切换。尽管midp2.0的UI部分已经很丰富了,但这些UI部件都是基于事件回调的。这在处理大量的、简单的问答式交互时显得力不从心。
本文实现了一个阻塞当前线程的对话框,简要地说,你可以使用诸如win32API中dialog函数那样的方式来实现对话框并阻塞等待返回值,然后根据返回值进行不同的处理。听起来很诱人吧。
正文:
问题何在?
首先回顾一下midp UI的事件处理机制。有两个要点:
1)首先UI部分由系统的一个线程负责维护。也就是说不能阻塞系统的事件处理方法。
2)事件处理使用的是一种回调机制。首先UI部件使用诸如setCommandListener之类的方法为自己注册一个回调接口(其中的回调方法由用户实现);等到触发了相应事件就调用这个注册好的接口的回调方法。
以下是一个实现了CommandListener的类的代码片断:
Form f=new Form("Hello world");
f.addCommand(exit);
f.setCommandListener(this);
可以想象基于事件回调的处理方式,在处理大量的、简单的问答式交互时显得力不从心。你不得不为每一个仅仅是询问要不要继续的对话框而实现一个又一个类,或者处理一个复杂的回调函数。如果选择后者,那么在一个又一个的if-else中处理不同逻辑事件的代码片断一定会烦死你。
较好的做法
这时候我们不免怀念一下win32 Api中对话框函数的处理方式:
int choose=Dialog(title,type……);
if(choose==OK){……}
else if(choose==Cancel){……}
这样处理将会阻塞当前线程,等待返回值,然后根据返回值进行处理。这样做很cool的原因就是在一个逻辑性很完整的任务中,你可以一次性在一个回调方法中完成所有逻辑,而不必为了问询简单的YES/NO问题而在不同的类中间跳来跳去。
如何在MIDP下实现
我们遇到的第一个问题来自于我们的方法必须要阻塞当前线程等待返回值。也就是说,这个对话框不能在UI的回调中直接运行,比如commandAction中。解决办法是将所有的事件处理都放到一个线程类中处理。(这是一点额外的负担,但不可避免)。还好这个工作量不大,要想实现两个对象之间的通信也不难。
第二个问题是如何阻塞当前的线程,我们祭出java线程的三板斧之wait()/notifyAll()。我们可以指定一个信号量(初值false),当其为false时阻塞当前线程,在得到用户通知后将信号量改为true,并唤醒线程。
下面看一下主要思路:
看一下代码:
如何使用
我编写了一个Test。当用户按下show按钮时,开启对话框,并将用户的选择打印出来。
屏幕快照
按下show
用户多次选择的结果
(出处:http://www.cncms.com)