Development for Mobile Devices Part Three

Building an application to reside and execute on a mobile device brings a whole other set of considerations and issues versus thin client development. Unlike browser based mobile applications, resident applications are going to be more dependent on their device platform.

When talking about development of downloadable applications it is important to distinguish whether the app is going to be written to a device platform or application platform. I will use term ‘device platform’ to mean mobile device hardware with its operating system or its integrated software. I will use term ‘application platform’ to mean 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.

When writing to device portability is not much of a concern, so you want to explore and 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, 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 lists some of these device platforms and what they offer in the way of SDKs, tools, etc.

Application Development Platforms

When considering application platform for your next mobile development project the choice is quite similar to the non-mobile world. Whether you are proponent of Java and open source platforms or prefer Microsoft tools there is always a question why do you like one platform vs. the other?

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.

Take the .NET platform as example number two. .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.

Let us look at three of the more popular application platform choices and look at ways to compare these platforms.

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.

How do these environments compare to each other? 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.

Portability 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. 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 from 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.

Emulation/Testing

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 on 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… 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.

Performance

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 released its SDK for the iPhone. This is certainly an application platform that is impacting mobile development and attracts the business community to think about the iPhone as a possible platform. iPhone SDK comes with xCode IDE, iPhone simulator, Interface Builder and Performance Analysis tools. 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 of 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.

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 while 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 considering that 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.

Display Differences

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 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.