The developers who remain chained to traditional command line interfaces can easily get lost in the details. To keep pace with the rapid changes in the marketplace, the familiar cycle of development functions (create, edit, build, integrate, deploy, run, debug, and release) must occur more quickly. Simply throwing more people at the problem only makes the process slow and complex.

Using an Integrated Development Environment (IDE), together with strong version control tools and proven Object-Oriented techniques is fundamental for the quality of the output from your team. Choose an IDE tuned for development of device applications that presents the development team with a simple, logical interface to the functions, and provides them the much needed version control elements.

The process of development follows several discrete steps. In each phase, quality tools, effective team collaboration facilities, and sound development practices can accelerate iterative development. Work to resolve issues early in order to avoid high costs and delays later in deployment.

Design for reuse

Isolation of the data that an application uses, from the business logic, and the user interface, is vital for code reuse and quality (Model, View, Controller design pattern). Write once, run anywhere (WORA) rings hollow throughout the J2ME(tm) community since each device has the features and functions (Navigation, GUI, buttons) that differentiate it from other devices (the wonders of a free enterprise system - choice).

Designing, up front, the code elements (GUI, business logic, data, class libraries) that make up an application will increase the reuse of code from project to project, and potentially from device to device. Reuse of objects from project to project across an organization is essential to reducing duplicate effort, recreating the wheel, and maintaining multiple code bases. Good reference materials on this include Michael Juntao Yuan's book on Enterprise J2ME: Developing Mobile Applications and Martin Fowler's work on refactoring.

Develop for multiple targets

Several base class libraries of various sizes designed specifically for the embedded market provide a choice when dealing with resource-constrained devices. They all provide the basic classes needed to run Java applications. Starting small and moving to larger profiles and configurations, only if necessary, keeps the footprint of the target device down.

Ensure that the profiles and configurations shipped with tools and the target runtime environment have been tested and certified to meet the specifications as defined by the Java Community Process(SM) and carry the Java Powered(tm) logo. For example, in small devices, the Constrained Limited Device Configuration (CLDC), Mobile Information Device profile (MIDP). In larger devices, the Connected Device Configuration (CDC) and Foundation profile and Personal Profile. This offers the assurance of a consistent set of APIs, regardless of how they are implemented by the JVM vendor. It does not guarantee the quality of the target environment or the portability of the application code.

For applications where the device must connect and transact OTA with enterprise systems, the use of open standards (JDBC, JMS, RMI, UDDI, SOAP, XML,...), and middleware to connect devices to data, transactions, and applications can facilitate the connection to existing sources of content and information. Also, in the development stage, maintaining a single version control database that co-ordinates the code that will be deployed to the device with the code that will be deployed to the gateway or server is needed. Once your end-to-end solution is delivered, each end knows how to talk to the other.

Deploy, then debug

Much of the code can be tested right on the development workstation and portions can be run before the program is complete. Serious application development can begin before the actual target device is available in limited supply, or even while it is still being refined.

Having an emulator for the target device that integrates with the development environment is key to building applications for PDAs and cellular handsets. The Universal Emulator Interface, as well as the eclipse.org extensible architecture has been used by PalmOne and Nokia to integrate emulators, simulators into IDEs to provide developers with the tools needed to create, test and make the application ready for over-the air (OTA) certification testing by the content aggregator, carrier or service provider.

Using an emulator or a simulator can quickly get the development team over the hurdle of ensuring that the system works inside the emulator, but is no indication that the code will work as designed and written on the target device.

For deep embedded projects (or even a Smartphone that allows a socket connection), development tools that support remote OTA debugging, as the application runs, live on the target are essential to avoiding errors in production. Finding an elusive error before millions of devices are shipped. But errors happen. Software provisioning and maintenance architectures, such as OSGi (on larger devices - CDC), can enable bundles of software to be installed, maintained and removed from a device. Systems where bundles of software can be pushed onto the device have the advantage here.

Analyze

Analyzing applications can show interesting details about application execution and memory usage, giving you critical information about the performance bottlenecks in your application. It helps the developer achieve optimum balance between speed and memory constraints. By inspecting code and profiling, you become aware of code that needs to be optimized. Profiling can also point out the "big eight" problems of application performance that can avoided up front by the use of good coding practices:

Angus McIntyre is product line manager, Embedded Java Products for IBM Pervasive (White Plains, NY)