Which mobile device should I target for my application? That's one of the first questions you need to answer as a mobile developer. You might select the device based on personal preference or what looks cool today. The problem is that mobile technology choices are diverse and evolving quickly. The tools and languages used to develop native applications vary wildly and you probably cannot afford to learn them all. Chances are you want to find a way to replicate your application across multiple devices while minimizing your investment.  How can that be done?

Hybrid Is More than a Green Decision
We are all familiar with the idea of hybrid cars and trucks. These vehicles typically combine petroleum and electric technologies to improve efficiency, reducing your carbon footprint.  You can take a hybrid approach for your mobile application by combining multiple technologies to improve your development efficiency, reducing your expenses.  The hybrid approach combines minimal device-specific native code with your application developed with HTML5, CSS3 and JavaScript.  Development of native code is painless through the use of several libraries and tools.  HTML5 provides the underlying capability for storage, drag and drop, timed media playback, and others.  CSS3 dramatically improves the presentation of web technologies enabling a native look-and-feel for mobile applications. JavaScript allows you to use your existing web skills to implement the application.  All of these technologies run within a compatible desktop browser allowing you to develop and test your application without deploying to a device.

The combination of familiar web technologies with minimal native code enables you to develop your application once and deploy to a variety of mobile devices.  Now you might be thinking 'Are these web standards finalized?' and the answer would be no.  However, the HTML rendering engines used in most mobile devices have been implementing the features as the standards are published.  Javascript libraries are wrapping these features and compensating for device differences and standards evolution so your application does not need to.  There are several libraries under development but I elected to use Sencha Touch.

Figure 1 - This diagram depicts the major differences between mulitple native and hybrid application development

Sencha Touch Is My Cup of Tea
The Sencha company logo is a green leaf, presumably because sencha is a Japanese whole leaf green tea.  I am an ardent coffee drinker but I really like this tea.  Sencha is perhaps best known for their Ext JS and Ext GWT libraries.  Sencha Touch is their latest library released late in 2010.  There are several similar libraries in various stages of development, but Sencha was one of the first to market and I am working on commercial products that depend on released libraries.  The first release includes support for Android and Apple iOS devices.  Reading the tea leaves promises future support for Blackberry 6 and Blackberry Torch.  The library is open source and supports a dual license approach making it appropriate for commercial use.  The library includes:

• Robust data integration including access to AJAX, JSONP, or YQL and local storage
• Large library of user interface elements many of which automatically bind to the data objects
• Advanced native look-and-feel styling, animation and branding capabilities
• Model, View, Controller (MVC) support to put it all together

Figure 2 - Example Sencha Touch application running on Apple iPhones

My First Sips of Sencha
I started using Sench Touch in the Summer of 2010 while it was in beta.  I had the typical beta experience of incomplete documentation, a few bugs and changing API.  Over the frequent updates, the documentation improved and examples were updated to align with the latest API.  Throughout the beta and after the production release, I worked on my application.  My application successfully used local storage, tree and carousal navigation, animated transitions, custom search features and selective user updates to content.  The plan is to deploy on Apple iOS devices first with the need for possibly many different branding themes.

I found it quite easy to define enities and storage objects with the data integration features.  The storage objects were extensible enough to add custom search features.  The user interface elements often took some experimentation and reverse engineering to fill in the gaps of light documentation.  I had to become familiar with the inspection and debugging features of Chrome and Safari to ultimately answer many questions.  There are still a few inconsistencies in how user interface element templates are used but overall, the library is quite complete.  One of the most powerful user interface features is the branding support.

The branding support in Sencha uses Syntactically Awesome Stylesheets (SASS). SASS is a scripting language that describes how to generate cascading stylesheets.  Need to change your corporate color across all user interface elements?  Change it in one place and regenerate your native look-and-feel stylesheet.  Sencha Touch ships with a full library of SASS scripts that you can easily extend to meet your branding needs.  This approach also encodes images into the stylesheet to reduce the number of files to deploy.  I was able to extend the SASS to specify branding color selections, omit unused user interface elements and specify the needed icons.

Sencha provides best practice advice for project organization and the use of the MVC support.  Part of the project organization is for unit testing. It is your choice how to test your JavaScript, but the best practice within our organization for other technologies is to use one of the xUnit libraries and include regression testing as part of continuous integration.  I did an informal survey within our development group and found that Javascript is an exception.  Since the bulk of a hybrid application is JavaScript, I found it necessary to evaluate and select a suitable unit testing approach.

Figure 3 - You can also write applications for the Apple iPad

This is Only a Test
A robust JavaScript unit testing library should include support for:

• Continuous integration
• Multiple browser testing
• Event testing
• Mock objects
• Organization of tests (e.g. suites)
• Code coverage reports

I looked at two dozen different options and selected the YUI Test Standalone Library.  This is a project to separate the Test module from the popular Yahoo! UI framework.  It is currently released as a beta and appears to be slated for a first quarter 2011 release.  Running unit tests requires the use of a desktop browser.  Javascript is used to set up the test environment including the suites and tests.  I found the suites and tests to be very similar to JUnit tests.  Several examples are included and enabled me to create a regression suite with a nice summary report like this:

Figure 4 - A unit testing console for displaying progress and results

Manually reviewing unit test results should not be included in a continuous integration development environment. The YUI Test Standalone library includes integration with Selenium Remote Control (RC) to automate the regression test.  Selenium RC is a test server that controls browser sessions for testing your JavaScript. The YUI Test Selenium driver enables a build script to:

1. Start the Selenium RC server
2. Specify the regression test HTML files
3. Specify the browsers to run the regression
4. Run the tests
5. Collect and report the success or failure of the tests
6. Optionally create coverage reports
7. Shutdown the Selenium RC server
   

All of these tasks are done via the Java-based driver included in YUI Test Standalone and can be included as part of a build such as Ant. The coverage report is conditional on a earlier instrumentation step (not shown).  The YUI Test Standalone library includes a Java-based instrumentation utility that creates instrumented Javascript proxies of the files targeted for coverage measurement.  The coverage report step above depends on the instrumented proxies to creat LCOV-based coverage reports. These coverage reports include a very nice report of line and function coverage including a line by line color coding of the coverage of the source.

Going Native
Up to this point, all development and testing has been done on a desktop running Chrome or Safari.  This has enabled a fast turn around in development and the possible use of browser-based web interface testing automation by a quality assurance group.  This is not to say that all testing can be done on the desktop.  Ultimately, device testing is needed and should be done early and often.  How can we get our HTML, CSS and Javascript to run natively on a mobile device?  The hybrid approach we introduced above would have us write a small program in the target technology that wraps and invokes the application.  Luckily, there are libraries and tools that make this painless.  PhoneGap is the option selected for this project.

PhoneGap fills the technology gap between JavaScript and the native mobile device. It provides JavaScript APIs to underlying native function such as:

• Accelerometer
• Camera
• Compass
• Contacts
• Geolocation
• Media
• Storage
• Others

PhoneGap also provides console integration with desktop debuggers, support for six platforms and integrated development environment (IDE) project templates. You must have your target platform SDK installed to use PhoneGap. Since my project is targeting Apple iOS, that means a Mac running the Xcode IDE and the iOS SDK. After downloading and installing the IDE, SDK and PhoneGap, a new project template was available. I created a new PhoneGap project and the template created all the native programs, build targets and default properties and images for me. I copied the application build results into the Xcode project, pressed Build and Run and the application was running in the phone simulator.  It was that simple. No Objective-C to learn or write with less than a day from install to running.

Gaps with PhoneGap
Despite the trivial effort to get the application running on the simulator, there were three minor gaps to address:

• The default target is iPhones.  This means the application would start up and run on an iPad with the dimensions of a phone (with the 2x option).  Sencha Touch reported the platform as a phone even when running on the actual iPad device.  Ideally, the default would be what Apple calls a Universal App that runs on all devices and adjusts itself when running.  After some research, I found that the solution was few mouse clicks away within Xcode.
• Orientation changes did not work.  A Sencha Touch application can change the way it looks based on the orientation of the device.  PhoneGap always reported the device orientation as portrait (0 degrees) even though Sencha Touch correctly reported the current orientation.  The solution was a minor hack to monitor for the window resize event and inform Sencha Touch to do the right thing.
• Certain text was rendered as a link.  Clicking on the link offered to add or update a contact.  What was that all about?  It turns out the default web view component in the iOS SDK attempts to find phone number and e-mail addresses and automatically makes them links to the appropriate app like contacts.  Pretty cool if you want that behavior but does 001-999.9 look like a phone number?  The solution was to add one line of Objective-C code in the PhoneGap generated code to turn this behavior off.
  

Live Long and Provision
In order to get your application running on an actual device you must go through a complex process Apple calls provisioning.  There is a nice step by step procedure to get you through it all available on the Apple developer site.  Now that I have my Sencha Touch application running on an iPad I see that performance work is needed.  Now that automated build and test process is going to pay off.  It is clear to me that a robust development cycle with this technology is possible and practical.

There are bound to be changes in the available libraries and supported devices in the coming months.  Sencha Touch and PhoneGap is a powerful and easy to use combination that is ready now.

Disclaimers

• Opinions expressed in this article are those solely of the author and do not reflect those of my employer.
• iPhone image Courtesy of Apple
• Sencha Touch application images used with permission
• The Android logo is reproduced from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.

References

• Sencha: http://www.sencha.com/
• SASS: http://sass-lang.com/
• YUI Test Standalone Library: http://yuilibrary.com/yuitest/
• Selenium Remote Control: http://seleniumhq.org/projects/remote-control/
• Apache Ant: http://ant.apache.org/
• LCOV: http://ltp.sourceforge.net/coverage/lcov.php
• PhoneGap: http://www.phonegap.com/