With an estimated 250 million Java-enabled handsets on the market today?a number projected to grow to 1 billion by 2006? the opportunity for wireless game developers is enormous. However, device fragmentation is the one major roadblock that could mean the difference between success and failure for developers embracing this market. Because of device fragmentation, J2ME game developers must develop code to address device-specific APIs, memory-management issues, performance differences, localization issues, screen-size variations, custom extensions, JVM implementation issues, as well as carrier-specific requirements. As a result, device programmers spend more time manually porting applications to ensure they operate across a variety of devices and less time developing new games. This article provides an in-depth look at device fragmentation. It explores the typical environment in which a mobile application must run, providing game developers with a better understanding of the causes of fragmentation and the steps they can take to address the issue.
With the promise of a billion Java-enabled wireless handsets in the market by 2006 (according to Ovum Research), the opportunities to profit from the development and sale of J2ME applications may seem limitless. Limitless, that is, until you recognize that reaching that market requires the creation of hundreds of different versions of every application to satisfy multiple device-, language-, and operator-specific requirements.
Developers and publishers know this problem by the name fragmentation. Fragmentation is the evil twin of differentiation, a term marketing managers use to explain the need to create so many different handsets. Since people want their phones to look and perform differently and generally do not want to pay for features they won't use, handset manufacturers must offer devices to satisfy every possible taste.
While differentiation may be good for handset marketers to increase sales, fragmentation is a major problem for developers. Fragmentation drives up the costs and time it takes to get an application to the mass market. Applications have to be ported from one device to another, translated from one language to another, and even customized for specific mobile operator needs. The result is often hundreds of different stock keeping units (SKUs) of the same product.
But specifically, what causes fragmentation and why can't standards be adopted to help alleviate it? Let's look at a mobile application's typical environment to understand this issue further.
By dissecting the application environment into layers, we see how each component is full of variables that can be combined in different ways. This results in significant differences that affect the application's operation. The basic layers are as follows:
Physical device characteristics
Device OS characteristics and APIs
JVM and APIs
Operator/market requirements and client/server APIs
Physical device characteristics
Similar to a PC, a mobile device has numerous elements in its physical structure that influence how an application functions. To suggest that all of these elements could be standardized is to overlook that this market is alive with constant innovation both for style and for new technology purposes. Add to that the fact that you don't have dominant players that can create defacto standards and you end up with hundreds of devices with different physical characteristics.
The chip level
At the chip level, we have elements like memory and processing speed, both of which are determined by the handset manufacturer's choice of processor. The decision of which processor to use is often based on economics and technology, as well as the rate of technology change. Chip processing speed affects how quickly the application can respond to a user's command and may limit the capability to quickly refresh the highly graphical elements of a J2ME game, for example. Both online and offline memory are also equally important and, again, establish limits for both the storage and operations of a J2ME application.
The user interface level
Hardware differences such as screen size, depth of color, and keypad configuration also influence how an application is seen and used by the user. While having a unique keypad configuration may create appeal from a style and marketing perspective, it may significantly change how user friendly an application is. Screen differences can also affect the user experience, with better screens offering a more enticing graphical interface. Lower resolution screens, however, can deliver only a simpler, more pixilated image. Again, as technology improves, screen resolution will also improve and the price may drop, but that doesn't mean that every phone will have the same size screen. Some users will want a compact phone, creating demand for smaller screens as well.
Designing applications with these potential hardware variations in mind is critical if the application is to run optimally across all devices and reach the target mass market.
Device OS characteristics and APIs
Unlike the PC world, no single operating system dominates the mobile device world. Nokia, with a 35 percent market share, has its own operating system and vested ownership of Symbian, yet runs multiple operating systems across its device portfolio. Each handset manufacturer also has its own system, as does Microsoft, with its .Net for smart phones waiting in the wings. The main reason each manufacturer creates its own version is clearly related to the change rate of their handsets. As the OS is directly related to the hardware manufacturing process, the manufacturers need to create their own versions so they can de-risk product development and manufacturing processes?thus ensuring their own operating systems reflect their existing hardware configurations.
The operating system in a wireless device provides the interface between the native application environment and the device's hardware, such as APIs to the various phones' hardware features (Bluetooth, IR, telephony) or usable applications (address book, messaging, and browsing). While the installed JVM may serve to abstract most of these features for J2ME applications, the available functionality is only as broad and reliable as the OS provides. Certain features such as the handling of sound files are not obfuscated by the JVM and remain a point of fragmentation on devices. Programmers need to be aware of these device idiosyncrasies.
Custom APIs, which reach beyond the Java specification, can also add substantial value to a Java application. Access to camera, Bluetooth, address book, or telephony features?including MMS (Multimedia Message Service) and SMS (Short Message Service) interfaces?are just a few examples of proprietary APIs that enable a programmer to create exciting new applications outside of the existing Java MIDP (Mobile Information Device Profile) specification. Many of these custom extensions are available on a few devices only, so building an application that performs only on these devices seriously limits the available market.
The JVM As Java is an open standard available through license from Sun, multiple companies offer JVMs. It is the JVM layer that abstracts the idiosyncrasies of the native operating systems, enabling the "Write Once, Run Anywhere" runtime environment. JVMs are all designed around the MIDP 1.0 or MIDP 2.0 standard.
Implementation of a standard is still open to interpretation and design. Different JVM vendors take slightly different approaches to integrating their JVM to a device's operating system. Add that to the J2ME roadmap and the methodical inclusion of new Java Specification Requests (JSRs), or standards, into the JVM, and you end up with numerous JVM versions in the marketplace, each running with different APIs on different operating systems.
That is perhaps the least publicized but most harmful of fragmentation elements. Poor JVM implementations can result in broken and sluggish applications, and JVM fixes that cause new production firmware releases ultimately drive the creation of new devices, each with its own SKU. The size and scope of the new MIDP 2.0 and Connected Limited Device Configuration (CDLC) standards will result in even more subjective interpretation and variance in implementation, which will drive JVM fragmentation to even higher levels.
All of these differences add to the growing list of device idiosyncrasies that must be considered when programming a J2ME application. As long we have multiple JVM vendors and evolving Java specifications, we'll have these differences.
Operator and market requirements and client/server APIs
Mobile operators also recognize the need to differentiate their offerings and meet market-specific requirements. To do that, they often have mobile devices created specifically for their customers, operate custom back-office environments, or require publishers to meet custom application requirements. All of these factors contribute to fragmentation from a developer's perspective.
At the client-server layer, an implementation integration problem exists, which recognizes that different mobile operators may establish back-office or front-office systems that need to communicate with the application. As these systems differ from one mobile operator to the next, they require an additional level of customization to make the application function properly within that operator's network.
The most popular interfaces include billing APIs for customer invoicing based on events that occur within the application (like paying extra for entering an additional game level), high-score tracking servers for games, communication servers for chat, and location-based services. While standards are being investigated for these application servers, the industry's continuous evolution implies that there will always be new ways for applications to communicate with Internet Protocol (IP)-based servers.
Operator and market requirements
Like the above custom integration with a mobile operator's back-office systems, many operators require their branding to be part of the application. Be it the simple addition of a splash screen or the elimination of certain phrases or words from the application's text to meet that mobile operator's specific codes, application customization is often required. Often, an operator-specific release of the mobile device satisfies specific operator requirements, creating a totally new device from a developer's perspective.
When you add the requirement for multiple language versions to meet individual market needs, the number of application versions needed to reach the mass market continues to grow.
How can developers keep up?
Since most of these issues affect the creation and sale of mass-market applications rather than customized enterprise applications, enterprise developers are, for the most part, off the hook?assuming the developer and IT department have some control over device selection by their mobile workforces. Once that control is lost to the user, the IT department will be expected to create applications that support a myriad of devices.
So what can be done? Limiting the devices and operators supported is an easy way to limit the number of ports that must be created. The downside is that limiting either option seriously limits the size of the market available for the sale or use of the application or game being developed. The result is a tradeoff, which we are already seeing in the publishing of J2ME applications?only the most popular devices and operators with the largest installed base are being supported.
What does this mean to the smaller operator or handset manufacturer that lacks dominant devices? Encourage the developer and publisher to provide more builds for more devices. Three options exist for publishers and developers: manually produce hundreds of different builds in house; outsource these builds to a third-party developer to do manually; or utilize new tools and automated technologies entering the market to aid developers in the porting of applications. Some tools that may be helpful include software development environments such as Metrowerks, Borland, and Sun wireless toolkits, which offer emulators for testing applications on many different devices. New technologies include the Tira Jump platform, which is an automated porting solution specifically designed to address fragmentation and supports nearly 100 different J2ME handsets.
Fragmentation is here to stay
Whether you consider physical device elements such as processing speed, memory or screen size, or variations in the implementation of the JVM or custom APIs?customizing Java applications for the more than 200 (and growing) different Java enabled-devices in the market is a major concern for J2ME developers. Add to that the customizations required to address market differences (languages, visual design), operator presentation, and integration needs and again we see the already staggering number of builds to launch a mass-market application grow.
Both the wireless device and application market are alive with innovation?technical innovation and lifestyle innovation. With no clear dominant market leaders in any of the device component, device manufacture, or JVM creation arenas, and with technology moving faster than any standard, fragmentation in J2ME is here to stay. Highly competitive environments both in handsets and wireless service means both industries will quickly innovate to keep ahead of the competition, luring more customers to their products and services.
In a fast moving market such as this, driving down porting costs with technology solutions such as the automated platform discussed above may be the only savior for this potential market of 1 billion users.