Mobile app development is a huge pain point for most enterprises. The debate still rages about the best strategy. Should you develop native apps for the major smartphone and tablet platforms? That's expensive and time-consuming, and it means hiring hard-to-find specialists for iOS, Android, BlackBerry, Windows Phone, and any other platform you want to support. Should you develop mobile Web apps? That is faster and cheaper, but sacrifices both performance and features. Should you develop hybrid mobile apps, combining native app shells with Web views? That still sacrifices performance in some cases, but recovers the most important features.
The Mobile Chrome Apps development kit, recently released as a developer preview, takes the hybrid app strategy. It adds some value to the PhoneGap/Cordova technology on which it is built by combining that technology with many of the core Chrome APIs, giving developers access to a larger palette of capabilities and the ability to target Chrome apps, as well as iOS and Android hybrid mobile apps. On the flip side, this new tool chain is incompatible with some of the niceties available to PhoneGap developers, such as Adobe PhoneGap Build, and it targets only the top two mobile platforms, not the half-dozen or so supported by PhoneGap/Cordova.
As I discussed in my recent review of Google Chrome, Chrome apps are coded in HTML, CSS, and JavaScript, and they use Chrome APIs to access push messaging, drag and drop, and several different kinds of storage, including Google Drive. The user downloads the app from the Chrome Web Store, and it installs on the local computer. The app locally launches in an app container, not in a browser tab, and loads its first page -- not from a remote URL.
Some of the most impressive Chrome desktop apps rely on Flash (or Flex, which also uses the Flash runtime), called from JavaScript. Unfortunately, that won't work on current mobile devices. Apple never allowed Flash on iOS, and Adobe stopped supporting its Flash Player for Android in 2012.
Google's Mobile Chrome Apps tool chain at a glance
Pros
Combines Apache Cordova-based app shells for Android and iOS with Chrome and Google APIs
Easier and less time-consuming than writing separate Android, iOS, and Chrome apps
Adds some value beyond what is included in plain Apache Cordova by giving you Chrome apps as well
Cons
Requires a Mac for the iOS development (unlike PhoneGap Build)
Doesn't support Windows Phone, BlackBerry, or other less important PhoneGap targets
Not exactly the most streamlined, integrated development environment
Platforms Targets iOS 6 or later and Android 4.x or later. Requires Node.js for all targets. Requires Java JDK 7, Android SDK 4.4.2 or later, and Apache Ant for targeting Android. Requires Xcode 5, ios-deploy, and ios-sim for targeting iOS.
Google Chrome meets Apache Cordova
PhoneGap started life as a quick hack at an iPhoneDevCamp event and eventually grew into a widely adopted open source project targeting multiple mobile platforms, under the auspices of Nitobi Inc. By 2009, PhoneGap apps ran on iPhone, Android, and BlackBerry. Adobe bought Nitobi in 2011 and contributed the PhoneGap code to the Apache Software Foundation to start a new project, Apache Cordova. Adobe PhoneGap is now a superset of Apache Cordova, in much the same way as Apple Safari and Google Chrome are supersets of WebKit.
In 2012, Adobe introduced PhoneGap Build, a subscription-based Web application that compiles PhoneGap HTML5/JavaScript/CSS3 projects into hybrid apps for various mobile platforms. The Cordova framework code itself continues to be free open source. Without PhoneGap Build, developers need to install and maintain the SDKs for all the mobile platforms they wish to target. With PhoneGap Build, the chore of maintaining the iOS, Android, and Windows Phone 8 SDKs locally can be avoided, and building for these three platforms becomes a matter of updating your project in GitHub and pushing a button. The latest PhoneGap Build does not support the other Cordova targets: Amazon Fire OS, BlackBerry 10, Ubuntu, Windows Phone 7, Windows 8, and Tizen.
It took me about two hours to install the Mobile Chrome Apps development kit and all its requirements on my iMac. I already had most of the major pieces installed, such as Node.js, the Android SDK, and Xcode, although I needed to do some updates and add Java and Ant to the Bash path. If you're starting from scratch, it may take you longer. If you already have all the prerequisites up to date, you may be up and running in less than an hour. If you're working on a Windows machine, you won't be able to build iOS apps, but you will be able to build Android and Chrome apps.
In addition to providing the application shell, Mobile Chrome Apps gives you access to many of the Chrome and Cordova APIs. The Chrome APIs include:
identity -- use OAuth2 access tokens to sign-in users without prompting for passwords
payments -- sell virtual goods within your mobile app
pushMessaging -- push messages to your app from your server
sockets -- send and receive data over the network using TCP and UDP
notifications (currently Android only) -- send rich notifications from your mobile app
storage -- store and retrieve key-value data locally
syncFileSystem -- store and synchronize files on Google Drive
alarms -- run tasks periodically or at a specified time in the future
The application shell gives a hybrid app retained state that isn't available to a mobile Web app. You can see the difference dramatically on your phone or tablet when you switch to a different app and then back. The hybrid app comes back the way you left it; the Web app doesn't.
If you think about what's being provided by the Chrome APIs listed above, you can see that some important capabilities are missing -- for example, access to the native device file system, access to the device's accelerometer and camera, playing and recording audio, and handling device events.
Fortunately, these capabilities are available, either from HTML5, or from the Cordova APIs, some of which are implemented as device-dependent Cordova plug-ins. The Cordova APIs include:
Accelerometer -- tap into the device's motion sensor
Camera -- take a photo using the device's camera
Capture -- access media files using the device's media capture applications
Compass -- obtain the direction that the device is pointing
Connection -- check the network state and cellular network information
Contacts -- work with the device's contacts database
Device -- gather device-specific information
Events -- hook into native events through JavaScript
File -- hook into the native file system through JavaScript
Geolocation -- make your application location aware
Globalization -- obtain information or perform operations specific to a locale and time zone
InAppBrowser -- launch URLs in another in-app browser instance
Media -- record and play back audio files
Notification -- generate visual, audible, and tactile device notifications
Splashscreen -- show and hide the application's splash screen
Storage -- hook into the device's native storage options
You'll notice that the Indexed Database API, aka IndexedDB, is not listed, either in the Chrome APIs or the Cordova APIs. That's because it is part of HTML5 [33]. Unfortunately, IndexedDB isn't yet supported in iOS Safari. There is a hack to implement IndexedDB over WebSQL that works on Safari, however.
From Chrome apps to mobile apps
The Mobile Chrome Apps development kit implements a command-line tool, cca (Cordova Chrome app), and supports the Android Development Tools (ADT 4.4.2 or higher) and Xcode 5, which in turn includes the Xcode command-line tools. You'll need Java JDK 7 and Apache Ant as well as the ADT for Android development, and both ios-deploy and ios-sim in addition to Xcode 5 for iOS development.
The cca tool is quite similar to the Cordova phonegap command-line tool. Like phonegap, cca can create a project in a directory, add or remove a plug-in, add or remove a platform, build a project, and run a project on a platform. In addition, cca can check its environment, copy an existing Chrome app project into a new Mobile Chrome project, and run a local Web server.
Note that after editing the Web source code, in either IDE or any other editor, you need to run the cca prepare command to generate updated mobile code before it can be reflected in the emulator or simulator. Among other things, the cca prepare command copies the contents of the "www" project directory into the two platform-dependent directories platforms/android/assets/www and platforms/ios/www, copies the Cordova JavaScript files, and generates manifest JSON files.
Unfortunately, the cca prepare command messes up the flow for a developer who wants to "live" in one of the IDEs. If there is a way to incorporate this command into the build cycle automatically, I haven't yet found it -- although in principle it should be simple. Worse, when you run the cca prepare command, the IDEs don't automatically reload the updated manifests. They just complain that the manifests are out of sync and refuse to run the project until you manually force the synchronization.
Given that the Mobile Chrome Apps tool chain is currently billed as nothing more than a developer preview, these limitations are reasonable. At the same time, I'd love for it to have better IDE integration. I'm looking forward to the next version, but in its current state I wouldn't want to try to ship an app using it.
