Chinaunix首页 | 论坛 | 博客
  • 博客访问: 663399
  • 博文数量: 779
  • 博客积分: 5000
  • 博客等级: 大校
  • 技术积分: 5000
  • 用 户 组: 普通用户
  • 注册时间: 2008-10-27 13:28
文章分类

全部博文(779)

文章存档

2011年(1)

2008年(778)

我的朋友

分类:

2008-10-27 13:38:35


  在这个系列的前一篇文章里,我们在开发样本应用程序ExpensesApp时,已经介绍了J2ME的用户界面(UI)控制,持续以及记录排序API。在本文中,我们将使用记录改变通知API,改进一下ExpensesApp,使它减少对内存的需求,纠正一些数据错误。最新的ExpensesApp源代码之后,我们就可以开始了。
  通过阅读先前的部分,你可以了解这个系列:
  《探索J2ME:建立一个开销跟踪器》
  《探索J2ME:建立一个开销明细表》
  《探索J2ME:使用记录管理系统》
  《探索J2ME:记录排序》
  降低内存需求
  ExpensesApp早先的版本使用了一个向量来ExpenseInfo的实例,这些实例代表着存储在应用程序数据仓里的记录。尽管作为可管理的集合,这是一个相当简单的选择,但是向量非常耗资源。这在一个内存有限的环境下,例如移动设备上,不是件好事。
  正如你可以从Listing A上的ExpenseInfo.LoadExpenses看到的那样,Expreses MIDlet现在在内存中使用一个对象数组来存储数据库记录。有了这个改变,我就能够在ExpensesApp每次典型的运行中(启动应用程序,再加入一个新的开销)减少将近10K的内存占用。这听起来好像不多,但是当你和这样一个平台,它是以几十千字节作为总的可用内存的衡量尺度,打交道的时候,这就是个不小的数目了。而且,我还重写了重复使用双流阅读器对象的方法,而没有在循环迭代的过程中重建它们,这和以前不一样。
  
  原来的处理开销的应用程序对资源的共享做得也不好。它不响应pauseApp事件,这是在用户切到另一个应用程序时要作出的响应――清空内存。这是糟糕的网络移动设备中最差的一种。通过释放被expenseItems数组占用的内存,这个应用程序现在能够更好地处理pauseApp。这个改变也迫使了其他方面的变化:如果有必要,startApp事件处理器也必须要重建数组(Listing B)。先前的文章可以知道:startApp不仅会在MIDlet初始启动时进行,还会在从暂停转换到活动状态时进行。如果有必要的话,我们可以通过删除pauseApp里的用户接口对象来释放一些额外的内存。
  解决同步的问题
  
  先前版本的ExpensesApp除了有内存使用的问题外,还有一些数据同步的问题。你可以从上次的文章里回忆起这些,但是我已经在下面把它们列出来了,毕竟离现在已经有些日子了:
  
  关于新开销的数据不会以正确的顺序被自动加入到lsMain列表里。
  删除掉的开销项目还在用向量表示,所以仍留在内存和lsMain表单里。我在上一篇文章里解决了这个问题,方法是在每次调用cmDelete命令时重建向量,这是个开销很大的操作方法。我还使用了一个说起来有点像组装兼容机味道的方法决定新的数据在什么时候被加到数据仓里,这将肯定导致一些不需要的向量的产生。
  对开销项目的修改被折射到内存中了,而不管它们是否是对应于数据仓的。
  使用RMS的记录变更通知系统就可以很容易地解决这些数据同步的问题,这个通知系统是集成在RecordListener接口中的。让我们来仔细看看这个接口。
  
  通过RecondListener来发布记录变更通知
  现在Expenses主类实现了一个新的接口,RecordListener。这个接口提供了应用程序记录仓变化的通知。RecondListener接口有三个方法,这三个方法都接受代表记录仓和受影响记录的ID号的自变量。
  
  RecordAdded在使用RecordStore.addRecord将一条新的记录加入到记录仓时被激活。
  RecordDeleted在调用RecordStore.deleteRecord将一条记录从数据仓里删除时被激活。
  RecordChanged在使用RecordStore.updateRecord将一条记录更新时被激活。
  将一个正在执行的类传递到RecordStore的方法addRecordListener,你就能建立一个RecordListener。正如你所预料到的,多个RecordListeners可以被加入到单个的RecordStore中去。
  
  ExpensesApp在本质上使用同样的方法处理这些侦听事件中的每一件,你可以在Listing C看到。添加和删除事件处理程序清除lsMain列表的内容,然后重建expenseItems数组,最后从暂存区里取出数据重建lsMain,以反映出变化。变更事件处理器则相反,只是简单的重建expenseItems数组,因为一条更新过的记录不会影响显示在lsMain里的项目。同时因为我并不关心事件发生之外的其他任何事,所以我就不用对每次事件所收到的RecordStore和ID号自变量做任何事。
  
  除了能为保持MIDlet和本地数据仓同步提供一个简单的方法外,RecordListener API在处理能够独立地从远程数据库完成更新的应用程序时,就便显出了自己的作用。我将在探索J2ME系列的最后一部分里向你展示,这是如何通过普通连接网络完成的。
  
  本文相关连接请点
  
  
  
  
【责编:admin】

--------------------next---------------------

阅读(344) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~