avaJe XE 1.0 (recently renamed SavaJe OS) is an operating system designed for mobile devices, in particular the Pocket PC-based Compaq iPAQ. The thing that makes SavaJe noteworthy is that it is the only small footprint OS that claims to be able to support the standard edition of the Java 2 JDK. In other words, SavaJe’s promise lies in its ability to run full J2SE applications in a handheld device, and saving developers the added step of porting their applications to support the J2ME, the Java environment that is optimized for small devices, although SavaJe does also support the full complement of APIs for the J2ME.
|
I will study the GUI-related classes of both AWT (Abstract Windowing Toolkit) and JFC (Java Foundation Classes) and also test the Java networking-related classes. I tested SavaJe XE 1.0 on a Compaq iPAQ 3650 Pocket PC. SavaJe currently only supports 3600, 3700, and 3800 series iPAQs. The company hopes to expand its hardware support soon.
|
Working with Flow Layout
I started my tests with the flow layout because it is the simplest and one of the most primitive methods of GUI implementation in AWT. Listing 1 (AWTDemo1.java) is a flow layout-based AWT GUI. The application contains labels, text fields, check boxes (both independent and grouped), buttons, and a drop-down list. Figure 1 shows my flow layout demo app running in normal mode on the iPAQ. Figure 2 shows the same in virtual screen mode. To see how SavaJe modified the application interface, you can compare Figure 1 with what appears on the screen of a desktop when you run the code in Listing 1.
SavaJe handled the layout of the components exactly as I expected. Flow layout imposes no restriction on placement of components, therefore SavaJe simply puts them where it can on the small screen.
| Author’s Note: In normal mode, SavaJe users can rotate the screen by 90, 180, or 270 degrees. This means users can effectively switch the horizontal and vertical axes. All screen shots in this review except Figure 2 show a virtually square screen. But the actual device screens are normally rectangular. There is a small, touch-sensitive keyboard (which my screen capture method didn’t show on the images) on the device screen just below the application interface. Therefore, the screen is actually rectangular?there is more vertical space than there is less horizontal space. If you switch the two axes, you can gain more horizontal real estate on the screen. Only Figure 2 was shot with the screen rotated into this horizontal orientation. |
As you can see in Figures 1 and 2, SavaJe gave the components the look and feel of JFC instead of AWT. In my tests, the entire suite of AWT components looked like JFC components on the SavaJe screen. This is probably because SavaJe’s engineering team wanted to keep the footprint of the J2SE implementation small and thus decided not to duplicate the look and feel of components. Implementing AWT and JFC with the same look and feel helps keep the product small and efficient. However, it shouldn’t bother Java developers too much. In fact, most Java applications built today prefer the JFC GUI over AWT, so having AWT components look like JFC components can be seen as ad advantage.
 |  |
| Figure 1.: A flow layout application in normal screen mode. | Figure 2.: A flow layout application in virtual screen mode. |
I noticed one important behavior missing on SavaJe. In most operating systems, right-clicking on a text field launches a pop-up menu for copy/cut/paste and a few other standard operations. The equivalent event of right-clicking on text in SavaJe is to hold down the pen on the screen for a few seconds. But in my tests, the right-click (pop-up menu) event never occurred.
Working with Grid Layout
The demo application in Listing 2 (AWTDemo2a.java) uses the Frame class of AWT as the main GUI (top-level) window. It creates a 4×1 grid layout and adds four panels to it, each of which contains different AWT components. The completed grid is added as the Northern component of the Frame-based GUI window. Figures 3 and 4 show the grid layout in normal and virtual screen modes, respectively.
 |  |
| Figure 3.: Depicted is a grid layout application in normal screen mode. | Figure 4.: Depicted is a grid layout application in virtual screen mode. |
All the observations that I made earlier about the flow layout application in Listing 1 are valid for this application as well. Components were displayed as I expected. In addition, I made an interesting observation that might be useful if you decide to develop for this platform: The text field in which to enter an employee name was set at 20 characters. Because of its length and the lack of horizontal space in a single cell of a 4×1 grid, SavaJe displayed the text field underneath its label (“Employee”) instead of beside it (see Figure 3). When I reduced the size of the text field from 20 characters to 15 characters, it became small enough to fit next to the “Employee” label on the same line (see Figure 5).
Listing 3 (AWTDemo2b.java) is similar to Listing 2 (AWTDemo2a.java) except that this application contains two 4×1 grids. One of the two grids is positioned as the Western component of the main frame of our GUI and the other is positioned as the Eastern component. This gives you an idea of how much lateral space is available on the small SavaJe screen (see Figure 6).
 |  |
| Figure 5.: By reducing the number of characters in the Employee text field from 20 to 15, SavaJe was able to display both the text field and label components on the same line. | Figure 6.: Depicted is a grid layout application, built with two 4×1 grids, set in a horizontal configuration, in normal screen mode. |
In contrast to Listing 2, this time the 20-character text field appeared without any distortion. Placing a grid as a Western component makes the J2SE classes think that there is more vertical space to work with for drawing on the screen. However, as you can see in Figure 6, the whole Eastern block that is supposed to reside to the right has been clipped off.
Listing 4 (AWTDemo2c.java) and its associated screen shot (Figure 7) depict the same two components, but this time the grids are positioned as Northern and Southern panels on the main frame. Everything is the same as it was before except that, once again, the 20-character text field does not appear properly in normal screen mode?it appears beneath, instead of adjacent to, its label. It has also been compressed vertically, making it virtually useless for character entry. This happened several more times when working with test apps in a vertical configuration in the normal screen mode.
 |  |
| Figure 7.: Depicted is a grid layout application, built with two 4×1 grids, set in a vertical configuration, in normal screen mode. | Figure 8.: Depicted is a 4×1 grid control along with a text area and a list in normal screen mode. |
Next I tried to squeeze some larger components on the screen. Listing 5 (AWTDemo2d.java) and its associated screen shot (Figure 8) places the same list and text areas as before on the screen, in addition to the entire 4×1 grid. Note that the scroll box component in the lower right quadrant is not displayed optimally. The left edge of the text in the scroll box (about two characters’ worth) is clipped off.
 | |
| Figure 9.: With 11 menus, this application would never be usable on SavaJe in normal screen mode. The menu labels are so overlapped so as to be unreadable. |
Java Foundation Classes and Swing
I performed two test applications in this review to demonstrate SavaJe’s handling of the JFC and Swing component libraries of J2SE.
The code in Listing 6 (SwingDemo1.java) composes an application with a menu bar, menus, menu items, and a toolbar. I included 11 menus in the menu bar, just to see what would happen. As you can see in Figure 9, SavaJe tried to display all the menus in the menu bar, but when there are too many to display in the available space, it overlays them on top of one another, abbreviating their labels until they all fit.
 | |
| Figure 10.: In virtual screen mode only, SavaJe was able to convert and display the application’s 11 menus, without causing UI headaches. |
Obviously, 11 menus is too many for the normal screen mode; the names of the menus cannot be read. If you intend for users to use your application in normal screen mode, you will have to ensure that your J2SE applications are limited to only four or five menus. However, if the user rotates the screen by 90 degrees, the interface can accommodate six or seven menus. However, the virtual screen mode works perfectly well (see Figure 10).
In Listing 7 (SwingDemo2.java), I wanted to write an application that would test SavaJe’s deftness in using colors with J2SE. Figure 11 shows the deployed code from Listing 7: the application starts with a simple button (“Change Color”).
You can change the color of the screen through a pop-up menu (shown as a box of three radio buttons in Figure 11) that appears if you hold down the pen anywhere on the screen for a few seconds. Once the pop-up menu has appeared, you can choose one of the three colors.
 | |
| Figure 11.: This simple Swing-based application, which allows the user to change the background color of the application on-the-fly, worked just fine in SavaJe. |
You can also change color of the screen by pressing the “Change Color” button. Pressing the button launches the color-picker dialog box (not shown in Figure 11), which is a standard JColorChooser class of JFC. Selecting a color and pressing OK on the color-picker dialog box, will change the color of background on the application’s main screen. The application worked perfectly well in SavaJe; no problems or issues were detected.
>Recall that in earlier tests with AWT classes, pop-up menus did not work with text fields. However, the menu in this application worked just fine, probably because this time I explicitly handled the pop-up event and drew the menu myself.
Networking-related Classes in J2SE
I tested the following networking- and I/O-related J2SE classes in SavaJe:
- ServerSocket: It properly instantiates new server sockets, listens for requests and creates Sockets reliably.
- Socket: Socket also works fine. I did not detect any problems by calling its various methods.
- Input and Output Streams: I tried various input and output streams such as FilterInputStream, BufferedOutputStream, and BufferedOutputStream. I found all read/write operations worked fine.
- File: I experienced no problem in opening files and creating File type objects.
Deployment Recommendations
The virtual mode in SavaJe is very reliable. If you have a Java application that you want your customers to use on SavaJe, just ask yourself one question: Will the users of my application like be willing to use the scroll buttons to navigate the device window across the application GUI? If the answer is yes, then you can go ahead and target your app for SavaJe devices.
But if your answer is no and you think users will not be inclined to use the virtual mode, you may want to rethink. The normal screen mode is not bad but there are plenty of situations that will flummox it. If you have more than seven menus on the application’s menu bar, you can forget using normal mode unless you redesign the application.
Apart from this, the networking- and I/O-related classes of SavaJe work perfectly and are very reliable. Moreover the performance (execution speed) of all programs that I tried was very good; comparable to what normal PC users are accustomed.
