Borland’s JBuilder 5.0 Personal and Mobileset

2.3.8 Siemens Mobility Toolkit (beta)

Several challenges and uncertainties face application developers that could limit pervasive Java’s progress. However, challenges often bring new opportunities for creative research and better practices.

For practical reasons, developers extensively use a device emulator (of the type and “skin” of a target device) throughout most of an application’s development and testing cycles. This unavoidable emulation could be a major source of discrepancy between the behavior of a MIDlet running on a given device emulator and that running on an actual device, which raises a serious uncertainty problem for the J2ME developer.

Another unexpected problem facing developers is the potential difficulty in porting MIDlets across different MIDP devices. Each device manufacturer can add its OEM’s “exotic features” to MIDP in the form of an API. This has quickly led to market fragmentation, which is contrary to the portability spirit of Java. Developers will have to weigh the benefits of specializing their applications for a specific device against the ease of porting their MIDlets across multiple MIDP devices.

Developers could face another serious problem if they are unable to freely download applications to MIDP devices. Consider the wireless telecom industry. Currently, carriers attempt to stick to their business territories when they deal with pervasive Java. One legitimate goal is to increase revenue streams by selling minutes (or packets) to subscribers and businesses. Another goal is to safeguard against losing any business due to the loaded applications (imagine voice over IP over Bluetooth on the phone). Toward these goals, carriers are actively pursuing control of application distribution to their subscribers’ Java phones. Developers must follow whatever procedures the different carriers set forth to be allowed to download MIDlets to the phones. This could range from a registration requirement to signing legal contracts.

Finally, developers risk lack of support for network-side developments (especially Web services) in their development processes. Most development toolkits focus on the MIDlet client, which is certainly important. However, networked applications are bound to use a “proxy” between the MIDlets and the network resources and Web services. There is currently no support available for developers to create MIDlet proxies. Many functionalities and responsibilities of a MIDlet proxy are common or at least similar, leading to code redundancy. For example, protocol and graphics conversion are two examples of simple adaptation tasks that any MIDlet proxy will have to perform. Integrating MIDlet proxy support into J2ME Toolkits will speed up development of the full application. Of late, the JSP has proposed a Java Specification Request to address this need (JSR 172, accessible from http://jcp.org).

Over the last decade, three noteworthy trends have occurred—the intersection of which has naturally led to the development of the Microsoft .NET Compact Framework.

The first trend was the popularization of sophisticated development and runtime environments that increase developer productivity and application robustness. These environments offer features such as integrated type safety at runtime, memory management (including garbage collection), and a standardized, rich programming framework that implements commonly used functionality. Such environments become even more powerful when coupled with development tools specifically designed to host and target their complementary runtime environments. Microsoft Visual Studio .NET and the .NET Framework are such a combination, released in February 2002 and targeting Microsoft Windows. The .NET Compact Framework was a natural extension, bringing this high-productivity environment to devices with more limited resources than desktop PCs.

The second trend was the impetus to write applications that provide information and services in a wider variety of situations than previously associated with traditional PCs. Specifically, developers started writing applications targeting small devices including PDAs, mobile phones, and various other embedded devices. One major barrier for developing applications on these types of devices, however, has been the deficiency of developer skills and knowledge. Both the .NET Compact Framework and the .NET Framework are based on the ECMA Common Language Infrastructure standard (see the “What Is the CLI?” sidebar). So, both source code and compiled binaries can run across Windows-based desktops and servers and various other devices and processors, thereby offering improved productivity and efficiency. This is not to say that applications written for a server would necessarily be useful running directly on a device, but it is a testament to the portability of programming skills between these two different targets.

With its general availability in early 2003, the .NET Compact Framework will offer developers a familiar, safe, and robust programming environment that increases productivity. Developers can use skills that they deploy for desktop and server development directly on devices. Microsoft designed the .NET Compact Framework to perform optimally on resource-constrained devices and to let it call XML Web services as a central and native platform component. It will release the platform simultaneously with tools functionality in Visual Studio .NET, allowing end-to-end development for devices running Windows CE.