S60 上的那个小工具，老汉给他起了个好名字，叫 Dandy Mobile Utility，它的哥哥，是我前几年写得用于 Windows Mobile 上的一个小工具，名字叫 Dandy Mobile Kit。

DMU 的主要功能是在手机打开和关闭键盘的时候显示一条信息，使用者可以随心所欲地定制这些话，励励志什么的。后来才又发掘出去电接通振动的需求，写完给别人装上（嘿嘿，我已经发展了四五个用户了），才发现他们基本都只需要这个我认为是次要的功能。

为了这个程序能被大多数人装上，老汉使用了自己的证书来签名，免去了要把使用者的 IMEI 打到开发者证书里再签名或者让使用者自己签名的麻烦。当然也带来了开发上的不便，例如振动功能，由于要绕过正常的 CHWRMVibra 所谓的“trusted client”的限制，我不得不直接和振动服务器程序打交道。这样做的结果就是：1、即使我的程序不在前台，也可以振动；2、我会忽略用户在情景模式中禁用振动的设置。

在最开始发布的程序中，有一个 BUG。这个 BUG 的结果是，如果 DMU 运行起来，则其他使用了 CHWRMVibra 的程序将无法产生振动（系统的绝大部分程序则不受影响，因为它们必然是“可信客户”，甚至是“特权客户”而拥有抢占的权力）。我很清楚，这是因为我为了简化调用，在 DMU 中把申请振动资源和发出振动请求两步合成了一步，但是振动结束后，我没有及时释放振动资源。事实上我是写了监控振动结束的监控器的，可是现象表明它没有正常工作。这个地方，系统的实现对于振动的处理相当怪异，并不是原生地由服务器产生振动结束的活动对象事件，而是需要监控一个 RProperty 对象。

今天的代码重审让我发现了问题。我确实 new 了一个振动状态的监听器，也对于返回的各种状态做了相应的处理，在该对象的所有者的析构函数中甚至都写好了清理代码，可惜的是，唯独忘记了发起第一次监听请求。增加这一行代码后，所有的测试都过通了，这应该是一个稳定的版本了。接下来有时间的话，可能会写一个基本可用的处理配置文件的设置程序，毕竟那样会显得更友好些。