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.
Google's Mobile Chrome Apps tool chain at a glance
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
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.
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
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 . 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.
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.
This story, "Google's tantalizing Mobile Chrome App SDK" was originally published by InfoWorld.
PayPal has fixed a serious vulnerability in its back-end management system that could have allowed...
iOS 10 at its most basic level is a platform for mobile devices that will allow apps to evolve in ways...
The creator of Linux talks in depth about the kernel, community, and how computing will change in the...
Going back to school? Here are some of the best laptop backpacks for every situation, whether you're...
Tech giants don't want to live in a world where someone else makes the world a better place better than...
The latest additions to Google's mobile OS should give you plenty to chew on
One security research company is taking a controversial approach to disclosing vulnerabilities: It’s...