Introducing Google's new Cordova-based toolchain
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 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.
f 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-sim in addition to Xcode 5 for iOS development.
cca tool is quite similar to the Cordova
phonegapcommand-line tool. Like
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 preparecommand 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
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, "Preview: Google's tantalizing Mobile Chrome App SDK" was originally published by InfoWorld.
In this webcast, we will discuss the IoT development landscape focusing on common development...
Native packagers can cause delays and frustration for you and your end users when you are trying to...
Find out how Eclipse, NetBeans, JDeveloper, and IntelliJ IDEA stack up today in capabilities and ease...
Three iterations of a client-server example demonstrate the timeless utility of Java I/O, while also...
From CIO to PC technician, salaries for technology-related jobs are on the rise. This IT salary guide...
The parallel and concurrent compacting garbage collector is aimed at in-memory databases and other...
Devotees talk about what's good (ease of use, IoT potential) and not so good (design issues,...
Editing code for readability is an up-front investment that can pay big dividends in the long run.