Porting Chrome Apps to Firefox OS Apps

 This article reviews the difference between Firefox OS appsChrome apps and provides examples for porting your Chrome app to an Open Web App.

Overall File Structure

Google Chrome apps are very similar to Firefox OS apps — they are built using web technologies, and their manifest file format is also similar to an extent, but the platforms differ in terms of syntax, file structures, and available APIs:

• Open web apps will let you use any file structure you want — they are just web apps, so you can use accordingly.
• Though, Chrome apps are pretty flexible in structure as well, but you need to know certain things . Chrome apps also have the concept of background pages, HTML/JavaScript that run in a background process and handle app functionality behind the scenes.

The manifest file

Both Chrome apps and Firefox OS Apps use a manifest file to define and control various parts of the app, including developer name and contact, icons to be used, and API permissions. Both use a JSON format and live in the root of the app directory. Let's move along and see what are the basic differences.

For our first example we'll use the Hello world  from the Google Chrome sample app repository. Grab this by running the following git command:

git clone https://github.com/GoogleChrome/chrome-app-samples

You can find a Firefox OS app version at David Clarke's github repository here:

git clone https://github.com/dclarke/firefox-os-sample-apps

Chrome manifest files have a .json extension. The original Hello world manifest.json looks like this:

 {  "manifest_version": 2,
    "name": "Hello World",
    "version": "2",
    "minimum_chrome_version": "23",
    "icons": {
         "16": "icon_16.png",
         "128": "icon_128.png"
     },
     "app": {
         "background": {
         "scripts": ["main.js"]
         }
      }
   }

Firefox OS App manifests have a .webapp extension; the converted manifest.webapp looks like so:

 {  "name": "Hello World",
    "description": "Hello World",
    "launch_path": "/index.html",
    "icons": {
        "128": "icon_128.png",
        "16": "icon_16.png"
    },
    "developer": {
        "name": "David Clarke",
        "url": "https://github.com/onecyrenus/firefox-os-apps"
    },
    "default_locale": "en",
    "permissions": {
    }
 }

TBD manifest features table showing the equivalents across the two formats (?????)

Reference docs:

• Chrome manifest files reference
• Mozilla manifest files reference

API Support Differences

APIs support across Chrome apps and Firefox OS Apps differs; while porting an app , you will need to do an inventory of the platform-specific APIs you are using, write equivalent functionality for the target platform, and potentially create a level of abstraction around them. The naming & capabilities of the APIs vary across the platforms, and in this section we need to have a look  at the followings:

• The different-but-equivalent device APIs supported across both platforms
• Where to find more documentation on each platform
• Which APIs have no commonality or equivalents across both platforms (Firefox or Chrome).

WebAPI equivalents across platforms

The WebAPI equivalents that share common function across the two platforms are listed in the following table:

Read more information on some of the HTML5 APIs Chrome supports.

As a developer, you may wish to port apps between Chrome and Firefox OS. But the difficulty lies in converting functionality between equivalent but incompatible APIs, where the APIs used to deviate from web standard APIs. In most of the cases, the function calls are different as well as the data being returned. To work around this, you could manually code an abstraction layer, or use an intervening JavaScript framework like phonegap to abstract away such incompatibilities.

TBD: Show some examples of abstraction layer/ported apps?

Reference docs:

Chrome app API reference (chrome.*)

Mozilla Web API reference

Firefox OS APIs not supported in Chrome

There are a number of Open Web/Firefox OS APIs, which are not yet implemented in Chrome. These APIs are in their various stages of standardization, but they are all being considered and pushed forward for the W3C recommendation track.

Battery Status API

Provides information about the system's battery charge level and notify you as the battery level changes.

WebFM API

Provides access to the device's FM radio, allowing you to programmatically turn the radio on/off and switch between radio stations.

Vibration API

Provides access to the device's vibration hardware, which let software code provide physical feedback to the user by causing the device to shake.

Camera API

Allows applications to manage the device's camera, for example taking photographs, recording videos, and getting information about focus, zoom, white balance, flash, etc. It is a certified API so it can basically only be used by device vendor-supplied applications.

Proximity API

Allows applications to respond to proximity events, which are a handy way to know when a user is close to a device.

Time/Clock API

Allows applications to change  time/date of the system. It is a certified API so it can only be used by device vendor-supplied applications.

Ambient Light Sensor API

Allows applications to respond to any ambient light events, which are  handy way to make a web page or an application aware of any change in surrounding light intensity.

Device Orientation API

Allows applications to respond to changes in the device's physical orientation.

Screen Orientation API

Allows applications to detect and respond to changes in the orientation of the screen (i.e., portrait or landscape), including locking the orientation.

Web Activities

Defines a way for applications to delegate an activity to another (usually user-chosen) application, for example using the camera to take a picture, or using the dialer to initiate a phone call.

Chrome APIs not supported by Firefox OS

Chrome similarly has a set of APIs that are not supported by the Open web and therefore not implemented in Firefox OS. For now, lack of support in a platform just needs to be worked out in a different way.

app.window API

A concept  currently unavailable in Firefox: provides the ability to control window parameters, e.g., maximize, minimize, change window size.

app.runtime API

Another concept not currently available in Firefox: this is basically used to notify when the app has been restarted.

i18n API

An internationalization API that allows you to pull in and display different language strings for users in different locales.

serial API

Allows an application to read from  and write to a device connected to the serial port.

runtime API

API to retrieve the background page, return details about the manifest, and listen to and respond to events in the app or extension life cycle.

system.cpu, system.display, system.memory, and system.storage APIs

APIs to query system metadata.

tts API

Allows an application to play synthesized text-to-speech.

usb API

Allows an application to access and provide commands to connected USB devices.

Other differences

TBD

In summary

The takeaway from this article is to guide you accordingly, as you start writing your apps, and make sure you have a level of abstraction around APIs that are not standardized through the W3C. They may change, and your app will likely have to change as a result.

 With such a diverse new range of target devices appearing, it will be helpful for end devices to be able to read and write to serial and USB ports. This could enable a suite of new types of devices and functionality that we don’t really expect,otherwise. Think of Arduido, Raspberry Pi, etc.