HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Your organization has decided to extend your enterprise applications into the mobile and wireless space. Congratulations! It will be an exciting time in your software development shop and your customers will no doubt be waiting with great anticipation for the results.

When I hear that organizations have decided to enter the wireless/mobile space I often think of the television commercial in which two businessmen say confidently to each other, "We can do that!" And then in the next breath they mumble, "How are we going to do that?"

If your organization has decided to enter the Java mobile and wireless arena, but you aren't sure what you're getting into, then stay tuned, because this article is for you. It discusses the two general areas to consider when entering the Java mobile and wireless technology space, which is primarily guided by the Java 2 Micro Edition (J2ME) specifications.

First, I discuss the issues involved in collecting the requirements and dealing with the user community as you plan the development of your applications. You're probably familiar with how to gather requirements and design a system with your user community when the target platforms are desktops and servers. I'll provide some real-world experiences and tips on working with your user community to scope out and design mobile and wireless applications.

Second, we examine some of the software engineering issues that go into making your application. These include issues in dealing with a limited user interface, security, data synchronization, performance, portability, application support, and configuration management. You'll encounter several if not all of these issues when you start to develop your application. At least you should know where some of the design and development "alligators" reside and have some tips on how to deal with them.

Dealing with the User Community
Java mobile and wireless applications will often work inside resource-constrained devices like cell phones and PDAs. In many cases, your user community will want to perform many of the same types of operations and communicate using the same data as when they're operating their desktop computers. The trick is fitting that functionality and data into a small device. How do you do this? By helping your customers understand this new paradigm, and allowing them to help you "shrink" the application and data into the smallest footprint possible.

Constraint Busters
Near the front of every J2ME specification is information about the types of devices that the development environment and the tools built on the specifications are meant to support. Typically, this is a list of constraints on the computing device that the J2ME specification has been specifically designed to address. The list usually includes constraints on one or more of the following:

  • Memory
  • Power
  • Connectivity
  • User interface
These will be the most frequently incurred obstacles in the development of your J2ME applications. As you prepare to design and build your application, push to find out any and all information that may challenge these constraints. Continue to ask yourself and the user community "how" types of questions.
  • How much data will actually be used to complete an operation and what data is nice to have?
  • How long will the application be used on a given day?
  • How often will the system be recharged?
  • How long between data synchronizations?
  • How convenient will it be to enter the data by keypad or Graffiti?
  • How focused will the user's attention be on the device/application?
Setting Expectations
The user community, in the span of their collective lifetime, has seen incredible advances in information systems. They now rely on laptops and desktops connected to company networks and servers for a wave of information. However, porting what might be on a desktop or server onto a Palm device will be tough.

Your first task as a new mobile/wireless architect is to get in touch with and hopefully manipulate the expectations of your user community. Early and often, you must communicate what is possible and what may be feasible but yet inappropriate for mobile/wireless technology. The key is to get the users out of the mode of expecting the next, better laptop or desktop. They've become accustomed to seeing more powerful systems and resources made available with each new platform or release of your software. At least as far as the hardware is concerned, moving to a truly mobile or wireless device will be a big step back for them. Start working on this understanding early.

Good/Bad/Ugly Mobile and Wireless Applications
J2ME mobile and wireless technology is a tool and tools can be used appropriately or inappropriately. J2ME can be used very effectively to extend enterprise information systems out to the mobile and wireless users in need of corporate data. For example, J2ME can be used effectively to put pricing calculators and updatable product catalogs in the hands of sales force personnel.

A J2ME application can also be used to coordinate the schedules and maneuvers of company personnel and equipment such as those owned by a delivery service. J2ME can provide a good platform when you need to have the client device perform an operation in both connected (usually wireless) and disconnected modes.

But J2ME has its limits. Using J2ME on a cell phone to take an entire bank loan application may be feasible, but probably not very useful. How often will a loan officer make a house call, and how easy would it be to enter all that data on a cell phone keypad? Therefore, don't just look at whether moving an enterprise application to mobile/wireless platforms is possible, look at whether it makes sense. In other words, what is the value of having the application on a mobile/wireless platform?

Device Familiarity
How many of your users currently have wireless/mobile devices? If they've never used a Palm device or only use their cell phones to make telephone calls, then it's probably a good idea to educate them to the paradigm. Operating an application running on the Palm OS or using a cell phone keypad to enter character data is different than running a Windows-based application or using a Web browser on a laptop or desktop system.

Get the targeted devices for your applications in the hands of your users early. They won't contain your application yet, but the paradigm familiarization will help you in two ways. One, users of these devices will have a better idea of how the applications on these small devices work. They'll be better equipped to help you create requirements and designs for your application. Their expectations will be easier to manage when they know more about the device and how it typically operates.

Two, once your application is fielded, more knowledgeable users will make your life infinitely easier as issues begin to manifest (as they always do) in the field. If your user community can't operate and help maintain their own devices, you'll have a much tougher time getting important diagnostic information from them.

Remember, these devices are mobile. The users will have to get software updates from you and learn how to do maintenance and support activities. The more comfortable the user community is with the device, the less time the devices spend in FedEx packages between the user community and you, and the more time they spend on the road where they provide value to the company. Give them the devices and allow them to play with the address books, calendar software, and other software already present. The more they get attached to the device, the more likely they'll want to see your application succeed.

Requirements Gathering and Design
Whether you develop formal requirements and analysis documents, or informally get your users together to determine what functionality should be in your application, make every effort to separate yourself from the lexicon and paradigm of today's desktop or laptop applications. Terms such as file, mouse, dropdown box, menu, or window may have no real equivalent in J2ME platform(s) and applications. For example, many phone and PDA devices have an operating system that has no real file system, much less a directory or file.

Start the paradigm shift right away. Don't let terms and patterns of bigger and more powerful platforms creep into your requirements and design discussions. Expectations can again be kept in check and you won't be left with the task of how to implement or mimic desktop-style functionality on a resource-constrained device.

As you gather your requirements and design your application, also consider where, not just how, your application will be used. A small device can be transported into many environments in which your applications may not be today. For example, your J2ME application may be operated by a salesperson who is seated in front of a client, or in the hands of a truck driver whose focus, hopefully, is on the road and not on the device. The device may be used in bright sunshine or in the dark. It can also be easily lost or stolen.

Most of us have been developing applications that reside on desktops and laptops that live in cubicles or offices and are operated, typically, by chairbound users. Do your requirements and application designs encompass not only the desired functionality requested by the user community, but also the surrounding environment that impacts the use of the application? For example, a lot of information in tiny font on a single screen may require more attention than the user can spare at any one time. Likewise, sales force applications that beep or make other sounds may offend prospective clients.

Explain the Limits
As you begin to understand the requirements and work with the user community to design the J2ME application, know the limitations of your target platforms and share this information with the users. If, for example, the user community wants to put a product catalog database and an application for accessing it on a PDA and you know this database is 2M larger than all the storage capacity of the biggest PDA, then share this with them. I like to tell architects to "do the math" with their users. You don't have to be a computer hardware engineer to understand that 4M of data will not fit into a system capable of holding 2M of information. They will get it and help you find ways to work within the limitations when they know what they are.

For example, in a recent project, a group of doctors helped whittle down an enormous database of clinical diagnoses used in insurance billing activities to the few hundred most often used ones. Thus they could use this application to complete more than 90% of their billings, an acceptable percentage to this group of doctors.

When you're not sure of the performance or capabilities of your device, do some quick prototyping. Wireless transmissions in connection with data synchronization are often areas that require some testing to determine if the transfer rates and processing times are acceptable. If the user community is aware of the results, they may even be prepared to put standard operating procedures in place that go into effect with the delivery of your application and the devices. For example, in another recent project, frequent (sometimes as many as three times a day) synchronization of data was required by the user in order to avoid a very time-consuming and difficult data synchronization that occurred at the end of each day. This was made part of the user documentation and enforced by the product manager.

Dealing with the Devices
Once you understand what mobile and wireless functionality you want to deploy to, your task as an architect or developer is to design and build the application. A few items that impact success and plague new mobile/wireless engineers are listed here.

The benefit of using J2ME or any micro Java environment to build your applications for mobile and wireless devices is writing software that's portable to a variety of platforms. Unlike the Java 2 Standard Edition or Java 2 Enterprise Edition, J2ME application portability requires more architectural foresightedness. A J2ME application is built on a configuration that provides the basic Java services for a large number of devices and a profile that provides for the specific needs (such as graphical user interfaces, persistent storage) of a specific set of devices such as cellular telephones and pagers. Portability across platforms served by the same configuration/profile combination is straightforward. Portability across configurations and/or profiles can be more complicated.

The user interface creates the most issues in application portability. Some of the issues surrounding user interface portability are discussed later in this article. A good measure to take, so that your applications port more easily, is to partition the application along UI and business logic boundaries. Thus the model-view-controller paradigm applies to your J2ME application as it did in your J2SE or J2EE applications.

In general, architects are left with two general approaches to dealing with issues of portability. At one extreme, the architect can choose to isolate and modularize the piece of the application that may vary across platforms. Partitioning out the UI exemplifies this type of development. Layering the application, however, can lead to more code that can cause footprint issues.

At the other extreme, the architect can choose to utilize the lowest common denominator available among the configuration/profile combinations used on the various platforms. For example, floating point numbers are not supported in the Connected Limited Device Configuration (CLDC) but are supported in the Connected Device Configuration (CDC). To avoid any potential porting issues between these two configurations, an architect taking the lowest common denominator approach would simply avoid using floating-point numbers in an application at the expense of greater functionality in larger platforms.

User Input
Given the lack of a keyboard and mouse, data entry on the small screen of many J2ME devices is a real challenge. Even though many devices now have foldout keyboards for use with their device, this type of apparatus can make the device less mobile. In most cases, user input will be handled with a pointing device like the stylus on a PDA or via a small keypad such as that found on a cell phone or pager. Many PDA devices, like Palm OS devices, offer a mechanism for capturing stylus movement over a touch-sensitive area of the display. Even these input devices can create user backlash because of the need to learn special shorthand for data entry and the difficulty the system sometimes has in interpreting some users' input.

When designing user interfaces, I encourage developers to think maximum "pokeability." In other words, attempt to create applications that can accomplish 80% or more of their operations through the touch of a single key/button or the "tap" or touch of the stylus to the screen. Where text entry is required, at least offer a virtual keyboard to allow the user to tap in characters from a keyboard-looking display shown on the screen (see Figure 1). Many of the PDAs offer this capability built into the device, but the Java environment may or may not take advantage of the feature.

Figure 1
Figure 1

Scrolling is another chore that can be a negative experience in small devices. Given the small screens, it's difficult to design user interfaces that don't require some form of scrolling. However, trying to manipulate a very small scroll bar on a small screen can be an exercise in hand-eye coordination. Horizontal scrolling should be avoided at all costs. A limited amount of vertical scrolling is tolerable, but you may want to provide "jump-to" buttons that allow for quick and easy movement in a scrolled area (see Figure 2).

Figure 2
Figure 2

In a similar light, users can easily get lost inside a J2ME application unless some forethought is given to navigational concerns. Unless you custom-build it, there are no menu bars or forward/back buttons as there are in Swing applications or Web browsers. In an application with multiple "screens," think about providing buttons/hot keys to switch to the various displays. Wherever possible, try to avoid having the user remember any data, or worse, having to compare data across screens.

User Interface
J2ME is a set of specifications for devices ranging, noninclusively, from the smart card to the laptop computer. The type and shape of user interfaces in this range of computing devices is vast. Creating the user interface is tough enough - making it portable is even tougher. Several factors should be considered when creating J2ME graphical user interfaces.

The screen size, for instance, will vary among platforms. The typical cell phone may have a screen size no larger than 9,654 pixels. The screen size of Palm OS PDA devices is 160x160 pixels. Most of the J2ME specifications don't include a layout manager to help you cope with these screen-size differences. Therefore, your code will have to serve as a layout manager. There are getWidth() and getHeight() methods that can help your code obtain the screen dimensions, but some work will be required to arrange information and UI widgets on the small screen, especially if seamless portability is required.

Also, many of today's small platform manufacturers are introducing color screens. Until the use of color in these small devices is ubiquitous, avoid the use of color in your UI. In systems that don't have color, it may be very difficult to differentiate some elements of your user interface on a screen that must attempt to gray-shade your use of color. Furthermore, many of the systems still have passive matrix displays, which can make reading some colors on the screen extremely difficult in any kind of natural light.

Finally, unlike the Swing package that universalized Java UIs on platforms that run standard Java, the widget set among the various J2ME specs and other micro Java environments vary. As suggested above, if portability is a chief concern, you may wish to seek the lowest common denominator in widget availability across the various specifications. If you wish to take advantage of more sophisticated UI widgets in higher-end devices, you'll want to isolate the user interface as a separate layer in your application so that swapping different UIs based on system capabilities does not create a wholesale application rewrite problem.

Depending on the implementation of the J2ME specification, the virtual machine may perform at one-third the speed of the standard JVMs. Given the constrained resources of the device, performance will always be a concern. Here are some performance tips to consider while building your application.

Due to resource constraints, garbage collection algorithms inside many J2ME virtual machines are not as high-performing or sophisticated as those found in larger JVMs. Therefore, some performance increase can be obtained by avoiding garbage generation. A few ideas to help with this goal:

  • Use StringBuffer for mutable strings.
  • Pool reusable instances of objects like DateFormat.
  • Use System.gc() to jump-start or push the garbage collection process.
Once you've determined that the application is working properly, compile the code with debugging information turned off. This not only increases the performance of the application, but also reduces its footprint. To compile your code with debugging information turned off, use the -g:none switch in your compile command.

Where possible, avoid deep hierarchies in your class structure to further improve your performance. Deep hierarchies require the virtual machine to load and link the superclasses.

Many third-party virtual machines generally perform many times faster than Sun's reference implementation. The options may be limited depending on your platform needs, but at least explore and consider purchasing a third-party VM.

Data Synchronization
Data synchronization deals with the management of data on different systems as if it were all on one system. In mobile/wireless applications, data will be sent to and potentially changed on a device where it must then be returned and reintegrated (synchronized) with the rest of the enterprise data. In the last few applications I've written, this functionality has made up as much as one-third of the codebase.

The first issue that must be tackled with regard to data synchronization is to determine which format will be used to exchange data between the devices and the server. XML would seem the logical choice, but it carries a price. XML impacts the size of the data transmitted and XML parsers may be too much for the allowable footprint. Small third-party parsers are now available but they'll still add to the footprint. Serialization is not available in every J2ME environment, so in many cases you may be left with simple delimited data as the means to send data.

Given an understanding of the data and how it will be transmitted between device and server, there are a number of distributed data questions that J2ME architects must resolve. Will data be locked on the server while it's used on the device? How much time does the client device have to modify the data before the server must reclaim ownership and allow others access to the data? If data is not locked, how many clients will have access to the data and what happens if both try to update it? Issues in data use and synchronization can be incredibly complex and require some extra design time.

Help is on the way. Several database vendors are offering "micro" versions of their database that not only manage persistent storage of the data, but also help perform data synchronization between the enterprise and mobile databases. However, these databases may not be available for your target platforms or may require too many resources to satisfy your needs. Also worth investigating is SyncML. SyncML (www.syncml.org) is a developing open-industry initiative for developing standards for data synchronization in both wired and wireless networks. Until third-party efforts and standards such as these are available and small enough to satisfy requirements, data synchronization will continue to occupy a large amount of design and development time.

Security Needs
In most cases, when using off-the-shelf mobile/wireless hardware, your application will utilize standard cellular telephone communication channels. These channels are open to eavesdropping and therefore theft of information. Encryption packages, such as those provided by the Legion of the Bouncy Castle (www.bouncycastle.org), can give your application 128-bit encryption if necessary - especially since many J2ME environments don't yet support SSL.

When considering the need for security, consider the possibility of loss or theft of the device. Compared to a desktop or even laptop, misplacing or stealing a cell phone or PDA is extremely easy. Therefore, you may want to consider whether the information on the device is password protected. It has been my experience that many users resist having to enter some authenticating password in order to use the applications and data on a device they soon come to view as theirs. However, these devices may contain very sensitive or important information (such as patient information or customer lists) with the wireless capability to access your enterprise systems. At least identify and analyze this risk in your requirements sessions.

Signing on may prevent unauthorized access to data in the event of loss or theft (see Figure 3).

Figure 3
Figure 3

Field Support
As your development efforts wind down, the real work in fielding and supporting your mobile/wireless application will begin. Remember, once you prepare and distribute the devices, you may never see the device again. On many of the projects that I've worked on, the mobile users were located throughout the U.S. Once they get accustomed to having the tool, they'll be reluctant to part with it to enable you to add or remove software or data. Designing and planning how to deal with deployment and maintenance issues once the system is in the field cannot be overemphasized. Some consideration and solutions should be found for the issues covered here. Experience has taught me that support has been the most difficult part of building successful systems, and is often the most overlooked part of development.

How will you provide software updates? Even the best software will have a few bugs or changes, especially in early releases. How will these be distributed to and installed on the devices? How does reference data get updated?

Reference data is data that typically doesn't change that often, but is used in running your application. Examples of reference data include lists of states and zip or area codes. Your application may include a product catalog or a list of plant locations as reference data. If this changes, how will this be updated on the devices? Data synchronization, as suggested earlier, can be used, but this may require more time and/or bandwidth than is reasonable for large sets of reference data.

How are backups of the device handled? Hopefully the users have been well trained and well disciplined enough to perform their own backups. Unfortunately, most users perform backups only after experiencing a failure that teaches them a lesson. How do catastrophic device failures get handled? Hardware does fail. If the user is able to get the hardware repaired or functioning again, will they be able to reload the applications and data on the system? If not, how will this be accomplished?

Whenever possible, build your applications in such a way that most of these issues can be handled automatically once the device synchronizes itself with your enterprise systems. This requires more work and more code on your part. Often your application must handshake with a server and both must determine what is on the device and what must be updated. More code means a larger footprint. J2ME specifications have been written to deal with some automatic updating, especially in the area of application updates through the Java Application Manager. However, J2ME is not yet equipped to deal with all types of updates.

Some of these synchronization operations will require relatively stable and good communication networks. Slow (9600bps) wireless network speeds that drop after a couple of minutes may not allow for wireless and automatic updates, backups, and complex synchronizations. Prototyping here will help you understand these types of limitations. Well-trained users, no matter what the actual mechanism for field support, will always make your job easier and provide you with alternatives when even the best-laid plans fall short in a critical event. If the users can actually help load software and data on their devices, you have a backup field support plan.

Extending your enterprise applications onto mobile and wireless devices using J2ME can be of real value to your organization. But, as we have seen, there's nothing small about building applications for cell phones, pagers, PDAs, and other such devices. In fact, there may be more issues and factors to consider as an architect of J2ME applications. As with most software development, understand the issues you may encounter and start working on them early and often.

Author Bio
James White is wireless practice manager and senior consultant for Fourth Generation, Inc., based in St. Paul, MN. He is the coauthor of Java 2 Micro Edition from Manning Publications and has written several articles on Java and object-oriented topics. Jim also speaks frequently at industry conferences and spoke on J2ME at this year's JavaOne. [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.