PhoneGap for Mobile App Development

Related Article: Mobile Development Options for .NET Developers

The world of software would probably be a better place if developers could code mobile applications using one programming language, one framework, and even one type of computer. Alas, that's never been the case, and I can hardly foresee it happening in the near future. Sometimes, you simply have no other choice than to write the same mobile application for a variety of mobile operating systems. This is a difficult option because it doesn't offer any smart, elegant, or even smooth exit strategy. You can take any of several approaches to writing a mobile app for multiple platforms, but each of these approaches carries risks.

The most obvious approach is to write distinct apps—one per mobile platform you want to support. However, doing so can be an expensive proposition. Additionally, writing a mobile app for several platforms is not conducive to agile software development. Unless you can count on having the development resources to build the apps in parallel, you're better off finishing one app before attacking the next one. Furthermore, this waterfall-like development approach could even be detrimental to the app's success, depending on the category of the app. The other options are to attempt to increase your development budget or to distribute the application over a period of time and limit the mobile platforms that the app supports.

Although developers would likely agree that there's no known silver bullet to kill the mobile beast, many developers see the PhoneGap mobile app development framework as the closest thing to a silver bullet that exists for mobile app development. But is PhoneGap as good as it seems? In this article, I intend to answer that question based on my experience with using PhoneGap. I will examine the overall architecture of PhoneGap and suggest ways that you can get better results using it to write mobile applications in specific scenarios.

PhoneGap at a Glance

PhoneGap was originally developed by Nitobi, which Adobe Systems acquired in 2011. After acquiring Nitobi, Adobe donated the code for PhoneGap to the Apache Software Foundation, renaming the original codebase Apache Cordova and making it an open source project. Adobe and other companies and individuals contribute changes and extensions to Apache Cordova. So essentially, PhoneGap is simply the first (and widely popular) distribution of the Apache Cordova open source engine.

PhoneGap is built around a simple and smart idea. You write user interface (UI), navigation, and business logic using HTML, Cascading Style Sheets (CSS), and JavaScript; then the entire web project is packaged in a container compiled as a native application for a variety of mobile platforms. The potential is tremendous: You write UI and logic once and package it up to a number of mobile apps for most popular platforms, such as iOS, Android, and Windows Phone.

PhoneGap offers an engine to package the set of web resources into an embedded web view. It also offers a comprehensive and consistent API to access device capabilities and sensors and command them from within your JavaScript code. More important, you consume the device API in the same way regardless of the actual device and mobile platform. So at first sight, PhoneGap is a huge win from whatever perspective you look at it. It allows you to leverage existing web skills and limits exposure to device and mobile platform internals to a bare minimum. One could say that a PhoneGap application is essentially a mobile single-page application that the PhoneGap API can compile to a native package for each of the supported mobile platforms (e.g., APK for Android, IPA for iOS).

PhoneGap in Action

Here's the typical workflow you follow to write mobile applications using the PhoneGap framework. First, you use your favorite web IDE to write a bunch of HTML pages. This has to be a 100 percent client-side solution, and navigation between pages is managed either through plain hyperlinks or by swapping div elements. If HTML pages need to access certain device capabilities such as contacts, camera, or vibration, you have available a JavaScript API that is consistent across all mobile platforms. The JavaScript API comes through a .js file you obtain from the PhoneGap download and reference from your HTML pages. The entry point in this web solution is commonly an HTML file named index.html, which is the only file in a root directory. (Note that this is only the most commonplace approach, and names and structure are arbitrary.)

Once your web application is up and running, your next task is to convert it into applications for different mobile platforms. You create a native project for each of the platforms you want the app to run on—such as Android and iOS. Note that the list of supported frameworks goes well beyond iOS and Android and also includes BlackBerry, Windows Phone, and Tizen.

Yes, you got it right: You need a distinct project for each platform. In particular, this means that you still need a Mac to turn your web solution into an iPhone or iPad application. Moreover, it means that you must be able to manage intricacies of native iOS and Android projects (and more). For example, for Android you need an IDE such as IntelliJ IDEA, Android Studio, or Eclipse to build an executable. Using your chosen IDE, you will create a project, add an activity class that inherits from a PhoneGap-provided Android class, and play with the exposed API. To be honest, even though creating the project is not much work and requires no advanced skills, it is nonetheless work you cannot avoid.

Let's look at an example. Listing 1 shows an Android activity that backs up a PhoneGap project.

package com.expoware.squarify;import android.os.Bundle;import org.apache.cordova.Config;import org.apache.cordova.DroidGap;public class SquarifyActivity extends DroidGap {    @Override    public void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);    super.loadUrl("file:///android_asset/www/index.html");    }}

You don't need more code than this. In Android, an activity is nearly the same as a window. The code in Listing 1 just initializes the window and sets its content. The DroidGap class is part of the PhoneGap framework. The loadUrl method retrieves the root HTML page from the resources of the application and creates a full-screen web view where the previously created web application is run. Figure 1 gives you an idea of the results of this code. The yellow area is the full-screen web view.

Figure 1: Layout of a PhoneGap Application in a Device

It should be noted that Adobe also offers a cloud-based build platform, Adobe PhoneGap Build, which saves you the trouble of managing and maintaining projects. Get a paid subscription to the platform, and you'll be able to upload web sources and download mobile binaries.

A Closer Look at PhoneGap

PhoneGap has plenty of advantages, but it isn't perfect. First off, the web UI that PhoneGap generates is hardly specific to the mobile platform. You'll also have to make a "devil's alternative" choice to build either an app that is highly responsive to the user's touch or one that provides an optimum and truly native user experience (UX); with PhoneGap, it is difficult to do both. To add value to the app, you might want to make its UX as close to native as possible, but this is hard to achieve with plain HTML. To accomplish this, you might need additional JavaScript libraries, but the more JavaScript you add, the more you lose in fluidity and responsiveness. The risk is that you'll eventually deliver a PhoneGap app that looks like a true iPhone app except that it is far slower! Overall, the best (or the least problematic) way to give a more native UI to a PhoneGap app is by using distinct style sheets. Using CSS alone, you might achieve much of what you want in the app's UI but not everything.

Another point to consider is that the performance of a PhoneGap application is inherently tied to the performance of the browser mounted on the device and the internal implementation of the WebView widget around it. Like it or not, mobile browsers are not all the same. You are responsible for accommodating differences in the Document Object Model (DOM) implementation and working around performance issues, if you find any. As the complexity of the solution grows, you might find yourself maintaining platform-specific versions of the web code that was originally supposed to be just a single app for multiple mobile platforms. This predicament can certainly be mitigated by good programming techniques, yet it is a challenge that you will have to tackle.

A PhoneGap Case Study

To summarize my experience with PhoneGap, I'd say that I've found it to be good enough on iOS devices and to perform adequately (but far from great) on most Android smartphones in the middle and low segments. I just don't like it on Windows Phone. I've only played with PhoneGap on a couple of other platforms. That said, about a year ago my company submitted a proposal to deliver an application on four different mobile platforms. It was a time-sensitive app bound to a public event at a low price point, and the app would have an overall lifetime of only a few weeks.

Initially, we made the quote based on PhoneGap prototypes and our faith in the PhoneGap promise of write an app once and compile it anywhere (and possibly quickly). What we learned, though, is that while the promise of PhoneGap is substantially fulfilled—you really can write a web app and compile it quickly on a few mobile platforms, the final result is not always what you wanted and hoped for. As it turns out, you cannot blame this state of affairs on PhoneGap. Rather, it all depends on your app's design and how the app is coded.

Having confirmed that we were obtaining poor applications because of our code and browsers, we faced the challenge of building four apps within a budget that barely covered full development of a single iPhone app. The main problem we had was with UI and page transitions. In a nutshell, if you want the app to be fast, you have to give up effects; if you want effects, you'll get an app that has far less speed and fluidity than a native app.

At the same time, we noticed that our app essentially consisted of a few independent pages tied together by a main menu. We then opted to create a native skeleton for the app in iOS, Android, Windows Phone, and BlackBerry. Sure, this created four distinct native apps, but each app was fairly simple. We had a static main page made up mostly of graphics and links. Then we created empty pages for each link and set up navigation. But how would the app generate actual content? To build in this capability, we added a WebView widget to each page and made it point to a remote URL that returned HTML. Figure 2 illustrates the layout we arranged. Finally, we applied a selective choice of colors and styles, making the content of the WebView nearly undistinguishable from the surrounding native UI.

Figure 2: Content for WebViews Downloaded from a URL and Cached Locally

This solution worked well for the particular type of application we were building, and I don't recommend blindly using this approach for just any type of mobile app. Fact is, this hybrid solution worked beautifully for us, allowing us to deliver four apps perfectly on time and on budget with a three-person team.

PhoneGap: The Reality

PhoneGap comes with the promise of reusability: Write your mobile application once and port it to as many as seven different platforms. Although PhoneGap largely fulfills this promise, I'm not sure that PhoneGap is the silver bullet that can always kill the mobile beast. PhoneGap works well in scenarios where providing a truly native experience is not your primary concern and when setting up a UI and UX common to many platforms is acceptable (e.g., gaming).

Beyond just trying out PhoneGap for yourself, I recommend that you experience the power of WebView in basic mobile development. A WebView in mobile platforms is more powerful and lightweight than any WebBrowser component you might have used. A WebView is worth using for displaying both static HTML and downloaded content. In the aforementioned project, downloaded content saved us a few times, allowing us to make last-minute changes without having to publish updates.