expensesapp早先的版本使用了一个向量来存储expenseinfo的实例，这些实例代表着存储在应用程序数据仓里的记录。尽管作为可管理的集合，这是一个相当简单的选择，但是向量非常耗资源。这在一个内存有限的环境下，例如移动设备上，不是件好事。

正如你可以从listing a上的expenseinfo.loadexpenses看到的那样，expreses midlet现在在内存中使用一个对象数组来存储数据库记录。有了这个改变，我就能够在expensesapp每次典型的运行中（启动应用程序，再加入一个新的开销）减少将近10k的内存占用。这听起来好像不多，但是当你和这样一个平台，它是以几十千字节作为总的可用内存的衡量尺度，打交道的时候，这就是个不小的数目了。而且，我还重写了重复使用双流阅读器对象的方法，而没有在循环迭代的过程中重建它们，这和以前不一样。

原来的处理开销的应用程序对资源的共享做得也不好。它不响应pauseapp事件，这是在用户切到另一个应用程序时要作出的响应――清空内存。这是糟糕的网络移动设备中最差的一种。通过释放被expenseitems数组占用的内存，这个应用程序现在能够更好地处理pauseapp。这个改变也迫使了其他方面的变化：如果有必要，startapp事件处理器也必须要重建数组（listing b）。先前的文章可以知道：startapp不仅会在midlet初始启动时进行，还会在从暂停转换到活动状态时进行。如果有必要的话，我们可以通过删除pauseapp里的用户接口对象来释放一些额外的内存。

解决同步的问题

先前版本的expensesapp除了有内存使用的问题外，还有一些数据同步的问题。你可以从上次的文章里回忆起这些，但是我已经在下面把它们列出来了，毕竟离现在已经有些日子了：

使用rms的记录变更通知系统就可以很容易地解决这些数据同步的问题，这个通知系统是集成在recordlistener接口中的。让我们来仔细看看这个接口。

通过recondlistener来发布记录变更通知

现在expenses主类实现了一个新的接口，recordlistener。这个接口提供了应用程序记录仓变化的通知。recondlistener接口有三个方法，这三个方法都接受代表记录仓和受影响记录的id号的自变量。

将一个正在执行的类传递到recordstore的方法addrecordlistener，你就能建立一个recordlistener。正如你所预料到的，多个recordlisteners可以被加入到单个的recordstore中去。

expensesapp在本质上使用同样的方法处理这些侦听事件中的每一件，你可以在listing c看到。添加和删除事件处理程序清除lsmain列表的内容，然后重建expenseitems数组，最后从暂存区里取出数据重建lsmain，以反映出变化。变更事件处理器则相反，只是简单的重建expenseitems数组，因为一条更新过的记录不会影响显示在lsmain里的项目。同时因为我并不关心事件发生之外的其他任何事，所以我就不用对每次事件所收到的recordstore和id号自变量做任何事。

除了能为保持midlet和本地数据仓同步提供一个简单的方法外，recordlistener api在处理能够独立地从远程数据库完成更新的应用程序时，就便显出了自己的作用。我将在探索j2me系列的最后一部分里向你展示，这是如何通过普通连接网络完成的。

• 关于丰搜
• 用户帮助
• 友情连接
• 意见留言
• 不良信息举报
• 免责声明

• Copyright © 2001- 2010 丰搜网 All Rights Reserved
• ICP备案编号:粤ICP备06052964号