Serious Java Programming For The Wireless World (cont.)

When I implemented JShape, I was able to assume the user’s computing environment would meet the following criteria during runtime:

• Large Memory Space: This allows JShape to integrate third party libraries in order to provide additional functions like reports and spatial analysis. Also, the large memory space allows JShape to store and process thousands of spatial record structures in memory during runtime.
• Fast CPU: This allows JShape to perform complicated GIS map rendering (which involves lots of double/integer mathematical calculations) from the input GIS or CAD vector data.
• Big User Display: This allows JShape put more information onto one screen
• Easy User Input Method: This allows users to use the mouse and the keyboard to enter the data.
• Fast Internet Connection: This allows JShape to receive at least hundreds of KB data from web server within a reasonable time.
• Full Java Class Libraries (For examples: AWT, HTTP, Math, etc.) are supported
• Java Float and Double Data Types Supported

When I tried to port JShape to KVM devices, none of the above assumptions held true! A typical KVM device has small memory, small storage, small display, slow performance, slow network bandwidth, less functionality and input methods that are less user-friendly. To overcome these difficulties, I was forced to almost redesign KShape and MShape from scratch. The following guidelines were used to implement my KVM Programs.

Minimize The Program Size

Lesson #1: If possible, avoid integrating the third party class libraries. For example: the kAWT (a GUI toolkit library) and MathFP (a Fixed Point Integer Math library) are widely used in the Palm KVM environment. These are, however, general purpose user libraries; the program sizes and the memory requirements were too high to be used in KShape.

Lesson #2: Store the big lookup tables and data structures in the user database rather than becoming an integrated part of the program. In KVM devices, the user data is stored in a database rather than a file.

Minimize The Memory Usage

Lesson #1: The memory garbage collection functionality is not quite as robust in KVM. If possible, call the garbage collection functions manually.

Lesson #2:Dispose of the objects and close the database and network connections after they are no longer needed.

Lesson #3: Carefully design the database structures (index, linkage or fixed size records), so only required records (not the whole database) are loaded into the program memory. Since the most of KVM databases are stored on Flash Memory media, the actual data access speed difference between a record stored in the database and in the program is not distinguishable.

Efficient CPU Usage

Lesson #1: There are no Float and Double data types and mathematical functions supported in KVM. Although there are some Fixed Point Integer Math libraries available to emulate the Float and Double functions, these emulated libraries sometimes are still too costly to run on KVM devices. The solution for this was to simply (actually it was the most difficult task!) revise the program algorithm to avoid Float and Double calculation at all.

Lesson #2: Prevent CPU from performing unnecessary tasks (like data conversion). For example: most GIS or CAD data is stored in proprietary formats, and the spatial coordination information is stored as a Double data type. To keep the KVM devices from processing these complicated proprietary data formats, developers can either pre-process or let the backend application server dynamically process the complicated proprietary data formats into a simple (Integer based) standard data format which is easily accepted by KVM programs.

Efficient Internet Bandwidth Usage

Lesson #1: Normally, the internet bandwidth of KVM devices is slow. In client and server environments, always let the application server do the major data processing work so that it only transfers the requested result from the server to the KVM client.

Lesson #2: On the KVM client, implement a cache mechanism to avoid unnecessary data transfer between the server and the KVM client.

Lesson #3: A data compression mechanism can be implemented between the server and the KVM client. However, the adopted compression algorithm needs to consider the CPU overhead and the extra memory requirement factors. It almost must find an optimal balance point between them.

Efficient User Interface

Lesson #1: Try to use the Tabbed Panel (the one adopted in KShape) to put the different group information into the separated panels.

Lesson #2: Avoid the scrollable panel design, because the scrollable panel sometimes requires more memory to implement.

Lesson #3: Avoid some KVM user components (like ScrollTextBox), because they will be runtime memory hogs.

Lesson #4: Sometimes entering the user data in the KVM devices is quite a tedious task. If possible, use a selection list rather than asking users to enter the desired option.

Conclusion

KVM technology is improving so fast that each month there may be new hardware to join this family. In the near future, KVM devices may have the current PC performance and capacity, and 3G wireless network bandwidth may eventually be fast enough to support online video broadcasting. Regardless of your device capabilities or communciations bandwidth, the above KVM programming guidelines also will hold true for any compact and resource limited device.

Reference

Sun J2ME KVM web site: http://java.sun.com/products/kvm
Sun J2ME CLDC web site: http://java.sun.com/products/cldc
Sun J2ME MIDP web site: http://java.sun.com/products/midp
Java Technology Goes Wireless: http://www.sun.com/sp/features/wireless.html
Motorola iDEN Developer web site: http://www.idendev.com
JShape Software - KVM Projects: http://www.jshape.com/kvm