oftware engineering is all about choices. Choices have to be weighed: performance vs. scalability, complexity vs. flexibility, pros vs. cons, and good vs. poor design. In mobile application development, we have achieved that “many choices” state. In fact, in twenty years of software development, I cannot recall another time when there were so many choices. Before the days of Java vs. .NET, I recall interesting meetings to choose the programming language for a new application. Today’s mobile application development environments make some of those choices look like child’s play. So the good news is: we have so many choices! The bad news is: we have so many choices and we must choose wisely.
Look up “mobile development” in Wikipedia, and you will notice the editors of this particular topic have listed 11 different choices for application development on a mobile platform. While the editors have done a good job of listing some of the more popular and widely used programming languages, environments, tools, etc. that same article admits that the listing is not complete. In fact, assembling such a list and keeping it up to date is nearly impossible. For example, just one day before writing this article, Apple released its SDK for the iPhone. New tools and platforms for mobile applications emerge all the time.
If someone else was responsible for choosing the platform for your mobile application development work, that limits?but does not eliminate?other choices. Alternatively, if you are in the position whereby your proposed killer app gets to determine the device platform, the playing field is wide open, and there are many options you need to explore; some have been around for some time, while others are just emerging. How do you choose? What are the factors to explore?
Do you write a resident application (an application that physically resides and executes on the device) for the device or are thin client applications more appropriate? If you’re thinking about thin client applications then what rich internet application technologies are available, and are they advanced enough for mobile devices? If writing a resident application, what technologies are the development option leaders, and what are the technical criteria for evaluating those options? Other articles in this DevX series provide more detail and practical examples to make some of the choices clearer.
Fat vs. Thin
One of software engineering’s classic arguments does not go away in mobile application development: should the mobile device serve merely as a thin client tool to access enterprise application and data? Or is an intelligent application required on the device? How does this discussion change when you’re dealing with a mobile environment?
Today, most mobile devices come with a browser. These browsers are often called mini or micro-browsers. Given the sophistication and capabilities of today’s many devices however, there may be nothing “mini” or “micro” about them. Some browsers on mobile devices offer the same capabilities as a desktop browser. In fact, some believe the death of “native mobile applications” is happening or imminent and that mobile web applications are the future.
A mobile browser (sometimes called a micro-browser) can be used to access both web content and server-side applications, eliminating the need to write and deploy an application to the device. In the mobile development world, these types of devices are sometimes called “mobile internet appliances.”
The capabilities of micro-browsers vary greatly. Furthermore, the limited connectivity of any mobile device requires the device to operate, at least on occasion, without connectivity. The very idea of “mobile” user is one that defies having to be tied to any network—even a network without wires. In my area of the country, people like to take long weekends and work from deep in the woods and boundary waters of the Mississippi River. Such cases require an application (and often some data) to be installed on the device. Devices that support locally-run applications are often called “smart devices,” or “information appliances,” indicating that they have more innate capabilities than those devices that solely offer connectivity. Application development for “smart” devices comes in many shapes and sizes. Some options are targeted toward specific devices while other options support a broader set of devices. Some options have high entry costs, while others are free/open source. You need to weight the features and aspects of all these development options and align the available features against the application requirements.
Thin Client Development
If you are lucky—really lucky, perhaps providing an application and associated data to your customers’ mobile devices will be as easy as giving them your “normal” URL.
IDC has reported that it believes 1.3 billion (that’s about 1/5 of the world’s population) will be connected to the internet via mobile phone in 2008. With that much thin-client capability and connectivity, it’s hard to ignore the mobile browser as a very viable means of putting mobile applications in the hands of your customers.
|Figure 1. “Normal” vs. Mini-Browsing: The image on the left shows Intertech.com through a normal browser while the images on the right display the same site through the Opera Mini browser (zoomed out and in).|
However, while accessible, most will find that their “normal” web site, let alone any Web application on that site, will not be usable via a mobile device browser. To give you an example, this URL provides an online simulation of the Opera Mini browser (commonly found on many mobile devices) that you can use to access any web site. Figure 1 depicts my company’s Web site in both a normal browser and through the “eyes” of a mini-browser. Try it out on your own web site.
If you can read the micro-browser version, you either have really good eyes or your web site has already been designed to display better in a micro-browser. Yes, you can “zoom” in and out using the micro-browser’s features, but that’s not always the most user-friendly of interfaces—especially when you don’t know where to zoom in to find what you need. Never mind the fact that manipulating to a particular zoomed area on the screen requires, for some, motor skills akin to those required for playing video games. That’s particularly true because mobile device browsers often have limited display space and interactivity (keyboard, pointing device, and so on).
The good news is that thin client development allows many organizations to reuse most, if not all, of the backend of their applications. Getting the apps to the device is also a lot easier. It’s the user interface portion of the application that you may need to address to support the micro-browser thin client. Therefore, there are many considerations when writing applications to support the mobile device—even when using the device as a thin client.
When browsing the web, you have to be connected. You don’t think about this as you read this article. Typically, the cost to “surf” is a flat monthly fee billed to you or to your office. But when browsing via a mobile device, you may be accessing the web through a cellular network. This access typically results in a fee for the amount of time one is connected or the amount of data one accesses. This cost can factor into the success of a browser-based solution in mobile computing. Too much connectivity can run up those costs. In fact, Nokia researchers have concluded that cost is “seriously restraining mobile browsing from becoming commonplace.” Another cost is that normal web site interfaces may need to be altered to provide the most efficient time use. Today’s web sites are rarely constructed for the most efficient use of time. In fact, some are built to encourage you to “linger” and stay on the site for long periods, presumably keeping you from the competitors.
WML vs. HTML vs. C-HTML vs. ?
Newer full-featured micro-browsers, such as Opera Mobile and Safari (used on the iPhone), can display HTML (or XHTML) complete with cascading style sheets and even client-side scripting. Therefore, the “normal” web site written largely with HTML/XHTML, CSS and client side scripts might be completely accessible in these browsers, even if they don’t always offer the best interface given the constraints discussed earlier. However, in other cases, a web site or web application may need to be rewritten or otherwise dynamically converted into an alternative markup/wireless protocol. Again, there are plenty of choices. However there seems to be increased consolidation toward XHTML-Mobile Profile (MP). A lot depends on where (United States vs. Japan vs. ?) and when (today, in a couple of years, etc.) you intend to offer your application and on what types of devices. Table 1 outlines some of the more popular markup options in use today.
|Markup Language||What is it||Pros/Cons|
|XHTML-MP (WAP 2.0)||Derived from and is a subset of XHTML||+Developers can use the same tools for mobile and normal web sites.+More formatting power than WML.+WAP Gateway no longer critical component.- May display differently in different browsers.|
|WML (WAP 1.x)||XML document with features inherited from HTML. First generation wireless markup language.||+WML and WMLScript are fairly easy to learn.+Was widely accepted.-WAP Gateway a concern in converting HTML to/from WML.-Soon to be phased out, but still used heavily in places like far east.|
|cHTML||A compact and simple form of HTML. Similar to WML.||+ Offers features such as access keys and phone number shortcuts- Limited use; big in Japan—especially on DoCoMo phones.|
Certainly, to reduce having to maintain dual sites and in order to offer the same rich display/features, the trend is to have micro-browsers behave more like “normal” browsers. Some analysts, like Craig Mathias, have suggested the time to retire micro-browsers altogether is drawing near. At present, however, this is not always possible—or wise—given mobile devices’ constraints and differences.
Give Me a Browser
Speaking of that micro-browser, just how did it get on the mobile device? You may assume that the devices all ship with a browser. That is usually true. However, you might also assume that the browser used on the device is the same one that it shipped with. This is increasingly not the case! As devices become more open to allow owners to add their own software and common runtime engines (such as the Java ME virtual machine), a demand has arisen for alternative browsers with alternative features. Opera Mini claims to be the world’s most popular micro-browser with over 15 million users.
Whether it is your device’s default browser or not, the Opera web site just asks you to point your cell phone browser to operamini.com to download and install the latest copy. It’s as simple as that. In fact, there are probably more micro-browsers than there ever were “normal” browsers. Table 2 shows a list of some of the user-installable browsers.
|Opera Mini||Opera Software|
These alternative browsers add complexity to thin-client solutions. Mobile developers take note: standards and standards adherence will be pivotal to making the thin client approach work. Just ask a web developer about the impact of all the alternative choices in browsers, added/removed plug-ins, and control of features such as script execution and cookies on a “normal” web site. As with most web sites/applications, lines must be drawn about what will ultimately be supported.
Can You Make It Rich?
If thin-client development on micro-browsers makes sense, the next logical step is to ask if these same applications can be made rich. Rich Internet Applications (RIA) is a term coined to describe web applications that look and feel like desktop applications from a user interface perspective.
|Author’s Note: Microsoft prefers the term Rich “Interactive” Application because some applications are used internally to organizations and never use the Internet, per se.|
It stands to reason that mobile users will want, and perhaps demand, a richness that comes close to the features and interactivity they get with desktop applications. This may sound impossible, but RIA is the current mobile development battle ground, with all the “big boys” (including Microsoft, Sun, and Adobe) offering their own solutions and vying for the hearts and minds of the thin-client mobile developer. In fact, collectively, mobile RIA has been dubbed Mobile 2.0. Unlike their desktop counterparts, mobile RIA solutions are not always integrated as part of the browser. So each technology/RIA application may require users to install yet another engine the mobile device in order to load and display. This certainly blurs the line between RIA applications and other native or resident applications for the mobile device. So what are the options for RIA on mobile platforms?
Adobe’s Flash Lite is a scaled-down version of Adobe’s ever-popular Flash Player that is engineered specifically for mobile devices. Learn more about Adobe Flash Lite from this DevX.com article.
What Should You Know About It?
This RIA technology provides access to a mobile device’s features, including Bluetooth, camera, microphone, and GPS. Developing with Adobe Flash products is considered easy, and a large and active community is available for support and help. Flash Lite’s strength is that it uses vector-based graphics (although it also supports bitmapped graphics) which scales well on screens of varying resolutions—but sometimes at the cost of poor performance. You can conveniently convert desktop Flash content to mobile Flash Lite displays with minimal effort, which helps if your organization already uses a lot of Flash on its web site or in its web applications. Flash Lite can also run on top of other runtime environments such as Java ME or BREW.
Flash Lite has not been widely available on mobile devices outside of Japan and Korea, but this is rapidly changing. Adobe’s 2007 Financial Analyst Meeting notes indicate that over one billion handsets will include Flash capability before the end of 2009. Access to Flash Lite content can be expected to blossom as more carriers and devices support the platform. Most of the major cell phone providers (LG, Motorola, NEC, Nokia, Sony Ericsson, etc.) now ship with products that have Flash Lite pre-installed.
Straight from Microsoft’s Silverlight web site, Silverlight is described as: “a cross-browser, cross-platform, and cross-device plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the web.” What does that mean? Well, Silverlight is intended to be a competitor to Adobe Flash. However, instead of compiled applications (such as Flash delivers), Silverlight applications are delivered to the browser in the form of Extensible Application Markup Language (XAML), which is an XML-based language. The XAML is then read and used by a browser plug-in to display rich content. The plug-in reads the XAML files, which can declaratively specify the UI, and play MP3, WMV, and WMA files without a Windows Media Player or the WMP ActiveX control. Microsoft is expected to make Silverlight available for use with some mobile browsers.
What Should You Know About It?
On the positive side, because XAML is text and not a compiled file, supporters say Silverlight applications will be more “searchable” via engines like Google than Flash applications. Silverlight 1.0 is expected to be released for mobile platforms (specifically Windows Mobile 6 platforms) to the development community in mid-2008 with general release scheduled for later 2008.
|Author’s Note: There is a Silverlight 2.0 for larger platforms, but it is not expected to reach the mobile platform until 2009 at the earliest.|
Silverlight is still a very young platform. Needless to say, while there’s a lot of hope for Silverlight in general, and Silverlight on the mobile platform specifically, the technology is still in development—read probably “not ready for prime time” yet. One big question is whether Silverlight clients will be supported on non-Windows platforms (and specifically non-Windows mobile platforms). The European Committee for Interoperable Systems has already questioned Microsoft’s “cross-platform” support with XAML-related technology. Finally, while XAML is just XML, most developers will want a XAML-aware integrated development environment (IDE). Today, only Microsoft’s Expression Blend and Visual Studio are equipped to develop Silverlight applications.
You can learn more about Silverlight from this DevX article.
What Should You Know About It?
Back in August of 2007, I wrote that Sun was still working with device vendors to bring JavaFX Mobile-capable devices to market in 2008, and that even development tools were still a few months off. In July of 2007, Jacob Lehrbaum, Sun’s JavaFX Mobile product line manager, said in a podcast that “it’s a little bit early to start working with [JavaFX Mobile] as we are still defining the platform and building out some of those capabilities.” To date, no major announcements on device or development support for JavaFX Mobile have been made. Sun typically introduces many product versions and makes many announcements at its annual JavaOne conference held in May. Look to that conference for updates to JavaFX and to get an indication of when JavaFX might be ready for primetime use:
First, for those unfamiliar with AJAX, it is the combination of these common technologies and techniques for creating RIA web sites and applications.
- XHTML and Cascading Style Sheets (CSS) for presentation
- Document Object Model (DOM) for dynamic display and interaction
- XML and XSLT for data interchange and transformation
- XMLHttpRequest object for browser-to-server communications in synchronous or, more commonly, asynchronous fashion
You can learn more about AJAX from this collection of articles and information.
What Should You Know About It?
The term “fat” hardly seems fitting, given that many applications that reside on a mobile device measure a few kilobytes in size. However, the term here is used to refer to those applications that are deployed to and execute on a mobile device versus the use of a micro-browser to access data and an application from the server. The term fat-client originated in our desktop world where fat or “thick” clients were larger than the browser application. A term used in some literature that more appropriately suggests the nature and size of these applications is “resident” application.
Building an application to reside and execute on a platform brings a whole other set of considerations and issues versus thin client development. Again, these considerations are neither good nor bad. Considerations are just aspects for your evaluation.
Writing to a Device or Writing to a Platform
Unlike thin (browser) client mobile applications, resident applications are going to be more dependent on their device platform. If the device platform has already been selected, this can limit your options considerably. If, however, the platform (device and application platform) is going to be selected on the best technology available to field the needed application, well then, the number of options just got a lot bigger.
Earlier, I referred to the Wikipedia page that listed 11 mobile development platforms. While I applaud those that have tried to collect such a list, you have to look at the list and understand that it’s a bit of an apples, oranges, and maybe even grapes (and a few other fruits) comparison. That’s because it’s a combination of some device platforms, some application development platforms, some RIA technologies and some general programming language alternatives. For example, you can write Java ME applications for Symbian OS and Palm OS devices; all three are listed as mobile development options.
Today, any such list of mobile development platforms is going to run into the same issues. That’s why it is probably more important to assemble a list of application platform options only after first answering a basic question: are you writing to a device or writing to an application platform?
I use the term “device platform” here to refer to a mobile hardware device and its operating system and/or its integrated software. The term “application platform” is used here to refer to the combination of programming language, general development API, and the runtime environment for that language on the mobile device. The application platform runs on top of the device platform.
So, when looking at resident application development, start with what might have already been decided—namely the device platform. If the device platform is set, then some—and maybe all—of your application development choices have been decided for you. If the device platform has not been picked, then you have research on application platforms ahead.
Writing to a Device
Has your device and/or the device’s operating system already been decided? Now your choices are probably more limited. Since portability (at least broad portability) is probably not as much of a concern, you want to explore and probably even use the SDK, tools and device emulator provided by the device or OS provider. Most of the major device platform vendors provide such tools for their devices. Since you are working with a specific device (or set of devices), many of the other issues that must be considered when working with a vast array of products such as performance and access to the device’s features and functionality (phone, camera, GPS, and so on) are probably more straightforward. The table below (Table 4) lists some of these device platforms and what they offer in the way of SDKs, tools, etc.
|OS||Language/OS options||SDKs/Tools||Developer Web Site|
|Symbian OS||C++, Java, Ruby, Python, Perl, OPL, Flash Lite, .NET||Carbide.c++ IDE (Nokia)-C++ and Java SDKs per device||developer.symbian.com|
|Blackberry OS||Java, .NET||Blackberry Java Development Environment, Blackberry plug-in for Visual Studio,Blackberry plug-in for Eclipse||na.blackberry.com/eng/developers/|
|Palm OS||C, C++, Java||Palm OS SDK, Java development with IBM Websphere EveryPlace Micro Environment, Also offer Palm Windows Mobile SDK for Palm products on Windows Mobile platform||www.palm.com/us/developer|
|Motorola||Java, Windows Mobile, Linux||MotoDev IDE (Java Eclipse based), MOTO Q Plug-Ins (for VisualStudio), Many SDKs for various platforms||developer.motorola.com|
|Nokia||Java, C++, Python (S60)||Carbide IDEs-Number of SDKs for various platforms that integrate with industry IDEs||www.forum.nokia.com|
|Sony Ericsson||Java, Symbian OS, Windows Mobile||SDK for the Java ME, Mobile JUnit, Eclipse Device Explorer Plugin, additional SDKs and integration plugins for IDEs||developer.sonyericsson.com/site/
|iPhone OS||iPhone SDK||developer.apple.com/iphone|
Writing to an Application Platform
Are you a hard-core believer in Java and open source development? Do you anxiously await every MSDN newsletter looking new .NET gems? We all have our beliefs in particular programming languages and development environments. Why? Why do you prefer that development language and application development environment?
Mobile development re-raises this question, and you may have to re-evaluate your answer in light of your mobile application development. Java, .NET (C#, VB), C, C++, Python, and other languages are all options available in mobile development. In some ways, the same criteria used to compare these on a desktop or server can be used to evaluate the languages use for mobile apps. However, mobile development does bring in other considerations which distort the old desktop/server application development environment discussions.
For example, Java’s strength has always been portability. Java is a widely available platform on all sorts of mobile devices. Sun touts some 2.1 billion devices with Java as indicated earlier. However, the exact same Java is not on all these devices. In order for Java to fit on so many different styles and shapes of platform, the Java architecture has been broken into a set of configurations and profiles. The configurations and profiles differ according to device and device capabilities. Look, I am a true believer of the Java write once run anywhere philosophy, but to say that Java code is completely write-once-run-anywhere on all devices would be hugely misleading.
Take the .NET platform as example number two. In the classroom, I explain to students that .NET shines in that you can use your choice of programming language (C#, VB, etc.) written to a single platform; that of .NET and the Microsoft operating system. Yes, efforts in projects like Mono attempt to make .NET more cross-platform, but the number of actual platforms and devices using these cross-platform .NET implementations is limited. Microsoft tools (for the most part those in Visual Studio) do a great job of making development to this particular platform very easy. In the mobile platform world, however, Microsoft is not the dominate OS. Thus, writing to this platform may not get you to those customers you want to capture.
So how should you look at the application platforms for mobile devices? The next sections explore three of the more popular application platform choices and look at ways to compare/contrast these platforms. Tutorials and more information on each of these application platforms are available on DevX.
Java Micro Edition (Java ME)
Java ME, formerly called Java 2 Micro Edition (J2ME), functions as Java for mobile devices as well as the Java embedded in consumer electronics such as TV set-top boxes and printers. It is a runtime environment that goes on the device and a set of Java APIs and tools to create the applications. Java’s ubiquity on a number of platforms of all shapes and sizes is notable.
.NET Compact Framework
This platform is a version of the .NET Framework for Windows Mobile OS platforms. It’s a subset of the standard .NET framework, but also includes some additional classes that address specific mobile device needs. For example, the library includes classes to work with the device’s touch screen. Classes specific to the PC platform were removed, such as classes associated with remoting. The CLR execution engine was rebuilt so that it runs more efficiently on mobile devices that may have limited memory, resources and power. Like Java ME, this platform targets both mobile devices and other consumer electronics. For example, the XBox 360 consoles include a version of the .NET Compact Framework. You can write applications for the platform in C# or VB.NET. The Windows Mobile OS holds a significant market share on high-end PDAs and “smart phones.”
Binary Runtime Environment for Wireless (BREW)
BREW is an application runtime platform created by Qualcomm for mobile phones. It was originally created for Code Division Multiple Access (CDMA) devices, and more specifically, for Qualcomm’s CDMA devices and chipsets. Qualcomm spearheaded the development of standards for this communication technology’s use in digital cellular communications. BREW has since been ported to other devices, but largely remains a Qualcomm-specific platform. BREW provides a small runtime environment (approximately 150K in size) that runs on top of the device’s Application Specific Integrated Circuit (ASIC) or essentially its OS. Applications run atop the BREW runtime. Applications can be written in different languages, although most use C or C++. There are some Java implementations for BREW, but they require that the application run on the JVM—which runs on BREW, which runs on ASIC.
Application Platform Evaluation Criteria
How do these environments stack up? A direct comparison can be difficult, given that many features provided through the application platform are a product of their targeted devices. However, some features worth examination are listed below. In addition, the other articles in this DevX special report on mobile development compare and contrast some aspects of these environments in more detail.
Platforms and Standards
Java’s ubiquity on a number of platforms of all shapes and sizes is notable. In 2006, Sun claimed that Java was available on 3.8 billion devices and 1.2 billion phones. Sun’s developer web site lists the hundreds of devices already outfitted with Java ME capability. Java, at its core, is meant to be platform-independent, but as indicated above, Java ME is a collection of specifications that outline a layered architecture:
- Configurations provide the basic services, libraries, and virtual machine capabilities for a broad range of devices based on the memory, power, and connectivity of the device.
- Profiles define the user interface, data storage, and other APIs for a narrower set of devices in a configuration.
- Optional API Packages add capability to a configuration and profile to support device capabilities not present on all devices (such as multimedia and Bluetooth).
This architecture allows Java to be added to devices large and small. However, the portability of an application depends on how many devices and, therefore, how many configurations, profiles, and APIs are targeted. The Java ME architecture can also impact how simple or complex application development can be.
Microsoft is .NET’s standard bearer. Proponents of .NET will claim other implementations of the .NET Common Language Infrastructure, such as Portable .NET and Mono, give .NET applications portability to other operating systems and devices, but portability is limited and these are not major players in the mobile arena. Windows Mobile OS is not a ubiquitous platform. It is common on relatively high-end “smart phones” and PDAs, but that popularity has not extended to lower end cell phones. Even on smart phones, a fourth quarter 2007 market data report from Canalys indicates that Windows Mobile has only a 12 percent market share. Competitors such as Symbian have a much bigger share worldwide (about 2/3 of the market) and others, such as Apple, are also working to cut into Microsoft’s market share.
Unlike Java ME, BREW offers portability without the numerous APIs and environments. However, BREW is tightly controlled by Qualcomm. Developers must register (or, “authenticate” in Qualcomm terms) with Qualcomm and submit their applications for BREW testing before the applications can be put on a device. This is supposed to ensure a BREW application behaves properly and is able to port to any BREW-capable device without issue. However, the cost (at least $400) of the authentication/testing is not trivial and a barrier to the software enthusiasts. Also, there are complaints that BREW is implemented differently and inconsistently on different phones. The emulator is generic and does not demonstrate these differences.
Development Tools and Integrated Development Environments (IDEs)
Java ME SDKs and basic tools are free from Sun. However, given the multiple Java ME environments and APIs, there are multiple SDKs and toolkits. Plenty of open source and commercial IDEs exist for creating Java ME applications. Eclipse and Sun’s NetBeans are the two most popular open source IDEs. Commercial products like Rational Application Developer from IBM are also available and popular. As indicated earlier, device vendors like Motorola also offer their own SDKs. If anything, the Java ME environment suffers from having too many development choices rather than too few. The complexity of Java ME’s architecture allows for its adaptation to a great number of platforms, but also can make finding or assembling a proper development environment more of a challenge.
In this area, .NET Compact Framework development shines. While it is possible to write applications without it, few developers would write applications for the .NET Compact Framework (or .NET for that matter) without Microsoft’s Visual Studio. Visual Studio is not free. The latest version is Visual Studio 2008 and it can cost, depending on where purchased, $150 and up. Without question, this tool greatly simplifies mobile development for the .NET Compact Framework and has a low learning curve for those already familiar with .NET and C#/VB development.
BREW’s SDK is free and can be obtained by Qualcomm. However, developers also need an IDE. If writing BREW with C++, this means having a copy of Visual Studio 6.0, Visual Studio 2003 .NET, or Visual Studio 2005. Again, don’t forget the cost to be authenticated and have your application tested before deployment. This can be a significant hit to total cost of development.
Through its SDKs and IDEs, Java ME environments offer a host of generic emulators for a number of devices. The Sun IDEs provide generic emulators that have “skins” that give the device emulator the appearance of a type of device with certain buttons, screen size, color depth, fonts, device controls, etc. Additionally, device vendors (Nokia, Motorola, etc.) provide SDKs that often offer more precise emulation for a particular device or set of devices. Some are able to be integrated with IDEs while others are stand alone.
The generic emulators don’t test vendor specific APIs. Additionally, as these emulators are generic in nature, they do not always accurately reflect specific device issues and capabilities. Testing on the actual target devices is always recommended, especially when it comes to Java ME applications.
The Device Emulator 2.0 is part of the Windows Mobile 6 SDK. This emulator does a great job of representing Windows OS devices and can be considered one of the strengths of developing mobile applications to the .NET platform. This emulator provides fake GPS, low battery emulation, and even goes to some length to provide an emulator that tests the behavior of your application with cellular communications state changes (incoming call, hang up, busy signal, and so on). This emulator is a true Advanced RISC Machine (ARM) emulator, which means the emulator runs the same code as real devices.
BREW’s emulator comes with the BREW SDK. However, it only runs on Windows. The testing and debugging of BREW applications is not easy and requires a lot of outside assistance. First, the BREW Emulator (called a Simulator) does not truly emulate the handset’s hardware. Instead, BREW applications are compiled to native code and linked with an x86-compatible BREW runtime library. “Simulation” hides issues related to the actual hardware. In order to avoid these issues, developers should test their applications on real BREW handsets. For this, an application must first be compiled and linked into ARM binary form to run in BREW handset. The compiler/linker is available from Qualcomm. The application must then be digitally signed. Again, another tool from Qualcomm is required. Finally, the application can be uploaded to a BREW handset for testing via another tool (and USB or serial cable) called the AppLoader that is available from, you guessed it, Qualcomm. After the application has tested out, it can then be submitted to Qualcomm for its “TRUE BREW” testing. By the way, once an application has been tested and ready for deployment, the operator that owns the relationship with the handset customer must be convinced to offer your application. They may choose to do more testing of your application before offering it to the customer.
Device Feature Access
Java ME’s access to a device’s fundamental capabilities (like camera for instance) typically requires them to be included in the configuration, profile, and/or optional API for that device. This varies greatly according to platform. Only one of the configurations (CDC) allows native interface access (JNI), so accessing the device’s feature even outside of Java may not be possible.
The .NET Compact Framework is written to the Windows Mobile OS, and so it has access to the same device capabilities as the OS. Which means the .NET Compact Framework application has access to just about everything and the device has and there is usually a convenient API to access it.
BREW allows direct access to the features of the device like the screen buffer, which is important for graphics intensive applications like games. At the discretion of the handset provider, BREW extension modules can add access to non-standard device functions.
Java ME runs on a virtual machine and its performance can be an issue especially on limited power/processing mobile devices. Like the Java virtual machine, the .NET Compact Framework requires applications to ride atop a runtime environment so performance of .NET apps is considered average by most accounts.
BREW applications, on the other hand, typically have very good performance. This is because the BREW applications run closer to the hardware layer than Java ME or .NET Compact Framework applications.
Platform and Application Provisioning
Getting the application platform and applications onto the devices can be problematic especially since the devices can literally be anywhere in the world.
Java ME’s application provisioning strategy depends on the configuration. An Over-the-Air (OTA) Provisioning specification defines how applications can be obtained on devices that run Java ME’s Connected Limited Device Configuration (CLDC). While the specification is in place, carrier and/or vendor support for the specification and how end-users can obtain their Java ME application is not always seamless (see the blog So, you want to deploy a J2ME app in the US?). There is no OTA specification for Connected Device Configuration (CDC) applications and therefore no consistent technology or strategy for getting these applications to their devices—particularly over the air.
As for the Java ME runtime environment, it is often factory installed by the vendor, especially on cell phones. In some cases, however, the runtime must be installed along with the application by developers or consumers, which adds to deployment frustrations.
The .NET Compact Framework is already installed with Windows Mobile OS, so getting the base application platform in this environment shouldn’t be an issue. ActiveSync allows Windows Mobile OS devices to be updated quickly and easily via connection to a desktop. In addition, over-the-air provisioning is technically possible, but it requires the support of the carrier and/or vendor. In particular, they must provide a device management (DM) server. In its documentation on Windows Mobile OS, Microsoft notes that “Microsoft does not provide an OMA DM or an OMA Client Provisioning server. The OEM, Operator, or a third party must create their own server”.
The effort to get an application to the point of delivery can be extensive with BREW. However, once ready, BREW’s application deployment and provisioning plans are well thought out and where BREW excels, especially for application developers targeting devices in the hands of the general public. The operator manages the available BREW applications for download through the BREW Distribution System (BDS). This system allows handset users to select and download applications over the air and bill them accordingly. The operator and Qualcomm conveniently handle all the distribution and billing details. Of course, this comes at a cost. This document indicates that developers receive 80 percent of the application’s wholesale price while Qualcomm and the operator take 20 percent. This over-the-air provisioning also allows the applications to be quickly updated or fixed. In fact, the handset manufacturers provide new features and fix bugs over-the-air also using BREW extensions.
Other Resident App Options
Again, this is not a complete list of resident application development technologies. The Open Handheld Alliance, whose members include Google, HTC, Intel, Motorola, Qualcomm, Samsung, LG, T-Mobile, and Nvidia, released Android in November of 2007. Android applications are written in Java with an Android Java SDK, but this Java is not Java ME or Java SE. Android applications are targeted to run on a custom virtual machine (Dalvik) and Linux OS. While there is considerable interest in Android, there are no major devices that run this application platform today. Apple, as mentioned, just released its SDK for the iPhone. This is certainly an application platform that could impact mobile development and attract the business community to think about the iPhone as a possible platform. Sun is also developing a JVM for the iPhone OS. Still there are other mobile development platforms that may not fit under a heading of “major” but might be worthy of exploration given your particular platform and application needs. Nokia has released a Python interpreter for some if its mobile phones. Lazarus provides a Pascal (Object Pascal) environment for select devices. Straight C/C++ applications can be written for Windows Mobile and other platforms. And regular Java (Java SE) is available on some mobile device platforms and James Gosling has hinted that this is ultimately where Java is heading in the mobile space.
The combinations and permutations of programming languages, development environments, and mobile device runtimes are extensive. There is bound to be something for everybody.
Tomorrow’s Resident Application Choices
Will BREW survive? Will the Apple SDK drive more companies to explore the iPhone for business applications and thus increase its market share? Will Android ever find platforms to host it? Will this discussion of writing to a device and writing to an application platform always be an issue? While it appears that the number of choices for mobile development is increasing, some say it’s a matter of time before we experience some contraction. Some, especially those centered on enterprise applications for business, say these and a host of other questions may not be relevant in the near future.
In 2004, Jack Gold, then a Vice President at Meta Group, made a bold prediction that “before long, the market will consist of only two camps: Microsoft and Java.”
Today, Mr. Gold is President of J.Gold Associates, LLC, a research, analysis, and strategic consulting company. Via email, I asked Mr. Gold if he would like to update is 2004 comment in light of what almost seems like more options and alternatives for building mobile applications today. He sticks by his 2004 comments and indicates the enterprise challenges will be at the heart of that consolidation.
“We still expect the market to coalesce around the two major platforms: Microsoft’s .NET framework and the Java environment (and its derivatives, but primarily J2ME). The vast majority of mobile apps deployed to smart devices today fall into one of these two environments. Yes, there are some thin client apps being deployed and this will expand, particularly as the browsers on the devices become more capable and support things like AJAX, Flash, Silverlight, etc. But enterprises still have the challenge of assuring anytime/anywhere computing for their workforce, and the wireless networks are not 100 percent reliable, and probably never will be (except in a controlled environment like an enterprise campus where radios/access points can be added as need). And if you look at the various platforms available for delivery, the standards become even more compelling. Blackberry and Symbian apps are primarily delivered to the devices via J2ME. Microsoft powered Smart Phone devices have apps that are primarily .NET powered. And Android, which is really an overlay on a Linux Kernel, will provide a platform for Java and AJAX deployment, as will the iPhone (Mac OS also has Unix at its core).
So while the devices expand, the delivery mechanisms, and especially development environments for enterprise class apps will remain centered on the standards that companies know today—Visual Studio and Eclipse primarily, with a few specialty app environments (e.g., Apple) for a few select devices. Enterprises will not be able to go out and learn a myriad of different app environments—it is too costly to create, maintain, and support different apps for different device types. There has to be a unifying thread, even though they need to potentially support different actual devices. So coalescence is required (unlike the consumer space where apps need to support dozens or hundreds of devices).”
Using history as an indicator, Mr. Gold might be on to something. In both hardware and software, there has typically been a period of proliferation of solutions before an eventual consolidation/standardization.
Other Application Considerations
In addition to the considerations listed above in thin and resident application development, there are some additional issues to consider when assembling a mobile application. These issues apply to both browser-based and resident applications, but are unique to mobile development.
Data Entry Complications
A few weeks ago, a story on CBS Sunday Morning featured a Japanese woman that wrote and distributed novels via her cell phone! She wrote an entire novel in six months on her cell phone! Some have been clocked at text entry of about 100 words a minute. Amazing feats, given that I have difficulty fat fingering in my voice mail pass code in the time required. While many are becoming more familiar with the user interface of mobile devices, it is often a clumsy interface compared to that of the desktop; especially to those of us that are older than the cell phone.
In 2006, the World Wide Web Consortium came out with the proposed Mobile Web Best Practices 1.0, Basic Guidelines recommendation. In it, they state “User input is typically more or a lot more restrictive on Mobile devices, which may lack pointing devices and usually do not have a standard keyboard with which to enter text.” So what do they recommend? Some of the recommendations include keeping the number of keystrokes required to a minimum, avoid free text entry where possible, and provide pre-selected default values where possible.
This same group indicated that URL’s maybe one of the worst offenses to the mobile Web user interface. The length of the URLs to many web sites makes getting to sites painful using mobile devices.
Many devices also lack a pointing device (mouse, pen, etc.) for interaction. Even when a device has a touch screen, the precision of one’s finger to act as a pointing device on a small screen makes many common desktop UI “widgets” like spin boxes difficult to use. Also, mouse movements are not tracked on most mobile devices. Technically, it is a challenge to differentiate mouse movements and mouse events when there is a touch screen. Therefore, mouse events that trigger tooltips and other such actions are not available. Gestures on mobile devices may even differ from those on the desktop. For example, dragging on an iPhone is for scrolling.
These limitations are not killers, but they do require consideration when building an application for the mobile device and typically cause current Web sites to be revisited before they can be considered “mobile ready.”
Interruptions and Interactions
The mobile device is many things today. In some cases, it’s a camera, text messenger, music player, personal information management system, GPS navigational system, and, oh yes, a phone. Does your mobile application interact well with all these capabilities? Does it need to interact with any of these features? What happens when a user is browsing your site or using your resident mobile application and a cell phone call comes in? As indicated earlier, it is interesting to note that the new Windows Mobile 6 developer platform goes to some length to provide an emulator that tests the behavior of your application as the state of cellular communications changes.
Do you need a picture from the user’s cell phone camera or a position from its GPS? Does the mobile device give your application runtime access to these features? Do these devices and their associated applications interrupt your applications use or vice versa? All points to consider (and test!) when looking at mobile application development. Also, when considering resident- vs. browser-based client application, note that access to these types of features may be tougher or impossible via the browser approach.
Of course, the mobile device display is generally smaller than that of a desktop, but display limitations aren’t restricted to just the number of pixels available. Fewer colors and slower display speeds can also hamper the experiences of mobile users.
The Nokia N series devices have been manufactured to provide great multimedia capabilities. The N82 has a 2.4″ display, LCD screen that offers a 240 x 320 pixel display and 16M of colors. It’s impressive, especially given most competitive mobile products today. But remember, most of our desktops and laptops have at least 800 x 600 pixels (minimum and what most of the web is built to) and 32bits (> four billion colors). Doing the math for you, that’s about 1/6th the display and ½ the color of our “normal” displays.
The display of mobile devices is certainly better than it was five years ago. According to a Report Trend report on mobile trends for 2008, we may have Apple to thank for continued improvements in the display in the not too distant future:
“The idea that User Interface = Culture Code is spreading in the market, and Apple iPhone can be taken as a prime example. Against this backdrop, handset vendors are expected to pursue mergers with UI companies while introducing a variety of new UI technologies, with a view to delivering differentiated OEM UI to the users.”
The display restrictions and limited interfaces provided by mobile devices do not mean these devices can never serve as a powerful instrument to get information and product to customers. Proof positive is again from that fast-thumbed community in Japan. The New York Times reported in January of this year that five of the top ten novels in Japan last year were originally sold on cell phones! If thousands are willing to read a 200+ page novel over the mobile web using a cell phone, I have to believe there are still a lot of applications (some “killer apps”) yet to be written and utilized on the mobile devices and technology at our disposal today.
Time to Get in the Game
With the arrival of so many mobile devices (and by default mobile users), there is no time like the present to bring mobile applications to life. Mobile development technology has arrived and is ready for prime time. As with all application development, the tough part of developing mobile apps is going to be trying to make the best architectural choices and design decisions given the needs and available technology. This DevX Special Report is meant to help address some of those choices and decisions. However, one thing is certain, you can no longer afford to sit on the sidelines and wait for “better solutions.”