Wireless Software Design Techniques

Print-friendly Version

by Qusay H. Mahmoud with contributions from Nicholas Lorain
May 2002

Software developers who develop applications to run on large powerful systems become used to the luxury of virtually unlimited memory and processing power. They face a new set of obstacles when they must work within the limited resources available in mobile wireless devices, with their small screen size, memory, and processing power. Developers also face environmental challenges posed by the devices; mobility and by wireless networks, which typically offer lower bandwidth and less reliability than wired networks, These limitations require developers to think differently about user interface, processing power, memory management, and exception handling.

Consumers too have become accustomed to the power and flexibility of larger systems. Both average consumers and high-end corporate users want devices with applications that are simple, intuitive, and reliable.

Developing applications for devices with limited resources requires skillful developers who are willing to learn and understand how the wireless environment operates, and able to make intelligent decisions regarding software architecture and performance issues.

The purpose of this article is to enlighten you about concerns you should keep in mind when developing Java 2 Micro Edition (J2ME) applications. This article:

• Gives you a brief overview of the constraints on wireless applications
• Offers hints for developing applications for devices with limited resources
• Discusses the architecture of wireless applications
• Suggests ways to improve your wireless applications' performance
• Discusses the life cycle of wireless applications and highlights the importance of development and emulation environments

Constraints on Wireless Applications

The explosive growth of the market for wireless devices is stimulating widespread efforts to adapt almost any technology ever developed for desktop computers to handheld devices connected to a wireless network. The challenge is not straightforward.

First of all, wireless applications must work within the daunting constraints of the devices themselves:

• Memory: Devices such as cellular phones and two-way pagers have limited amounts of memory, obliging you to consider memory management most carefully when designing application objects.
• Processing power: Wireless devices also have limited processing power (16-bit processors are typical). You must recognize that elaborate tasks may take an unacceptable time to complete.
• Input: Input capabilities are limited. Most cell phones provide only a one-hand keypad with twelve buttons: the ten numerals, an asterisk (*), and a pound sign (#).
• Screen: The display might be as small as 96 pixels wide by 54 pixels high and 1 bit deep (black and white). The amount of information you can squeeze into such a tight screen is severely limited.

It is too easy to focus on the limitations of the devices themselves and forget that the wireless environment imposes further constraints:

• Wireless networks are unreliable and expensive, and bandwidth is low.
• They tend to experience more network errors than wired networks.
• The very mobility of wireless devices increases the risk that a connection will be lost or degraded.

In order to develop efficient and reliable wireless applications, as you plan them you need to keep these constraints in mind, asking yourself the following questions:

• What impact do devices with limited resources have on application design?
• How important is it to develop applications that are platform-independent?
• What security issues should I be aware of?

Challenges for Wireless Developers

As I mentioned earlier, developing applications for mobile wireless devices poses several challenges that developers of wireless applications should be aware of. Here I present some crucial challenges and offer hints for developers. You should prepare yourself to handle these challenges if you want your applications to function correctly in the wireless environment.

1. Transmission Errors

Messages sent over wireless links are exposed to interference (and varying delays) that can alter the content received by the user, the target device, or the server. You must ensure that your application is prepared to handle these problems. Transmission errors may occur at any point in a wireless transaction and at any point during the sending or receiving of a message. They can occur after a request has been initiated, in the middle of the transaction, or after a reply has been sent.

Wireless network protocols may be able to detect and correct some errors, but you need to come up with error-handling strategies that address all the kinds of transmission errors that are likely to occur.

2. Message latency

Message latency -- the time it takes to deliver a message -- is primarily affected by the nature of each system that handles the message, and by the processing time needed and delays that may occur at each node from origin to destination. As a developer, you need to take message latency into account, and keep the user informed of processing delays.

It is especially important to remember that a message may be delivered to a user long after the time it is sent. A long delay might be due to coverage problems or transmission errors, or the user's device might be switched off or have a dead battery. Some systems keep trying, at different times, to transmit the message until it is delivered. Other systems store the message, then deliver it when the device is reconnected to the network. Your concern here is to avoid sending stale information, or to make sure your users are aware that it is not up to date. Imagine the possible consequences of sending a stock quote that is three days old, without warning the user!

3. Security

Any information transmitted over wireless links is subject to interception. Some of that information could be sensitive, such as credit card numbers and other personal information. The solution needed really depends on the level of sensitivity. To provide a complete end-to-end security solution, you must implement it on both ends, the client and the server, and assure yourself that intermediary systems are secure as well.

One solution to consider when handling highly sensitive information is encryption: the sender encrypts the data before transmitting it over the wireless link; the authorized receiver receives the encrypted data and decrypts it using a key provided.

E-commerce applications are already successfully using the secure HypterText Transfer Protocol (HTTPS), which is HTTP over the Secure Sockets Layer (SSL) Web security protocol developer by Netscape. SSL works nicely with e-commerce and there are hopes it will be used for m-commerce as well. Sun has been working on a stripped-down version of SSL called kSSL, and has already delivered it as part of the MIDP 1.0.3 reference implementation and the J2ME Wireless Toolkit 1.0.3. You can read more about kSSL in Vipul Gupta's 2001 JavaOne presentation, Bringing Big Security to Small Devices. Quite apart from the kSSL initiative, some Java-enabled devices that support SSL are already available from NTT DoCoMo and Motorola.

Cryptography is outside the scope of this article. If you are interested in encrypting data over wireless links, I recommend that you take a look at the Bouncy Castle open source project for Lightweight Cryptography APIs for J2ME. You can find a tutorial on Bouncy Castle APIs in Chapter 12 Protecting Network Data, Jonathan Knudsen's book on wireless Java.

Hints and Guidelines

This section provides hints and guidelines you will find useful when developing wireless applications:

• Environment. Do some research up front. You must first understand the needs of your potential users and the requirements imposed by all networks and systems your application will rely on.
• Architecture. The architecture of your application is very important. No optimization techniques will make up for an ill-considered architecture. Your two most important design goals should be to minimize the amount of data transmitted over the wireless link, and to anticipate errors and handle them intelligently.
• Application partitioning. You need to think carefully when deciding which operations should be performed on the server and which on the wireless device. MIDlets allow you to locate much of an application's functionality on the device; it can retrieve data from the server efficiently, then perform calculations and display information locally. This approach can dramatically reduce costly interaction over the wireless link, but it is feasible only if the device can handle the processing your application needs to perform.
• Data representation. Data can be represented in many forms, some more compact than others. You should consider available representations and select the one that requires fewer bits to be transmitted. For example, numbers will usually be much more compact if transmitted in binary forms rather than string representations.
• Message latency. In some applications, it may be possible to do other work while a message is being processed. If the delay is appreciable -- and especially if the information is likely to go stale -- it is important to keep the user informed of progress. Design the user interface of your applications to handle message latency appropriately.
• Interface simplicity. Keep the application's interface simple enough that the user seldom needs to refer to a user manual to perform a task:
  1. Reduce the amount of information displayed on the device.
  2. Make input sequences concise so the user can accomplish tasks with the minimum number of button clicks.
  3. Offer the user selection lists.

Performance-Driven Programming

When developing applications for mobile devices with a small footprint, it is crucial to make your applications run faster. The less time your application takes to run, the happier your customers are going to be. Here are some guidelines to help you optimize performance:

• Do not initialize objects to null. That chore is handled automatically.

• Wherever possible, use local variables instead of class members. Access is quicker.

• Minimize method calls. The Java Virtual Machine (JVM) loads and stores a stack frame every time it calls a method. For example, instead of doing something like this...

  for(int i=0;i<obj.length; i++) { // do something with array elements }

  
  

  ...where the length of the array is evaluated every time the loop iterates, it is more efficient to define a local variable and call the accessor only once:

  int len = obj.length; for(int i=0; i<len; i++) { // do something with array elements }

  
  

• Minimize object creation. Object creation leads to object destruction and reduces performance. Instead, design objects that can be recycled. Instead of creating return objects inside of methods, consider passing a reference to the return object and modifying its values. For example, this code snippet...

  int len = record.length; try { for(int i=0; i<len; i++) { MyObject obj = new MyObject(); // do something with obj } } catch(Exception e) { e.printStackTrace(); }

  
  

  ... creates and destroys a new instance of MyObject every time the loop iterates. You can avoid this object churning -- continually creating and discarding objects in the memory heap -- by moving the object creation outside the loop. A more efficient way to rewrite the code above would be to create the object outside the try statement and reuse that object as follows:

  int len = record.length; MyObject obj = new MyObject(); try { for(int i=0; i<len; i++) { // do something with obj } } catch(Exception e) { e.printStackTrace(); }

  
  

  By reusing a single object instead of creating many the program uses less memory and the processor doesn't spend as much time collecting garbage.

• Avoid string concatenation. Concatenating objects with the + operator causes object creation and subsequent garbage collection, and thus chews up both memory and processor time. It is more efficient to use StringBuffer.

• Avoid synchronization. If a method takes longer than a fraction of a second to run, consider placing the call to it in a separate thread.

Development Tools

Developers usually build applications that will be deployed and run on a platform similar to the one on which it was built, tested, and evaluated. Developing wireless applications is more challenging because they will be developed on one platform (such as a Solaris or MS Windows machine) but deployed and run on a totally different platform (such as a cell phone or a PalmOS device).

The development life cycle of a wireless application comprises three steps:

1. Use your favorite development environment and tools to develop the application. There are many development environments to choose from. My favorite wireless environment is the J2ME Wireless Toolkit. It is the best environment available, with a simple and intuitive user interface that makes it easy to start developing wireless applications. More importantly, it includes several emulators for testing your applications.
2. Test the application using an emulation environment. Once you have developed the application and it compiles nicely, the next step is to test your application. The best place to test your application at this point is an emulator. The J2ME Wireless Toolkit comes with several, including Motorola i85s, PalmOS device, and RIM Blackberry.
3. Download the application to a physical device and test it on a live network. Once you are happy with the application's performance on one or more emulators, you can download it to a real device and test it there. You cannot download wireless applications over the air now, but soon you will be able to, using the Over The Air (OTA) provisioning protocol. Until then, you have two ways to download an application hosted on a remote server. You can download it through your PC connection to the Internet using the Motorola iDEN Update Software Application/Java Application Loader, or you can download your own local application to the device using the Motorola Java Application Loader Lite (JAL Lite).

Vendor-Specific Extensions

If you choose to use other development tools, you may find that they support some vendor-specific extensions to the J2ME. Extensions are not inherently bad, because they drive innovation, but you need to understand that you must choose from among three options:

1. Limit yourself to the standard set of APIs defined through the Java Community Process (JCP), to maximize chances that your applications will run as is on devices with different Java implementations.
2. Design your application in such a way that, if it is deployed on a device that doesn't support the vendor-specific extensions your application uses, it can still default to the standard set of APIs defined through the JCP. Catching exceptions is a valid way to implement this approach.
3. Make the calculated decision to develop different versions of the same application for different devices. Java makes this strategy easier than if the application was written in C or C++, but it requires you to take a coordinated approach to minimize the time spent tuning the application for different devices.

Conclusion

Mobile devices are already available, and all the necessary components and infrastructure are in place to begin developing and deploying wireless applications. This article discussed the important issues of the wireless environment you must consider when developing applications for mobile wireless devices with limited resources. It also offered hints and guidelines for dealing with the constraints imposed by the wireless environment.

In order to succeed in the wireless market, you need to develop relationships with other developers, device manufacturers, content developers, and wireless carriers. You must be prepared to take risks, but remember that the future is bright for wireless software developers, as the emphasis on Wireless Internet opportunities will continue to grow.

More Information

• Helpful hints for Application Developers and User Interface Designers using MIDP
  
  
• MIDP GUI Programming
  
  
• Wireless Java Security
  
  
• Bringing Big Security to Small Devices
  
  
• Securing J2ME Applications
  
  
• Motorola iDEN Developer Community