The development of software applications that run on mobile wireless devices is a relatively young but growing field. The creation of these applications requires a set of skills that isn't commonly found among PC application developers. Those developers simply aren't familiar with the unique requirements posed by the mobile nature of many wireless devices. These requirements exist whether the developer is dealing with a cell phone, PDA, or other handheld device.
What do engineers list as the biggest headaches in developing wireless software applications? The 10 most common obstacles are covered below. They've been compiled from a recent survey of working professionals. By recognizing these common problem areas, developers can meet these obstacles with preparation instead of surprise.
Application PortabilityAlmost every respondent in this survey pointed to portability issues as his or her chief challenge. Senior programmers at Verizon Wireless (www.verizonwireless.com), for example, acknowledged that porting applications across multiple handsets with different screen sizes, keypad types, and processor types is a major concern. This problem is compounded further when programs must be ported across numerous carriers that each have multiple handsets. This can lead to 40 or 50 variations of the application that must be ported, notes Mike Yuen, Director of BREW Developer Relations for Qualcomm Internet Services (www.qualcomm.com). Mike sees this obstacle as more of an operational challenge than a technical problem. Wireless game developers, for example, must recognize the keypad input limits of certain handsets. While pressing multiple keys at the same time may be a feature that's supported on high-end handsets, it wouldn't work on low-end units. Resource ConstraintsCompared to the desktop-computing environment, one of the biggest differences in creating applications for mobile wireless devices is the introduction of resource constraints. Inexperienced developers often struggle with optimizing their code size to deal with constraints like limited memory size. Another example is the slower processor speed offered by lower-end handsets, which prohibits the use of applications that are based on frame rates. According to Jason Loia, Managing Director of Entertainment and Media at Lavastorm Engineering (www.lavastorm-engineering.com), "Application-size limits on lower-end devices are atrocious to work with. This is especially the case when you want to have some networking, high-quality graphics, and sound in your game." Server-Side InfrastructuresMany interactive wireless-handset applications, such as those for entertainment or office productivity, require a robust server-side component. Yet Xavier Facon, CTO for Crisp Wireless (www.crispwireless.com), points out that many developers lack the required infrastructure background, application-provisioning software, and access to messaging gateways that are needed for successful interactive programs. Several application issues are really more related to the network infrastructure. But at least developers should recognize them as concerns. Linda Everk, Broadbeam Corp.'s (www.broadbeam.com) Executive Director, Marketing, says that developers need to know how data is "pushed" (i.e., dispatched) from the server to the client when the device's IP address changes throughout the day. Other obstacles include the ease with which they can integrate existing back-end applications. Access To New DevicesDevelopment cycles for handset applications are perhaps the shortest of any mobile wireless device. New handsets are introduced to the market every three to six months. It's therefore very difficult for developers to gain early access to handsets for testing purposes. A similar argument holds true for the latest versions of popular device operating systems (OSs).Qualcomm's Mike Yuen explains that only a handful of pre-commercial handsets are available for developers. In the development of a personal-computer application, everyone has access to even the latest PC. But new cellular handsets are hard to come by. He adds that even when they are available, most pre-commercial handsets are still going through the rigors of the final hardware-debugging process. The software developer is therefore left trying to create his or her application on unstable hardware.Security IssuesApplication developers must understand the inherent security challenges of a mobile device. Chief among these limitations is the power-sensitive nature of most handsets. In response, developers must make use of computationally efficient security programs like certain types of cryptographic technologies, notes Roy Pereira, VP of Marketing and Product Management for Certicom (www.certicom.com).In addition, position-aware applications represent a growing market for wireless developers. Yet they are fraught with security issues. As Doug Peckover, President of Privacy (www.privacyinc.com), observes, "You can now track the location of mobile phones in real time." Application developers must be sensitive to the privacy needs of potential users.Of course, cellular phones aren't the only devices that need security. Perhaps data-intensive PDAs or messaging handsets have even greater needs. Mark Guibert, VP of Corporate Marketing for Research In Motion (www.rim.net), notes that it is difficult for developers to make wireless applications secure on their own. "Given the confidential nature of the data that is being transmitted to and from handhelds, the system must support end-to-end security," he concludes.Power LimitationsPower isn't just a concern for security functions. It affects all mobile wireless applications. The ever-increasing feature sets of today's handsets make power consumption and heat dissipation major concerns. As Robert DiGrazia, Director of Marketing for Alternative System Concepts (www.ascinc.com), points out, "Because software behavior can affect power via clock cycles on the processor, software designers—like their hardware counterparts—must consider power in their designs" (SEE FIGURE)."Many traditionally power-hungry applications, such as still cameras, motion videos, and games, must be redesigned for the power-budget constraints of mobile handsets," adds Bob Plunkett, Director of Product Management for QuickSilver Technology (www.qstech.com). He provides the humorous example of a video-game developer who has expectations for a 3D motion game, but only the equivalent of two AA batteries for power.TestabilityThe successful applications are those that have been thoroughly tested. Software developers often use traditional tools like simulators and emulators. But the final test must be performed on the actual device across an active wireless network.The need for on-device debugging is a major testability requirement, explains Metrowerks. According to the company, developers need full platform-awareness tools and the ability to do both run-mode and stop-mode debugging.Even where test equipment is available, problems persist. Paul Moreton, Director of Handheld Software for Mobility Electronics (www.mobilityelectronics.com), explains that sometimes the biggest challenge is determining which party is responsible for failures. If the handset application doesn't work, is it the result of a bug in the application? Or is it from a problem with the OS or the physical handset itself? RF Network IssuesA slew of challenges is brought on by using the RF connection that's inherent in wireless devices. Software developers must wrestle with issues like coverage gaps, network congestion, high network latencies, and network disconnect. They must work to make those problems invisible to the end user, observes Broadbeam's Linda Everk. She also points out that developers may have to decide how to best handle multiple network connections with minimal or no end-user intervention (e.g., GPRS, EDGE, CDMA, and 802.11).For many application developers, the variety of global wireless-network standards poses few concerns. They will be affected, however, by the fact that needed functionality may only be available via a certain wireless network. For instance, a video application may require a high-speed network with low latency and high bandwidth. In this case, a CDMA network might be preferable to a GSM connection.Language Issues One of the more subtle, yet contentious obstacles is the selection of the development language and platform. Here, the obvious issue is which language to use—be it Qualcomm's BREW, Sun's J2ME, or Microsoft's .NET. (See "Java Faces Competition From BREW and .NET," Wireless Systems Design, Nov. 2002, p. 13, www.wsdmag.com/Articles/Index.cfm?ArticleID=6750.) Some programmers have even more basic language issues. QuickSilver's Bob Plunkett laments the designers who continue to rant, "Real men write in assembly language."Knowledge ResourcesLast, but not least, are issues dealing with the developers' knowledge and availability. Paul Moreton of Mobility Electronics cautions that the learning curves for some application platforms—like Symbian—may be high. Plus, the documentation that might help shorten those learning curves isn't always available or adequate.Yet even that knowledge base won't be enough if the resources aren't available when they're needed. Dave Juitt, CTO and VP of Engineering, Bluesocket (www.bluesocket.com), notes that a major obstacle for any developer in today's wireless world is the ongoing challenge of allocating engineering resources (programmer hours). This issue is especially prevalent in the wireless market, in which technology and customer needs are ever-changing.
The list of the most common wireless-application challenges ends here. A wise man once said that recognizing obstacles was half the battle in overcoming them. Hopefully, this list will give software developers more than half a chance to create successful applications.