mozilla
Your Search Results

    Porting Chrome apps to Open Web Apps

    This article is in need of a technical review.

    This article is in need of an editorial review.

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

    Overall file structure

    Google Chrome apps are very similar to Open Web Apps/Firefox OS apps — they are built using web technologies, and their manifest file format is very similar. But there are some differences in terms of syntax, file structures, and available APIs.

    • Open web apps let you use any file structure you want — they are just web apps, so use what you are used to.
    • Chrome apps are pretty flexible in structure as well, although there are certain things you need to know. Chrome apps also have the concept of background pages, HTML/JavaScript that runs in a background process and handles app functionality behind the scenes.

    The manifest file

    Both Chrome apps and Open Web 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 the differences are.

    For our first example we'll use the Hello world example 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 an open web/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"]
             }
          }
       }

    Open web 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:

    API support differences

    There are some differences in APIs supported across Chrome apps and open web apps; when porting an app over you will need to do an inventory of the platform-specific APIs you are using, write equivalent functionality for the target platform, and perhaps even create a level of abstraction around them. The naming & capabilities of the APIs vary across the platforms.

    In this section we will look at the different-but-equivalent device APIs supported across both platforms, where you can find further documentation on each, and lastly which APIs have no commonality or equivalents across both platforms (Firefox or Chrome).

    Note: Standard web APIs will work on both platforms.

    WebAPI equivalents across platforms

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

    API equivalents across Chrome apps and open web apps
    API functionality Open Web app API Chrome app API
    Alarms alarm Chrome alarms API
    Audio getUserMedia (also handles video) audio API, also supports getUserMedia
    Bluetooth Web Bluetooth (documentation coming very soon) bluetooth API
    Device storage Device Storage API fileSystem API, mediaGalleries API
    Persisting identity navigator.id API (used in Persona) identity API
    Idle notification Idle API Chrome idle API
    Location data Geolocation API location API (Chrome also supports the Geolocation API, but that is not compatible with event pages)
    Notifications Web Notifications notifications API, events API
    API Permissions Permissions API Chrome permissions API
    Push notifications Simple Push API pushMessaging API (messages sent through Google cloud messaging)
    TCP sockets TCP Socket API socket API (allows UDP connection)
    Power management Power Management API power API
    Context menus  contextmenus contextMenus

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

    As a developer wishing to port apps between Chrome and open web, the difficulty is converting functionality between equivalent but incompatible APIs, where the APIs used deviate from web standard APIs. For the majority, 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

    Open web/Firefox OS APIs not supported in Chrome

    There are a number of open web/Firefox OS APIs not yet implemented in Chrome. These APIs are in various stages of standardization, but they are all being considered and pushed forward for the W3C recommendation track. For now, lack of support in a platform just needs to be worked around in a different way.

    Battery Status API
    Provides information about the system's battery charge level and lets you be notified by events that are sent when 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 lets 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 the system time/date. It is a certified API so it can basically only be used by device vendor-supplied applications.
    Ambient Light Sensor API
    Allows applications to respond to ambient light events, which are a 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/open web platform

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

    app.window API
    A concept not currently available 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 for and respond to events in the app or extension lifecycle.
    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 experiment/deploy as you write 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.

    There are Chrome APIs that it would be good to see standardized, especially internationalization, serial, and usb. 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 traditionally expect. Think of Arduido, Raspberry Pi, etc.

    Document Tags and Contributors

    Contributors to this page: kscarfone, JuliaM, markg, chrisdavidmills
    Last updated by: JuliaM,