Google has announced and released a preview for porting Chrome Apps to mobile devices. Tentively called Mobile Chrome Apps the whole thing can be found over at Github. What this does is bring most the Chrome Web app API to Android and iOS. It does that by wrapping up cordova/phonegap with some custom plugins in a tool that allows import of those existing web apps.
Essentially it is cordova. The command line tool cca is a node.js script that wraps the cordova module. When you create a new project under the covers it’s calling into cordova, adding the Android and iOS platforms, then applying a list of custom plugins to provide the org.chromium.* namespace. Additionally it allows you to symlink or copy any existing web app you already have by pointing to the manifest.json location. Beyond that many of the same deployment commands are the same just using cca instead of cordova. For example, cca run android in place of cordova run android.
Unfortunately this means that it does not provide a Chrome webview on any platform as the name might imply. Platforms will still use the standard WebView implementation available to them. This means that, ironically on Android in particular, certain HTML5 functions might be missing depending on the OS version being used. Standard cordova development tips apply here and the chromium team has provided a short tip list.
Application Breakdown
While it’s not exactly cordova project, the cordova command fails inside a cca created app, anyone who’s used cordova/phonegap before knows that the real magic is in the plugins. A Mobile Chrome App uses a mix of standard cordova plugins (e.g. file, inappbrowser, keyboard, network-information, statusbar) with custom google plugins for many of the org.chromium.* javascript namespaces.
So can you use those plugins in your cordova projects? Yes!
Well, for the most part. They’re built on the standard plugin framework and some of them have already been published to the cordova plugin repo. The only thing you might have to be wary of is if a plugin relies on a Chrome App lifecycle event.
You can get a list of ‘normal’ plugins with a cli search.
cordova plugin search org.chromium
Here’s the list as of this post:
org.chromium.commonorg.chromium.frameworks.googleopensource— This plugin adds the Google Open Source iOS framework to a project.org.chromium.frameworks.googleplus— This plugin adds the Google Plus iOS framework to a project.org.chromium.identity— OAuth2 authentication for Android and iOS. On Android, it uses Google Play Services, and on iOS it uses InAppBrowser.org.chromium.notifications— Plugin for showing notifications on Android.org.chromium.polyfill.blob_constructororg.chromium.runtimeorg.chromium.socket— Client and server sockets for Android and iOS.org.chromium.storage— Provides an implementation chrome.storage.local and chrome.storage.sync (but does not actually sync).org.chromium.syncfilesystem— Refer to docs at: https://developer.chrome.com/apps/syncFileSystem.html
The full list of contributed plugins is located here. They can be installed if you checkout the project locally and point to that location.
What’s missing?
Currently the project lacks full Chrome API support, a list of available features has been made available and will hopefully be kept up to date. Certain HTML5 and other features are missing too, again depending on the version of the platform. Here’s the current list:
- no <webview> tag
- no IndexedDB
- no getUserMedia()
- no NaCl
If you already have a Chrome Web App in a CRX bundle there is an android test harness available which will allow you to test your apps on a phone. This is a modification of the cordova testing harness but works the same way.
How does it start up?
The cordova config.xml content element points to a page that requires cordova/channel and then calls boot() on org.chromium.bootstrap.mobile.impl. This is a new API added to the normal chrome APIs. Its purpose it to allow cordova plugins a chance to initialize.
boot() is waiting for all device ready listeners to have finished. Then it inserts an iframe that causes the parent page to call bootstrap.mobile.bgInit passing itself as the background window. The manifest is read and the scripts specified by the background property are inserted into the window. On load of this window, the regular chrome app lifecycle starts up. Including the launched event that the background script is listening for to create a window.
After that point the app should behave as if it was launched in the browser (with the cavets already covered above.) More details can be found in the bootstrap plugin
What does it mean to me?
If you don’t have a Chrome App already this is very likely to mean nothing to you.
It’s been implied that this is Google’s way of making mobile app development easy. In reality it’s no more easy than it was with cordova/phonegap. While you could just drop your developed-for-the-web application in and be done, you’d find that the results are not going to be very good.
Just a quick drive through the provided example projects will demonstrate this easily. Pages aren’t scaled correctly, buttons are too small, etc. Work will have to be done to correctly render for the variety of screen sizes you app now faces, aka responsive design. If you really wanted that native feel you’ll have to do a little more work to fake the native components on each device.
On the other hand, if you can use Google services (Sign-On, Google Drive storage) and/or have a need for a mobile and a desktop version of an application. The Chrome platform can provide a single base platform on which to develop making it a nicer alternative to an aging technology like Flex.