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.

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 by the end of this year. 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 the consumer.

Developing for mobile browser however is a tricky business since the choice of browsers running on mobile devices is much greater than in the desktop world. 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 needs to be addressed to support the mobile browser thin client.

Most of the mobile devices come with the built in browser however more and more devices allow you to download third party browser.

Here is the list of built-in default browsers:

• Android (mobile phone platform) by Google (based on WebKit)
• BlackBerry Browser by Research in Motion (proprietary)
• Blazer by Palm, installed on all newer Palm Treos and PDAs (based on NetFront).
• Danger browser by Danger (proprietary), installed on all Danger-designed devices including the T-Mobile Sidekick.
• Embider by Infraware[4] (proprietary).
• Internet Explorer Mobile by Microsoft
• jB5 Mobile Browser by Jataayu Software, available on Symbian Series 60, Windows Mobile and Linux Platforms
• MOTOMAGX by Motorola (based on WebKit).
• NetFront by ACCESS Co., Ltd. (proprietary).
• Nokia Series 40 Browser by Nokia (proprietary).
• Novarra nWeb (proprietary).
• Obigo Browser by Obigo AB (Sweden), 100% owned by Teleca AB (proprietary).
• Openwave Mobile Browser by Purple Labs (newly aquired from Openwave) (proprietary).
• Opera Mobile by Opera Software ASA (Norway). – Capable of reading HTML and reformat for small screens (proprietary).
• Picsel Browser by Picsel Techologies (Scotland) (proprietary).
• PlayStation Portable web browser by Sony (based on NetFront).
• Safari by Apple Inc on iPhone and iPod Touch (based on WebKit).
• Iris Browser by Torch Mobile for Pocket PCs (based on WebKit).
• Wapaka Browser Java micro-browser by Digital Airways.
• Web Browser for S60 by Nokia (based on WebKit).

And here is the list of browsers that can be downloaded and install on your mobile device:

• Bluelark Bluelark bought by Handspring Inc.
• Deepfish Beta from Microsoft
• Doris by Anygraaf Oy (Vantaa, Finland)
• iPanel for Palm OS,
• jB5 Mobile Browser Beta from Jataayu Software.
• JOCA by InteracT!V, another proxy-rendering free software.
• Minimo by Mozilla Foundation (based on Gecko).
• Opera Mini by Opera Software – supports most features of stand-alone Opera, but can run on less capable phones by offloading memory-intensive rendering to proxy server (based on Opera Mobile running on a server).
• Opera Mobile by Opera Software – supports all modern web standards supported by desktop browsers, including XHTML, CSS2 and Ajax. Has advanced Small Screen Rendering that adapts regular pages to small screen (proprietary).
• Pixo by Sun Microsystems (Pixo acquired by Sun July 2003)
• PocketWeb by tlogic.de
• RocketBrowser Rocket Mobile, Inc.
• SAS
• Stanford Power Browser created in Stanford’s InfoLab
• TeaShark – a free Java-based browser with a desktop-like layout
• ThunderHawk by Bitstream Inc.
• UCWEB by UCWEB Technology
• Universe by OpenMobl Systems
• Webby Mobile by AnOriginalIdea
• WebViewer – a free Java based browser by Reqwireless
• WinWAP by Winwap Technologies

As you can see the diversity is staggering. However there is good news on the horizon – Forrester assures as that:

“over the next few years, the highly fragmented mobile browser market will begin to settle out as regular Web developers target fully capable browsers like Opera Mini and Internet Explorer (IE) Mobile and those based on WebKit.”

Some of the browsers mentioned above such as Opera Mobile or Safari can display HTML (or XHTML) complete with cascading style sheets and 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 constrains of display space and interactivity. 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. Below is the list of most popular markup options in use today.

Another option for developers of the mobile Web applications is to use Mobile Development Platform such as Netbiscuits or Swift. I will describe how such platform may be used using Netbiscuits as an example.

When a mobile device requests a URL of your Mobile Web Application, this HTTP Request

will be routed to and processed by the Netbiscuits platform. The platform is working similar to a proxy server. In a first step, Netbiscuits will forward the HTTP-request to your Web- & Application-Server (e.g.

Apache, Tomcat, IIS, etc.) which hosts the BiscuitML (BiscuitML is an XML-based markup language used to build mobile web pages with the Netbiscuits Platform)Application. As in a normal web application, you will process the request and retrieve content from a Content Management System or database for example. Instead of creating HTML output, your application has to send a HTTP response back containing a valid BiscuitML document. The BiscuitML markup will then be processed by the Netbiscuits platform and be transcoded into the right markup (XHTML MP, WML etc.), specifically optimized for the mobile device that sent the initial request (Software such as WURFL or DeviceAtlas is used to determine parameters of the device) . Although BiscuitML pages can be static pages, in most cases you would create dynamic applications, of course. You can do that by using your preferred programming language like Java, PHP, C#/VB.NET, etc., whatever you find useful to create dynamic web applications. Plugins for certain IDEs are available as well, which make development with BiscuitML easier. The page content itself and also images that should be displayed inline in the pages of your mobile portal can reside on your Web- and Application server. Other multimedia files, especially those used as downloads (e.g. wallpapers, videos etc.), need to be uploaded to the Netbiscuits Media Repository first.

Below is high level architecture diagram of a Netbiscuits web application:

Mobile Web 2.0?

Now we know how create Web Apps for Mobile devices. Next question is – Can we make it Rich? Can we give customers what they come to expect using regular Web? It may be surprising but the Rich Mobile Internet dubbed Mobile 2.0 is the current battleground , with companies such as Microsoft, Sun and Adobe offering their own solutions. 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 devices. So what are the options for RIA on mobile platforms?

Flash Lite

Adobe’s Flash Lite is a scaled-down version of Adobe’s ever-popular Flash Player that is engineered specifically for mobile devices.

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.

Silverlight

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.

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 and Nokia S60 devices) by the end of the year.

JavaFX Mobile

JavaFX is meant to compete with both Silverlight and Flash. JavaFX is a family of products initially comprised of JavaFX Script and JavaFX Mobile. JavaFX Script (JavaFX for short) is a scripting language meant to provide rich user interfaces using syntax that resembles JavaScript and Scalar Vector Graphics (SVG). As its name implies, JavaFX Mobile is intended to be used on mobile platforms.

JavaFX Script is a scripting language that runs on top of a Java runtime. JavaFX resembles Java, JavaScript, and other scripting languages in some of its syntax, but developers can also use the standard Java syntax and make use of an extensive set of Java APIs. Sun claims that Java is the most ubiquitous application platform for mobile devices and can be found on over 2.1 billion devices—a lead it does not intend to give away to the likes of Silverlight or Flash technology. However, where Silverlight on mobile platforms may be considered a young technology, Java FX is, in fact, an infant technology – Java FX Preview SDK had just been released.

JavaFX Mobile is mostly based on technology which Sun acquired when it bought SavaJe in April last year. Sun has developed Java as a technology which it can license to others. However, JavaFX Mobile has been developed as a product it will sell.

Mobile AJAX

Mobile AJAX is nothing more than AJAX used on mobile browsers, in other words, mobile AJAX is just AJAX. Those who believe that writing native application software is the wrong approach to mobile software development (and that native mobile applications are on the way out) may find additional support for their case in “mobile” AJAX. Some mobile browsers do not provide all the necessary technologies and standards (such as JavaScript, CSS, and DOM) required to create usable AJAX applications on mobile devices. Increasingly, however, and as discussed earlier, many do. Opera Mobile and Mini(version 4), IE Mobile, Mozilla’s Minimo as well as browsers on the Nokia S60 and the iPhone, all run AJAX, albeit sometimes with limitations.

The mobile browsers listed above typically fall on mobile devices classified as smart phones or PDAs (or both). Even on these devices, some limitations of AJAX technologies on the devices can lead to issues. For example, JavaScript performance is quite poor on the first iPhone resulting in slow rendering of AJAX pages (on the new iPhone the performance should be much improved). Also, DOM manipulation and extensive JavaScript execution can tax the devices’ CPU and memory—which can impact the device’s performance and quickly drain its power supply. But as the capabilities of mobile devices increase, the availability and use of AJAX in all its forms may also increase. In fact, mobile AJAX may actually help resolve some of the issues associated with mobile browsing. For example, AJAX can be used to make it appear as if the content loads faster by loading only the necessary parts of a page (typically much smaller), on a mobile device. Also of note, in September of 2007, the World Wide Web Consortium (W3C) and the OpenAJAX Alliance held a workshop on Mobile AJAX.