Since the debut of the Palm Pilot, the progress of such devices has been nothing short of breathtaking. And although most of us seem to use our PDAs as little more than glorified address books, enterprises are beginning to leverage mobile devices as a way to keep on-the-go staff connected. As users begin to demand more out of their PDAs, developers have to build more complex applications, and to do this, you must select the right platform.
Battle of the Titans
The two primary PDA development platforms are Java 2.0 Micro Edition (J2ME) and Microsoft’s .NET Framework Compact Edition. Sounds like a rehashed version of J2EE vs. .NET, right? That’s because it is.
But writing J2ME applications is quite different from writing J2SE or J2EE applications. Sun stripped so much of the functionality out of the language that it bears little resemblance to the desktop or server versions. For example, J2ME currently does not support float data types, which are often needed for mathematical calculations.
Another surprising limitation of J2ME is that it does not support JDBC. Sun explained, “The persistent storage facilities provided in the Java 2 Standard Edition (J2SE) platform, such as the JDBC and Object Serialization APIs, are not suitable for handheld devices with a small memory footprint.” The data model provided is known as the Record Management System and supports data access only through byte arrays. According to Sun, “A record is an array of bytes. You can use the DataInputStream, DataOutputStream, ByteArrayInputStream, and ByteArrayOutputStream classes to pack and unpack data types into and out of the byte arrays.” Although it does provide a way to persist data, the model is at best a hack and makes it difficult to program with.
Microsoft’s .NET Framework Compact Edition
Microsoft’s .NET Framework Compact Edition is the newcomer to this space. However, its solution is elegant insofar as it takes minimal time to make the transition from building desktop applications to building PDA applications. The differences in programming device vs. desktop applications are much more subtle in .NET than with J2ME. For example, unlike J2ME, the .NET Framework Compact Edition does not offer a ticker element: a marquee display tag available in HTML that scrolls a piece of text across the screen, looping it after the whole string has shown. But you can still implement it by deriving a class from the label and having a timer that moves the text across the label every 100 ms or so.
Figure A provides a detailed competitive analysis between these two development platforms. The information listed here will help you make an informed decision about your choice of platform.
One last metric
Sun, where is the Web services support? Microsoft’s platform offers full support for consuming Web services. Consider this scenario:
Imagine a simple location-based Web service for a field service employee armed with a mobile device. First, the employee would be working at a customer site. After finishing the job, the employee would enter the address of the next customer and get back formatted directions, which would be provided by a GPS receiver and the MapPoint .NET Web service.
In .NET, this would be straightforward. Using Visual Studio .NET and the .NET Compact Framework, the developer would design the app UI, add the reference to the Web service, and then write around 30 lines of code, which include the retrieval of location info from the GPS receiver, the call to the MapPoint .NET Web service, and finally the formatting of the output to a nice-looking UI including a DataGrid.
In J2ME, this would be difficult. Very likely, the developer would be building the application for a Palm VII or high-end cell phone, such as one provided by Nokia and would therefore use the Connected Limited Device Configuration combined with the Mobile Internet Device Profile. (This technology stack is known as CLDC/MIDP and is the most common among Java-enabled devices.) The problems with this approach are apparent from the beginning.
First, J2ME is designed to be platform independent, so the UI cannot be visual-designed unless you want to design for only one device. Even at that, concepts such as a “button” don’t exist because some devices, such as cell phones, support only soft keys and menus. As a result, the developer builds against an abstract “choice” interface that may render as a button on one device and as a menu item on another. Designing UI is likely to be a process of trial and error.
Second, accessing the GPS receiver is not supported in CLDC/MIDP. Instead, the developer would have to get a device-specific vendor library to cross the native boundary to access anything outside the limited sandbox. This not only removes portability but also results in different codebases for different devices, including different deployment mechanisms, testing matrices, etc.—thereby negating the benefit of Java’s platform independence.
Third, assuming the developer can access the GPS receiver, CLDC/MIDP does not have support for floating-point values. This means that the latitude/longitude coordinate for my office in Manhattan Beach, CA, (33.90113492833283, -118.4200642207047) would position me around 50 miles away at 33, -118, which is somewhere in the middle of the Gulf of Santa Catalina.
Finally, assuming all of the above issues are resolved, the developer still has to hand-code all of the XML, SOAP, and socket calls to actually communicate with the Web service. This alone could take days.
Making the choice
There is only one reason to choose J2ME: device independence. In my opinion, this argument holds little water because most device applications are written for a specific hardware device to accommodate differences in display size, colors, etc. Ironically, it can be argued that J2ME’s platform independence may be seen as a disadvantage: Because it is designed to be platform independent, it can’t take advantage of device-specific features, resulting in applications with minimal usability. Given this decreased usability, it is unlikely that anyone will be buying an application written in J2ME, no matter how many devices it runs on.
When comparing technologies, I often use the following metrics to compare:
- Which technology offers the cheaper alternative (measured by resources)?
- Which technology offers the faster alternative (measured by schedule)?
- Which technology offers the better alternative (measured by functionality)?
Although I would like nothing more than to throw Sun some credit, I believe that the .NET Framework Compact Edition takes the top prize.