我比较困惑的就是，这个蓝牙应该不会一直打开的（费电），所以如何控制好这个蓝牙的搜索？比如每分钟开10秒钟这种简单的算法可能会导致两个人永远的错过（假设他们的手机时间差10秒），又或是象以太网一样用一个随机的关闭时间，再或者是保证手机时间同步（那样用什么算法都可以了），比如可以从运营商网络那里获取时间。

有意思的是，Imity开放了手机端的源码，从这个J2ME的源码里面，可以看到蓝牙部分是通过JSR82（蓝牙接口）来实现的，看了一下，它的算法很简单，就是简单的周期性开蓝牙（类似每分钟开10秒），难道老外的手机都是缺省时间同步的吗？ 有些不解。

• 控制台（console）：大部分J2ME设备没有控制台，system.out.print的东东都会消失掉，不过Sun的模拟器倒是可以的，但毕竟是模拟器，没法进行设备上的调试。
• 文件：这个要支持JSR75的设备才行，遗憾的是，很多设备都不支持（主要是早期的）。

所以，基本的做法只能是记在内存里，需要时把这个字符串取出来显示，不过这真不是一个好的解决方法，很简单的问题，如果代码崩溃了，就看不到的了。比较理想的一个方式是蓝牙（直接在PC端看Log），不过比记文件条件更高啊，需要两端都有蓝牙，并且设备端支持JSR82（N73好像支持），但起码我的笔记本还没有蓝牙。

paint

paint相当于是个回调函数，被J2ME主线程（处理UI和事件）来调用，任何时候我们都不能自己直接调用paint，程序在paint里面按部就班的画出界面即可，paint会带一个Graphics参数，用这个graphics去作图就可以了。

现在的很多J2ME平台已经默认支持双缓冲，所以在paint执行时，实际上界面并没有画出，而是等到paint执行完成后，一次性刷新到屏幕上的，不过这是和平台相关的。

repaint

这个是通知系统，我们需要刷新界面了，但仅仅是个通知，repaint会立即返回（无阻塞），paint会在合适的时候被系统调用，所以paint和repaint不是一一对应的，有一个repaint并不意味着一定会触发一个paint，多个repaint可能会被合并到一个paint调用。

如果在paint里面调用repaint，那么就意味着这个paint结束后会被再次调用，这在有些需要连续不段的刷屏的程序中可能有用，不过显然不太合适，比如下面这种代码。

public void paint (Graphics g) {
repaint();
}

serviceRepaints

如果调用serviceRepaints，则会直接立刻重绘界面，阻塞式调用，直到paint完成。所以如果我们写出下面的paint接口：

public void paint (Graphics g) {
repaint();
serviceRepaints();
}

后果相当于递归调用，并很快造成内存耗尽（Out of memory）异常，因为serviceRepaints里面又会直接调用paint（），所以使用serviceRepaints一定要小心，可以在某些地方使用serviceRepaints，但绝不能在paint里面调用。

callSerially

这个接口可以将一个Runable的接口抛在系统队列尾部，处理完消息之后，执行这个Runable接口的run，这在有些使用paint绘制的程序中会用到，可以在paint完以后，通过callSerially触发run接口，表示界面已经画完，可以做别的事情了，又不会阻塞系统队列。

由于J2ME本身用户界面部分的代码并不复杂，因此手动用代码来实现其实也可以接受，不过如果想快速写一个程序，VMD还是蛮合适的。而且除了标准的J2ME控件外，VMD还提供了一些基于J2ME控件的Custom控件（想一想VB/Delphi都有这些），比如什么Splash/Login 等等，这些如果手动写代码还是有点麻烦的，所以想用这些的话，VMD也挺合适的。

至于使用“流程图”来代替逻辑部分的编程，显然只能对小程序适用，而恰恰很多J2ME的程序都很小，因此也可以一用。我自己试用的结果是效率是有一些提高，而且和所见即所得的界面编辑功能结合起来，还真挺方便的，印象大为改观，什么时候用这种方式“画”一个程序出来看看效果如何。

一些参考文档：

• Sun的VMD演示视频
• Exploring the NetBeans Visual Mobile Designer（这个文档有点老，对应的是Netbeans4.1，不过里面的概念可以看一看）

需求

一般来说，J2ME的GUI有两层API，一层是高级UI，提供了各种GUI控件，但是J2ME只是规定了这些控件的接口，没有规定实现，因此不同厂商的这些UI的实现有很大的差异，也就是在不同的手机上看到的UI可能会有差异，另一层是基于Canvas的低层绘图接口，这一层次上需要应用程序直接在Canvas上绘制用户界面，不提供控件功能，但是好处是在各个手机上有一致的效果。

很多应用程序希望得到这种一致的效果，但直接在Canvas上编程又太麻烦了，于是就有了各种基于Canvas的UI库，Synclast是其中的一个。

安装

在Ubuntu下，不能用apt-get来安装synclast，需要到Sourceforge上去下载（似乎已经很久没有更新版本了，最新的可下载版本还是2004年的，但直接用cvs版本的话会有不少更新），展开后的Synclast包括了源码，例子以及编译好的jar包，要安装例子程序，可以使用下面的命令：

export J2ME_HOME=/usr/local/netbeans-6.0/mobility8/WTK2.5.2/

sudo ant demo

这会将Synclast的例子程序安装到系统中去。

运行

启动Netbeans6，选择New Project中的Mobility下的Import Wireless Toolkit Project，就自然可以看到SynclastUIDemo这个工程了，创建它，剩下的工作就很简单了，直接在Sun模拟器下运行就可以看到Synclast UI的几个例子。

因为我没有用过它，所以不作评价，类似的这种UI库还有J4ME，J2ME Polish等，不过感觉还是不够多，可能和J2ME在手机应用程序领域的流行度有关。

J2ME中的UI部分，如果使用低级的Canvas来做用户界面的话，Canvas仅仅提供了一些最基本的绘图操作（线，框，填充等），要支持象按钮，列表等这些UI控件的话，不免要自己来做绘制了，这时Double Buffer就可以派上用场了。在有些平台上，Double Buffer已经内嵌就支持了，我在Sun的模拟器和N73上实测的结果是这两个平台已经都支持了Double Buffer，无需再写代码去实现额外的显示缓冲了，在Symbian S60的网站上也找到了一篇文章证实了我的猜测。
这里的一篇文章详细介绍了在使用Canvas时如何使用Double Buffer，还提供了一个动画的例子程序，这个例子代码使用了Canvas的isDoubleBuffer接口来判断一个Canvas是否已经支持了DoubleBuffer，如果不支持的话，才自己分配一个buffer来做Double Buffer，如果已经支持了，那么直接绘图就可以了。但是代码中有一个明显的bug，这句话：

g.drawImage (offscreen, 0, 0, Graphics.TOP | Graphics.RIGHT);

需要改为：

g.drawImage (offscreen, 0, 0, Graphics.TOP | Graphics.LEFT);

不过这个语句只在Canvas不支持Double buffer才用到（用于buffer的拷贝），所以在模拟器上是没有影响的，我也是为了验证double buffer的效果，特地注释了前面的isDoubleBuffer的检测（强制使用代码实现的Double Buffer）才发现这个bug。

《Beginning J2ME: From Novice to Professional》书名则要清晰的多了，从目录上看，内容也要比上本书丰富许多，包括了Core一书中没有提到的诸如蓝牙，短信，多媒体等内容，可惜在细节上下的功夫不够，我对比了两本书讲同一内容的几处章节，Core一书大多要清楚一些，所以这本书我就没怎么看了（那些蓝牙之类的章节我还没有需求）。不过在Amazon上它也是4星的评价，也算不错啦。

对比一下，好像Core一书可以说是“少而精”，而Beginning一书则相对“多而糙”，你喜欢哪种？

Connector.open通常会使得J2ME虚拟机弹出一个警告：是否连接网络？真实的手机上也会有类似的警告（比如Nokia N73）。而这个警告是需要用户选择同意的，如果在程序的主线程中执行Connector.open，由于主线程同时需要处理GUI事件，那么这里就形成一个”死锁”。

如果是用Netbeans的话，Netbeans在调试运行时，会”发现”这类主线程中的网络调用，并在调试控制台显示警告信息，提示这类调用应该在单独的线程中执行，这个比较人性化，要是它能自动实现这个单独的线程，那岂不更妙（做梦吧。。。）

/usr/local/netbeans-6.0/mobility8/WTK2.5.2/wtklib/devices

下面可以看到每种设备有一个目录，在每个目录下都有一个xxx.properties （xxx取决于设备名）文件，编辑这个文件就可以设置某类模拟器的很多细节参数，比如

设置 touch_screen = true 就可以得到一个带触摸屏的模拟器（当然要运行的程序也支持触摸屏，才能看到效果），Cool。

也许是我的PC性能不佳，也有可能是这个Nokia Emulator优化不够，又或是Windows系统有关，反正在Netbeans里面，直接调用Nokia Emulator来调试的话，肯定是Emulator连不上而超时（因为模拟器还在那慢腾腾的启动呢），如果先用一般的run模式启动模拟器运行一下midlet，然后不关闭模拟器，再选调试就可以了。

Nokia的SDK包还支持真机调试，需要在手机上装一个Debug agent，我还没有试过，不过Nokia模拟器的模拟度似乎很高，估计大部分情况时是不需要这个牛刀的。。。