he Rosicrucian Egyptian Museum in San Jose, CA displays clay tablets used by ancient Babylonians to record information. These tablets are nearly identical in size to the modern PDA. In light of this, it should not be a surprise that the convenient size of the PDA is one of the primary reasons the devices have been so rapidly accepted by today’s workforce.
With relentless technology advances, the convenient size of the modern PDA can now provide the hardware power in the PDA comparable to that of desktop, and even some server machines of a few years ago. Battery technology has also made advances?although surprisingly less rapid than other PDA components?making the current crop of PDAs able to solve an ever wider variety of problems.
|Editor’s Note: On July 12, 2002, InfoWorld reported significant security vulnerabilities in the Sharp Zaurus. While this vulnerability has no relevancy to the content and techniques provided here, we recommend that Zaurus developers read about this vulnerability. Updated August 9, 2002: Sharp has since posted a patch for this vulnerability at myzaurus.com.|
To demonstrate the Java performance improvements realized with today’s PDAs over the last five years, Table 1 shows the time differential of two platforms when transferring 850 bytes from a modem (AT&V command) and displaying it in a Java TextArea. Note that enhancements to Java technology play a more significant role than the increase the CPU performance. Performance will continue to improve with the enhancements in processing power of PDAs. Some companies have announced they will ship PDAs based on the XScale CPU operating at 400MHz this year. In addition to faster hardware Java 1.4 also provides significant performance improvements that should make their way into PDA implementations of Java.
The performance improvement achievable with today’s faster hardware can be seen in this table, which shows a simple benchmark for the transfer of 850 bytes from a modem and then displaying it in Java TextArea.
|CPU||OS||JVM||Receive & Display (ms)|
|100MHz SH3||Wince 2.0||J++ 1.1||173000|
|206MHz SA1110||Linux (2.4 kernel)||Jeode||933|
In spite of PDA advances, developing software for PDAs has traditionally been a relatively restricted exercise (compared to desktop development), often limited to using C/C++ that is tightly integrated with the PDA OS to ensure sufficient performance for end user applications. In concert with hardware advances, Java technology has made strong advances, making the PDA a remarkably suitable platform for development and deployment of Java applications.
This article discusses Java development on the recently released Sharp Zaurus SL-5500 PDA, and provides information regarding Java development on PDA devices in general. With the excellent performance of today’s PDAs, developers can leverage their Java knowledge, and much of their existing Java object libraries, to deploy great functionality on a range of portable devices.
Sweat the Little Things
My company has been doing Java development on PDAs since 1997 using virtually every Java-capable platform including the popular Compaq iPaq and now the Sharp Zaurus SL-5500. The Zaurus SL-5500 is the first PDA we have seen to date that ships with Java tightly integrated from the factory. This integration lets developers build seamless Java solutions within the framework of the PDA.
Little things make a big difference when it comes to providing a good user experience. One example is application switching. In every Java PDA we saw prior to the Zaurus, switching between applications was extremely inconvenient. For example, on the iPaq when a Java application looses focus, returning focus is not a simple one-tap operation. Returning focus to a Java app on an iPaq requires seven taps: Start | Settings | System | Memory | Running Programs |
The app-switching exercise is annoying, however an even more egregious oversight in these environments is that there is no readily visible indication that the Java app is running in the background when it loses focus. This problem is magnified because nearly every button push on a PDA will launch a new application, and thus causes a focus change.
In the line of duty, PDAs are stuffed into bags, tossed on airplane and car seats, sat on, and dropped, so it is virtually impossible to prevent the occurrence of accidental button pushes (remember this when designing your PDA applications). In one Java GPS mapping application we implemented, even after significant training, users were still starting multiple copies of the app when it lost focus. This was very problematic as the application was using the PDA serial port to read the GPS receiver, causing the all instances of the app after the first to fail when they attempted to access the serial port.
The Zaurus eliminates both of the previously mentioned problems because Java apps behave exactly like any other app. The Zaurus uses the Qtopia application environment. When a Java app is launched within the Qtopia environment, an icon is placed on the taskbar just as with any non-Java application.
This behavior is not rocket science, and it is exactly what I expected to see on PDAs years ago. Sharp, however, is the first company I have seen that managed to integrate it on a PDA. WinCE on the H/PC has this feature, but the H/PC is a different class of device than a PDA. Neither Palm4 (obviously since it is single tasking), nor PocketPC 2002 have this feature. Figure 1 shows a Zaurus with three apps running, including the Java app currently in focus. All apps have an icon on the taskbar allowing the user to switch between them by simply tapping on the icon. Should you start a Java application that is already running, the Zaurus will simply bring the running application into focus.
Rethinking The Interface And Toolset
Figure 1 may actually take you back in time a bit to the early days of AWT. Many developers have moved exclusively to Swing for Java GUI development. I expect Swing to be integrated in a future generation of PDAs, but today AWT is more appropriate. AWT earned a bad reputation because its UI is simplistic compared to other, fancier GUIs available on the desktop. Idiosyncrasies across OSs caused by using OS-native peers didn’t help either. But AWT works well in the simpler, space-constrained form factor of the PDA.
Because of limited PDA screen real screen estate, building GUI-based applications presents some unique challenges. Developers working in desktop environments have become accustomed to large displays. Creating applications on the PDA will almost always require a developer to change his way of thinking. The good news is the PDA is controlled with a stylus and is close to the user, so generous amounts of space are not required. Figure 2 shows how Personal Java on a PDA uses 50 percent less screen area than the desktop for the java.awt.FileDialog by using “OK” instead of “Open” on buttons.
On the other hand, an application designed to be used with fingertips instead of stylus will require much larger buttons. Figure 1 is an example of a ‘finger friendly’ application.
Many applications require multiple configuration parameters that ultimately won’t fit on one screen. A popular widget for implementing these is tabbed panels. I have seen some tabbed panel widgets implemented in AWT, but they are not integrated into any of the popular IDEs in use today. A simple and affective alternative is to use the java.awt.Choice component as shown in Figure 3.
With screen area at such a premium, providing functionality is an increased challenge. You can find unused areas of GUI objects to provide additional functionality. The application in Figure 1 for example, uses the lower right corner of the java.awt.TextArea to provide a ‘-‘ button to change the size of the application.
Fortunately, the Zaurus uses Personal Java instead of J2ME, which, in my opinion, is a great advantage. This allows developers to extend Java functionality using native methods, preventing the ‘it is what it is?the vendor knows best’ situation that you get with J2ME.
Having worked with Java since its inception, my opinion is that without developer access to native methods Java would have had limited market acceptance. Native methods were required for the first Java project our company worked on. Additional support of this perspective can be found looking at the existing crop of J2ME cell phones: Most J2ME implementations don’t provide access to the device phone book. Without native methods to bridge the gap, the value of Java on these phones is limited.
The Zaurus doesn’t have this restriction, so the possibilities for developers are virtually endless. For example, the application displayed in Figure 1 uses native methods to extend Java to access the RS-232 serial port.
To create native methods on the Zaurus, you typically compile native code with an ARM cross-compiler running on Linux. These compilers are free. Here’s a list of some of the ones available. The components at the time of this writing are:
A good developer knows that a good application does not guarantee success; a good user interface must accompany good application logic, functionality, and successful code execution. So, too, installation must be a snap. Typically, installing a Java app on a PDA is about as fun as getting a root canal. The Zaurus, however, provides a quick and easy installation process.
Sharp has made building installers straightforward, too. Installers can be built on Linux using the ipkg-tools. To get the tool, go to ftp://lorien.handhelds.org/pub/linux/feeds/demo and download the file named ipkg-tools.tgz. If Windows is your development platform these ipkg-tools can be run under cygwin. Gabriel Software has a Zaurus deployment feature plug-in for JBuilder .
The directory structure in Figure 4 is for a typical Java installer. Note the install location on the Zaurus is controlled by the folder location for the .desktop file. For your application to install in Applications area instead of the Jeode area, simply replace the apps/Jeode folder with apps/Applications and put the ScanChamp.desktop file in that folder. The contents of these files are described in pjava_prog-gd-020404_mk_checked_sh.pdf (or newer version) at http://developer.sharpsec.com.
There is one documentation issue related to the script file (runscanchamp, in this example) that evaded even the excellent Zaurus support team. Except for the standard script header, the content of the file is shown below (it would normally be all on one line). The documentation indicates that the XappName entry should be set to the application name. When this is done, the application icon doesn’t display on the taskbar, eliminating the entire task-switching benefits described earlier! Until this is fixed, always set XappName=$0 to have the app icon on the taskbar.
$QPEDIR/bin/evm -Xprogressbar -XappName=$0 -cp$QPEDIR/java/ScanChamp.jar:$QPEDIR/java/CS1504Com.jar:$QPEDIR/java/Serialio.jarScanChamp
Once created, IPK installer packages can be installed via USB or a network connection. Or you can simply pop the IPK file on a Compact Flash (CF) memory card, put the card in the Zaurus, and do the install with just a few stylus taps. If your application uses the built-in serial port, a CF card is very convenient. To avoid having to pop a CF memory card in and out of the device, a CF network card can be used with the “Install packages via networks” option. I routinely use 802.11b WLAN CF cards, from D-Link and Socket/Symbol for this purpose with great results.
Exorcise The RS-232 Serial Port
Many info-gadgets existed before the PDA, and none of them were very successful. Palm provided seamless connectivity, and PDAs have been a huge hit ever since. Virtually all PDAs today have an RS-232 serial port. Supporting this interface is important since there are hundreds of millions of electronic devices?computers, GPS receivers, barcode scanners, modems, digital cameras, environmental sensors, etc.?that also have RS-232 serial ports (and not USB ports). If you wish to develop applications (Java or otherwise) that communicate with the serial port, you will need to know how the port is controlled. In many designs the same physical port also provides USB-slave-mode connectivity. Vendors provide different ways of controlling the serial port. To use the port on WinCE you simply open the port when idle (i.e. no ActiveSync session). The Symbian OS provides control of the port, allowing the desktop link feature to be enabled/disabled through a native system call (even when active) or via the keyboard using Ctrl-L.
The Zaurus has multiple serial port modes. The default mode is “INIT 5,” which runs a getty daemon on the built-in serial port (/dev/ttyS0) providing a PPP connector. If you open the serial port in this mode (which the flexible architecture of Linux allows) your application can send data, but it will not receive any because the getty process gets it. To completely control the built-in serial port on the Zaurus you must ‘soft reset’ in “INIT 3” mode. To accomplish this:
- Toggle the battery cover switch on the back of the device.
- Slide open the keypad cover to display the keypad.
- Power on the Zaurus.
During the boot process you will see a ‘Wait’ message displayed followed by a number that decrements from 5. Before the number decrements to 0, press the ‘/?’ key on the keypad. This will display the following menu:
q (x): Qtopiaa (e): Linux Consolee (e): init 3 (ttyS0: -free-)r (e): init 4 (ttyS0: terminal)t (e): init 5 (ttyS0: pppd)
Press the ‘E’ key on the keypad. The device will boot with the serial port configured in INIT 3 mode (exorcised, or free of daemons as it were). This selection must be done each time the PDA is soft reset in order for the serial port to be free for your application. Resetting is not commonly required due to Linux’s stability.
|Author’s Note: To enable synchronization via USB, soft reset the Zaurus in INIT 5 mode (the default).|
I discovered a serious bug in the Zaurus related to INIT 3 mode, which affects both the consumer SL-5500 and SL-5000D developer version. When running with INIT 3 mode, the bug prevents the clock from being set, and setting any alarms in the calendar will cause the Zaurus to completely lock up. Sharp is informed of this issue and plans to fix it in a future ROM version. The bug affects ROM 2.12 (SL-5500) and ROM 1.12 & 1.13 (SL-5000D). Fortunately there is a workaround, and with the handy Zaurus keypad, it is not difficult. The fix need only be done once as it maintains itself during subsequent soft resets.
- Once booted in INIT 3 mode, switch to the “Applications” area.
- Start the “Terminal” application.
- From terminal, enter the following commands
# cd /etc/rc.d/rc3.d # ln -s ../init.d/atd S41atd # cd /etc/rc.d/init.d # ./atd start
Another option is to use a routine that I specifically created to fix this problem. Start Add/Remove Software and tap Install packages via networks. Tap the switch icon in the lower right portion of the screen, and tap New. In the Name field enter serialio.com (or some other name) and in the URL field enter http://www.serialio.com/zpkgs. Then tap or push the OK button on the Zaurus. After the Package Manager displays, double-tap the serialio-fixatd package and the package details will be displayed.
You then tap Install and the icon will indicate the package is selected for install. From here push or tap OK and you will be prompted to select an install location with RAM being the default. Choose OK and you will again see the Add/Remove Software screen; tap the X in the upper right of the screen or push the Cancel button and the package install will complete. Then go to the Jeode panel and tap the fixatd program. Once the fix is complete the program can be removed. A screen shot sequence for this process is available at http://www.serialio.com/zpkgs.
The Zaurus opens the PDA world to Java in a manner previously known only to developers and users of desktops and servers. Java on PDAs no longer needs to be restricted to the enterprise where significant developer knowledge and user training is required.