Comparing Android and Java ME

As you have seen so far in this chapter, Android has taken a dedicated and focused approach to its mobile-platform efforts that goes beyond a simple JVM-based solution. The Android Platform comes with everything you need in a single package: the OS, device drivers, core libraries, the JNI, the optimized Dalvik VM, and the Java development environment. Developers can be assured that when they develop new applications, all key libraries will be available on the device.

Let us offer a brief overview of Java ME before comparing the two approaches. Figure 1-4 shows the availability of Java for various computing configurations. Java Platform, Standard Edition (Java SE) is suitable for desktop and workstation configurations. Java Platform, Enterprise Edition (Java EE) is designed for server configurations.

Java Platform, Micro Edition (Java ME) is an edition of Java that is pared down for smaller devices. Furthermore, two configuration sets are available for Java ME. The first configuration is called the Connected Device Configuration (CDC). Java ME for CDC involves a pared down version of Java SE with fewer packages, fewer classes within those packages, and even fewer fields and methods within those classes. For appliances and devices that are further constrained, Java defines a configuration called Connected Limited Device Configuration (CLDC). The available APIs for various Java configurations are contrasted in Figure 1-5.

Any optional packages that are installed on top of the base CDC and CLDC APIs are treated as "profiles" that are standardized using the JSR process. Each defined profile makes an additional set of APIs available to the developer.

Figure 1-4. Java computing configurations

Caution Both CLDC and CDC might support some Java APIs outside Java SE, and their classes might not start with the java.* namespace. As a consequence, if you have a Java program that runs on your desktop, there are no guarantees that it will run on devices supporting only micro editions.

Figure 1-5. Java API availability

The CLDC Java platform is hosted on a specialized and much reduced JVM called the K Virtual Machine (KVM), which is capable of running on devices whose memory is as low as 128K. (The "K" in "KVM" stands for "kilobytes.") CLDC can run additional APIs under MIDP (Mobile Information Device Profile) 2.0. This API includes a number of packages under javax.microedition.*. The key packages are MIDlets (simple applications), a UI package called LCDUI, gaming, and media.

The CDC configuration APIs include the java.awt API, the API, and more security APIs in addition to the CLDC configuration APIs. The additional profiles available on top of CDC make the javax.microedition.xlet API available to application programmers (Xlets represent applications in the CDC configuration). On top of a CDC configuration you'll find about ten more optional packages that you can run, including Bluetooth, Media API, OpenGL for Embedded Systems (OpenGL ES), Java API for XML Processing (JAXP), JAXP-RPC, Java 2D, Swing, Java Remote Method Invocation (Java RMI), and Java Database Connectivity {JDBC). Overall the Java ME specification includes more than 20 JSRs. It is also expected that JavaFX ( will play an increasing role in the mobile space for Java.

Note JavaFX is a new UI effort from Sun to dramatically improve applet-like functionality in browsers. It offers a declarative UI programming model that is also friendlier to designers. A mobile version of JavaFX is expected to be released sometime in 2009.

Now that you have a background on Java ME, look at how it compares to Android:

• Multiple device configurations: Java ME addresses two classes of micro devices and offers standardized and distinct solutions for each. Android, on the other hand, applies to just one model. It won't run on low-end devices unless or until the configurations of those devices improve.

• Ease of understanding: Because Android is geared toward only one device model, it's easier to understand than Java ME. Java ME has multiple UI models for each configuration, depending on the features supported by the device: MIDlets, Xlets, the AWT, and Swing. The JSRs for each Java ME specification are harder to follow; they take longer to mature; and finding implementations for them can be difficult.

• Responsiveness: The Dalvik VM is more optimized and more responsive compared to the standard JVM supported on a similarly configured device. You can compare the Dalvik VM to the KVM, but the KVM addresses a lower-level device with much less memory.

• Java compatibility: Because of the Dalvik VM, Android runs .dex bytecode instead of Java bytecode. This should not be a major concern as long as Java is compiled to standard Java class files. Only runtime interpretation of Java bytecode is not possible.

• Adoption: There is widespread support for Java ME on mobile devices because most mobile phones support it. But the uniformity, cost, and ease of development in Android are compelling reasons for Java developers to program for it.

• Java SE support: Compared to the support for Java SE in CDC, the Android support for Java SE is a bit more complete, except for the AWT and Swing. As we mentioned earlier, Android has its own UI approach instead. In fact, Android's declarative UI resembles the JavaFX approach.

Was this article helpful?

0 0

Post a comment