PhoneGap: a misunderstood hybrid framework

17 Oct 2012

A few mobile approaches

I think it's clear for everyone now that there are a few possible approaches to creating a mobile app. Many people have blogged and presented about them, including this recent deck from Martin Fowler. We've seen each approach offers a tradeoff between many axes such as cost & user experience, and they're usually labelled like this:

Where does PhoneGap sit?

Interestingly, PhoneGap is often put in the WORA bucket, or mistakenly compared to runtimes like Titanium. After all, PhoneGap allows you to write an app in Javascript and run it on any device. I often hear as well that PhoneGap is used to wrap a website into an app. Let's clear things up. PhoneGap does allow you to embed an HTML/JS/CSS "web page" into a native shell, but its real strength lies in its more advanced usage: as a hybrid framework! What's a hybrid framework you ask? Let's have a look at the major features we typically need when building a hybrid app from scratch:

Building a hybrid framework

A custom webview

The idea being to display web components, it all starts with a web view! This webview should be able to load HTML (locally or remotely), and run Javascript and CSS. All major smartphones come with an XYZWebView, the only thing you'll have to watch for is the (decreasing) gap in HTML/CSS support between them.

The bridge

Next step is allowing Javascript code in that webview to call your native code, and vice versa. All platforms can do this, but unfortunately they all do it differently.

The reverse bridge is usually much easier: if the webview exposes a global javascript function, the native code can simply call it passing any required arguments. The trick just lies in that call being synchronous or not, depending on the platform.

Some plugins please

A solid bridge is a first step, but most calls will end up looking something like this:

The typical plugin

You don't want to write too much boilerplate code for every "bridged" method, which is why a well-thought plugin system is the backbone of a hybrid framework. It should be easy to define new native components, their inputs, how to tell when they have finished running, and their success or failure. That includes callback management and cleaning up!

So why PhoneGap?

When PhoneGap started, it really offered a single WebView with bridging capabilities. Single WebView = single webpage. This doesn't mean we have to wrap a plain old server-heavy website, we can still follow good client-side practices. Still, calling out to native code feels like an exception: you call the native bridge to set alarms, open the camera, or show a custom UI overlay. A lof of successful apps still operate this way, but it has limitations: the core of your app is always HTML, and native components sometimes feel "drawn on top".

Things have changed now. After a few years and a couple of versions, Project Cleaver is now available for iOS and Android. Think of it as PhoneGap upgrading the WebView to a first class citizen. Your app is no longer a WebView, it contains a WebView. Or several!

One app, multiple web views

Instead of having an HTML page that sometimes displays native widgets, why not turn it on its head? You can have a fully native app displaying HTML widgets when applicable. Each of these components will reside in a WebView, and interact with the rest of the app through the bridge. If it makes sense, a WebView can even host a entire flow - for example 3 consecutive pages for which HTML/JS/CSS do a great job. Hey, if it works, you can start with the entire app in a WebView. The important thing is that it's up to you.

With the ability to mix and match native and web, we can always choose whichever is more appropriate for each feature. Is HTML rendering well? Probably a good choice: you'll get the portability and development speed. Need the best experience and performance? Go native. You can also seamlessly transition components from one to the other as it makes sense.

Of course you guessed it, Cleaver (now called CordovaWebView) provides all the "bridge" features we talked about, and does so quite nicely. The plugin system is relatively well designed, and yes its evolving API is a slight pain but also an example of how the framework keeps moving forward.

What about my custom framework?

This one sounds cheesy, but let's face it: PhoneGap had years of testing on multiple devices, and a team dedicated to it. I never thought much about it until I started following the source code and bug tracker, and stumbled upon things like these:

A bad reputation

So why does PhoneGap have a bad reputation? I keep hearing team X tried PhoneGap and it looked nothing like a real app: slow and clunky. Or team Y tried PhoneGap and had to throw it all away. My guess is PhoneGap effectively lowered the barrier of entry into the native territory. They made it easy for anyone to wrap a website in a WebView - done! Apply the label built with phonegap. Unintentional brand-damage. In fact, I think it's similar to the original Apple vs Android apps debate. Yes, many Android apps were of lower quality: all you needed was a knowledge of Java, and no approval process. However it's no reflection on the actual technology. PhoneGap done the right way is actually pretty powerful. Just pick one and start building:

A few pointers

Personally, I try to stick by these rules for any HTML widgets, and things usually turn out ok:

Now have fun in the hybrid world Smiley

Comments