Software designers have to make tough decisions when they select development environments for cellular-handset and PDA applications. Each of the major frameworks have their own strengths and weaknesses, whether it be Sun Microsystems' J2ME, Qualcomm's BREW, or Microsoft's .Net Mobile. Some handset manufacturers, such as Kyocera, have even opted to use a relatively unknown software platform as their development platform. So how can a software designer or the company for which he or she works select the most appropriate platform? The answer to that question can be found in the market and technology factors that are shaping today's wireless and mobile device applications.
Right now, Java-based handsets dominate the market for mobile applications. This trend reflects the continuing growth in the average revenue per user (ARPU). The steady increase in ARPU is attributed to the continued growth of Java-based services and applications for both over-the-air (OTA) application delivery to mobile devices and the back-end server systems (FIG. 1). Several major players in the handheld market, including Nokia, Ericsson, and Motorola, have chosen Java as their preferred development environment. But deploying Java applications onto mobile devices via Sun's Java 2 Platform, dubbed Micro Edition (J2ME), means facing its own challenges.
For example, a Java application may run perfectly on the desktop emulator, but fail to perform on the actual Mobile Information Device Profile (MIDP) device. As part of the J2ME architecture, the MIDP layer is a collection of Java application programming interfaces (APIs) that address user-interface, storage, and networking issues.
What makes the J2ME desktop so different from the wireless-device environment? According to Mike Wilson, Director of Product Management at Softwired AG (www.softwired-inc.ch), the causes can be found in several real-world issues:
- The device processor speed is slower than the desktop.
- The application size is too large for the device.
- Data request/response is much slower than on the desktop/LAN prototype.
- The battery drain is higher, thanks to the network communication that occurs when the Java application executes on the mobile device.
- The wireless network constantly disconnects from the device.
- Bandwidth fluctuations cause the request- or response-driven MIDI applet to be intermittently non-responsive.
At the root of most of these problems lies the unreliable nature of the wireless connection, especially compared to a traditional wired LAN. Java developers need an accepted communication model for the unreliable wireless environment. Without one, they have little choice but to spend a great deal of time testing their application on the actual mobile device.
Although it lags in terms of market share, Qualcomm's Binary Runtime Environment for Wireless (BREW) is a worthy competitor to Sun's J2ME. BREW is a very flexible platform. It encompasses both an application execution environment based on C++ and a business model for operator revenue.
Several firms have developed innovative products for the BREW platform. One example is Insignia's (www.insignia.com) Mobile Foundation Java-enabling software. This product is an extension of the BREW platform for mobile devices and supporting networks. Insignia's product supports the latest J2ME standard, while allowing BREW devices to run Java-based applications—even without the presence of a Java virtual machine (VM). Another indication of BREW's growing acceptance is the recent announcement from Oracle. It is extending its Oracle 9i Lite database to support Qualcomm's Wireless (BREW) platform.
What are the major technical advantages of BREW over J2ME? At first glance, speed might be the most obvious benefit. Because J2ME runs on a virtual machine, it requires more processing speed than BREW. Resource-restricted devices, such as cellular handsets and PDAs, have limited processing capabilities. This feature would give BREW, which runs in the native environment of the device, a definite advantage. But companies like Zucotto Wireless, InSilicon, and others have developed Java accelerator chips and core intellectual property (IP). These devices should level the playing field, at least in terms of performance.
Like .Net, though, BREW is a relative newcomer to the field of mobile application development. J2ME has a proven track record, though it also has its own problems. In contrast, BREW has yet to gain widespread acceptance. Plus, BREW was developed for Qual-comm's CDMA chip sets running on a CDMA network. For now at least, it's device dependent.
ENTER .NET AND C# One of the latest entries into the mobile-application space is Microsoft's .Net environment. For the most part, .Net competes with Sun's Java 2 Platform Enterprise Edition (J2EE) on the server side of the network. Yet the recent introduction of the .Net Mobile Development environment gives Microsoft an environment for both the PocketPC and the recently available MS Smartphone.The new environment comprises the Smart Device Extensions (SDE) for Visual Studio .Net (VS.Net) and the .Net Compact Framework (CFW). The CFW is a subset of the full desktop .Net framework. It was designed for the development of resource-constrained mobile devices. The SDE is a plug-in to VS.Net. With it, the developer can use the familiar desktop VS.Net environment.
To put it plainly, the CFW is the .Net platform for mobile devices. It supports programming languages like Visual Basic .Net (VB.Net) and C# (pronounced C Sharp). For those new to C#, a few remarks are in order.
Microsoft's C# looks a good deal like Java. It includes features like single inheritance, almost identical syntax, and a compilation to an intermediate format.
C# differs from Java in that it borrows features from Delphi. It also includes direct integration with Component Object Model (COM), which is a big benefit to Windows developers.
One of the most widely touted differences between the programming languages is that C# is compiled, while Java is interpreted. A closer looks reveals that this claim may not be entirely accurate. Java compiles to byte code, which comprises operation codes in the instruction set of the Java Virtual Machine. C# compiles to Microsoft Intermediate Language (MSIL), which was formerly known as portable binary format. This is an intermediate, assembly-like language to which all .Net languages compile.
Some have suggested that MSIL should be called "Windows byte code." It supposedly suffers from the same speed issues as Java's virtual machine. On the upside, though, the intermediate languages that are compiled to the machine code for execution at runtime share the advantage of language interoperability.
Ultimately, is Java or C# better? The answer depends on the individual's background and development needs. For a Windows programmer developing programs for the PocketPC or MS Smartphone 2002, C# offers enormous advantages (FIG. 2). It is easier to use than C++, while having more features than Visual Basic. It also appears that COM development is much easier under C#.
For the Java programmer who needs applications that are relatively platform neutral, Sun's J2ME is the answer. Java's five-year headstart over C# has also helped position J2ME and J2EE as market leaders—at least for now.
One of the biggest challenges facing J2ME is on the business side of deployment. J2ME provides a robust application execution environment on both the client and server side (J2EE) of the network. But it doesn't clearly provide a business model for operators. Conversely, BREW has a business model for certifying, downloading, and charging for content. In these times of economic uncertainty, generating revenue may be more important than having better technology. So for now, software developers should remain well versed in C++, Java, and C#.