MobileFeature

App Cloud vs PhoneGap: a web developer’s view

Brightcove developer Adam Mark builds the same app on PhoneGap and Brightcove App Cloud to demonstrate the differing strengths of each system

When I talk to developers about App Cloud, they often ask, “How is App Cloud different from PhoneGap?” Without missing a beat, I give my stock answer: “PhoneGap is great, but App Cloud gives you so much more.”

The matter of more has always nagged at me (more is not necessarily better) so I decided to do an apples-to-apples comparison from a web developer’s perspective. I built the same app twice, first on PhoneGap, then on App Cloud, and graded each system on the strength of its platform capabilities, development model and service offerings.

First impressions

PhoneGap:

I located and downloaded the latest version of the PhoneGap SDK in about 15 seconds without any fumbling. This made a great first impression. I noticed PhoneGap offers a public archive and full documentation of its old SDKs, which gave me peace of mind as a developer. What’s more, I found PhoneGap.com to be neatly organised, with clear pathways to documentation, community support and case studies.

App Cloud:

I registered for a free account before downloading the SDK. (If you’re impatient like me, you’ll find the registration step annoying. But it’s necessary if you want to use cloud services like cloud compilation, push notifications, and analytics.) After registering, I landed in App Cloud Studio, where I found links to the SDK, the Workshop app, video tutorials and community support. I downloaded the SDK and the Workshop app.

Getting started

PhoneGap:

I unzipped the SDK, cracked open the getting started guides, and followed the instructions for setting up my development environments on iOS and Android. What looked simple on paper turned out to be insanely complicated.

Getting started on iOS required downloading and installing XCode. But to download XCode, I had to upgrade my operating system to version 10.7 from version 10.6.8. This took four hours.

Getting started on Android was even more of an exercise in patience. I downloaded Eclipse, then the Android SDK, then the Android Developer Tools plug-in. At each pass I was presented a dizzying array of options. For example, there were 12 versions of Eclipse and 11 versions of the Android SDK:

Phew! All told, getting started with PhoneGap took nearly a whole day, and I had yet to write a single line of code.

App Cloud:

Getting started with App Cloud was a breeze by comparison. First I downloaded the Workshop app onto my iPhone and Android phone. Then I unzipped the SDK, double-clicked the Node.js installer, ran the startup script, and opened the App Cloud development server in my browser. In about 10 minutes, I was ready to start coding.

Hello World!

PhoneGap:

I opened XCode and followed PhoneGap’s 'Hello World' instructions for creating a new Cordova iOS project from a shell script. This appeared to work until I tried running the project in the iPhone simulator:

As it turned out, the local copy of the getting started guide was out of date and omitted a key step: installing the Cordova library. I deleted the project, installed the Cordova library, and ran the script again. Then I tweaked index.html and opened the app in the simulator:

Nice! Getting the app onto my iPhone was a bit trickier. I had to register my device in the iOS Provisioning Portal, then create a provisioning profile, then create a development certificate, then install the certificate. While these steps are necessary to create an iOS app in any framework, it was cumbersome to go through these motions just to run my 'Hello World' app.

As for Android, it once again threw me for a loop. I simply couldn’t get my 'Hello World' app to run in the Android Emulator despite all my attempts to create and launch an Android Virtual Device in Eclipse. After a frustrating couple hours — even Stack Overflow was no help — I managed to create a device image via the Android SDK Manager, then launch the emulator:

App Cloud:

I ran the provided Node.js script to create a starter app inside App Cloud’s development server. Then I popped open Chrome and navigated to the app:

I made a few changes to a CSS file and refreshed the web browser — a quick win. Then I opened the Workshop app on my iPhone and scanned the QR code that appeared in the web browser. In three seconds, the app loaded on my phone. I made some more changes to the CSS and pulled down the Refresh tab in the Workshop. The changes appeared. Then I did the same thing on my Galaxy Nexus.

I’ve gone through this process a thousand times now, yet I’m always floored by it. In just a few minutes, I was previewing an app on both iOS and Android, making changes, and seeing the changes take effect immediately. And I did it without XCode, without the Android Developer Tools, and without any specific knowledge of native app development.

Structuring the app

PhoneGap:

I wanted my sample app, a simple news reader, to have two distinct views: one for displaying the latest news and one for displaying my saved articles. I assumed I could use two HTML pages to create the backing for these views, but I was surprised to learn that I had to build my entire PhoneGap app within the context of a single HTML page. I imagined my code would get pretty messy without using a JavaScript MVC framework to manage it, and I worried about the performance implications of doing too many things inside one page.

I was also disappointed by the lack of support for native navigation across iOS and Android, so I had to roll my own navigation in HTML. Not wanting to use an iOS-style tab bar on Android or an Android-style action bar on iOS, I settled on a generic design that would accommodate both platforms.

Finally, I didn't find any built-in functions for handling basic tasks like scrolling and pagination. After exploring a few different UI libraries, I decided to install jQuery Mobile, a popular tool for building mobile web sites.

App Cloud:

Unlike PhoneGap, App Cloud apps are backed by multiple HTML files, each corresponding to an independent view in the UI. A typical content-driven app may have four or five views, and the developer can choose whether or not to display native navigation to help the user navigate from view to view. In this sense, the UI is truly 'hybrid'. On iOS, users see the familiar tab bar and More … menu; on Android, users see an action bar.

As I discovered early on, spreading code and functionality across multiple views is a good thing for a few reasons. First, the native container can unload individual views if it needs to free up memory (instead of crashing). Second, developers can neatly organise code by view (each HTML page has its own DOM, its own CSS, and its own JavaScript). Finally, because the app is broken into multiple views, the code itself is more portable.

App Cloud has a thin UI layer, but it does 90 per cent of what I need: tap events, smooth scrolling and page transitions inside a single view. I like having these basic functions available out-of-the-box. As with PhoneGap, App Cloud lets you drop in third-party JavaScript libraries. (I’ve used many, including Moment.js for date formatting and Hammer.js for gesture support.)

Another nice feature: App Cloud loads HTML templates from plain text files on the device’s file system and populates them in the bc.templates object. This makes it easy to separate control logic from presentation logic using Markup.js (included in the App Cloud SDK) or a templating framework of your choosing.

Making the app

PhoneGap:

Even though I was able to use my favourite text editor and stage the app on a local web server (Apache), I still had to run XCode and Eclipse in order to build and preview the app on my iPhone and Nexus. Every few minutes I went through the same motions: first, switch contexts from my text editor to Xcode, then to Eclipse; second, run the app in the iPhone simulator, then in the Android emulator; and third, deploy to each device. This got tiresome (I looked at PhoneGap Build as a potential time saver, but it didn’t strike me as a convenient development tool. It’s a build tool, as the name implies. I also looked at Hydration but got scared away by the docs. (What’s a “non-Hydrated binary equivalent?”)

At this point it occurred to me that I was dealing with two different code bases to make two different apps, one for iOS and one for Android. A fellow engineer suggested I create a symbolic link between the www directories in each project, which seemed unwieldy to me.

App Cloud:

I staged my app in App Cloud’s local development server (running on Node.js) and tested much of it in Chrome. When it came to testing the app on my iPhone and Nexus, I simply pulled it up in the Workshop app.

The Workshop app extends the development model that all web developers have come to know: code, refresh, repeat. The ability to test an app incrementally — without long delays and without having to reboot the app — saves a tremendous amount of time and frustration.

Finally, unlike PhoneGap, I was working with a single code base of HTML, CSS and JavaScript files, even though I was building for iOS and Android at the same time. There was simply less code to move around.

Working with content

PhoneGap:

I pulled an RSS feed directly from my web site using jQuery’s get() method. Then I converted it to JavaScript object with the help of an XML to JSON plug-in. To cache content on the device, I used localStorage methods.

App Cloud:

As with PhoneGap, I used $.get() to pull down the RSS. When it came to storing data on the device, I used bc.core.cache(), which uses a Least Recently Used (LRU) algorithm to clear data if the cache ever fills up. App Cloud’s caching function also handles serialisation and deserialisation of objects.

Taking it a step further, I decided to run my data through an App Cloud content feed, then load it using the SDK method bc.core.getData().

This service has multiple benefits. First, it lightens the load on the origin server (in my case, a small Wordpress site). The App Cloud server periodically fetches new data, caches it and makes it highly available to thousands of devices. Second, App Cloud reduces the size of the payload by eliminating unnecessary data fields. Third, App Cloud converts the data from XML to JSON on the server side, flattens it, compresses it and provides a convenient interface for accessing it.

Working with the device

PhoneGap:

While I didn’t really take advantage of native device capabilities, I noticed that PhoneGap’s device API is more mature than App Cloud’s. For example, PhoneGap supports access to the contacts database and Compass. It also has a nice interface for determining the device’s connection type. And the API itself is very well organized.

App Cloud:

While App Cloud offered less in the way of device capabilities, there were some built-in features that I found to be invaluable. First, it’s often necessary to display external web content without forcing the user to leave the app. For this reason, the App Cloud SDK makes it extremely easy to open native modal windows. (PhoneGap has some plug-ins for this, but they require extra configuration.) Second, many types of content apps require multiple, distinct views. By default, App Cloud supports multiple views backed by native navigation controls. Developers can hide the navigation bar outright or toggle it via bc.device.enterFullScreen() and bc.device.exitFullScreen().

Note, App Cloud will soon release its own plug-in development kit that allows developers to create custom native functionality on top of the App Cloud SDK.

Running the app

PhoneGap:

From a distance, it was hard to distinguish between PhoneGap and App Cloud. But there were a couple issues with PhoneGap. I was unhappy with the smooth scrolling (or lack thereof) in jQuery Mobile, my chosen UI layer. I considered switching to Kendo UI Mobile, but I didn’t want to pay $199 for it. I also looked at Sencha Touch, but it was too bulky (a 55MB download). I settled on iScroll. Problem solved. Also, the part of my UI that displayed multiple images (at 150KB each) was noticeably slower to load.

App Cloud:

I cheated here and used App Cloud’s image transcoding API, even though it’s not part of the free edition (App Cloud Core). I cropped and scaled each thumbnail image on the fly, shaving nearly 1MB off the total payload and speeding up the rendering of the UI. Sure, I could've cut up these images by hand, but that’s simply not practical to do when delivering dynamic images to multiple platforms across many types of devices.

I also saved a few cycles by loading my data through an App Cloud content feed. Not only was the payload smaller, I didn’t need to convert it from XML to JSON on the client.

App Cloud’s smooth scrolling was also faster than iScroll when handling complex content.

One final note on performance: both apps ran faster on iOS than on Android.

Building the app

PhoneGap:

Since I had already done the hard work of setting up XCode and the Android Developer Tools, building the app for production was relatively straightforward. I just repeated what I had already done a dozen times during development (although I added my own icons and loading images).

App Cloud:

I zipped up the directory containing my static assets — HTML, CSS, JS, etc — and uploaded it to App Cloud Studio. Then I clicked Publish App and was asked to enter tons of provisioning information for iOS and Android. Although tedious, this process was certainly easier than having to build the apps myself and, at the end, I was able to download an IPA file for iOS and an APK file for Android.

And the winner is...

I think PhoneGap and App Cloud are both winners, but in different categories. PhoneGap wins for having a more robust device API, great documentation and examples, and a large ecosystem of plug-ins. (As I mentioned above, App Cloud is about to release its own plug-in framework, and it will support many PhoneGap plug-ins.) App Cloud wins for its elegant development model (the Workshop app is simply unmatched) and for its array of cloud services.

The biggest distinction is this: while PhoneGap is a development platform, App Cloud is a development platform and an operational platform at the same time. In my simple demo app, I took advantage of two App Cloud services: image transcoding and content feed optimisation. I also compiled my iOS and Android apps in the cloud from a single code base. In a more complex app, I would use App Cloud’s push notification system, real-time analytics, and remote configuration capabilities. Sure, these things are possible with PhoneGap, but not without cobbling together lots of moving parts from many different vendors.

I encourage web developers who are exploring hybrid-native solutions to evaluate both platforms as I have. You may find PhoneGap to be exactly what you’re looking for: a cross-platform development kit. But if you need more in the way of services (image transcoding, content optimisation, push notifications, etc) and less in the way of heavy toolchains (XCode and Eclipse), take App Cloud for a spin.

Both App Cloud and PhoneGap have a lot to offer. I hope they continue to push each other, and web developers, forward.

Subscription offer

Log in with your Creative Bloq account

site stat collection