Marketplace/getFeature

The Marketplace has been placed into maintenance mode. It is no longer under active development. You can read complete details here.

Overview

When we say "getFeature" we are generally talking about feature detection writ large. This involves two APIs: hasFeature and getFeature. In order to use either of these APIs, an app must be using the 'feature-detection' permission (which is specified in the app's manifest).

Both hasFeature and getFeature are similar in that they return information about the device. But they differ in that hasFeature simply returns a boolean if the feature exists, whereas getFeature returns a value about that feature; as such, they're intended for slightly different use -- when you need to know IF something exists vs THE EXTENT of something. Example: hasFeature("camera") vs getFeature("hardware.memory").

Version Compatibility

While it has been said that "getFeature" landed in 2.0, many people have not understood this discrepancy, and assumed that meant both getFeature and hasFeature landed. They did not; only getFeature did land. Therefore, complete feature detection is not possible in 2.0.

Another point of confusion is the wiki page on hasFeature speaks of values for the manifest namespace that can be used with hasFeature; but these were actually implemented on getFeature -- which makes sense if you know that hasFeature is not implemented in 2.0, but is incorrect according to the spec.

hasFeature does exist in 2.1, though it has the (recently fixed) bug where it returns undefined for manifest.* tests. There is no plan to backport support of hasFeature to 2.0.

Technical synopsis of hasFeature/getFeature

The hasFeature API is documented on the wiki, but it can be summarized: across all versions,

• getFeature works for hardware.memory (expected), but nothing else;
• hasFeature works for api.* (expected), and doesn't work for hardware.memory (expected).

... with the complicating caveat that hasFeature does not exist on 2.0 (even though getFeature does).

Implementation

The implementation of "getFeature" has been complicated by the intersection of a few factors:

1. we are not yet a real packaged app (we are still a packaged iframe)
2. Where's My Water and Firefox Hello have feature detection requirements, and they will ship on devices before the end of 2014

Reference materials from Product and UXD

• PRD
• PRD Extension

Where's My Water

It needs to use:

• asm.js - the manifest.precompile option was added to the app manifest in 1.4, but the permission was not added until 2.0.
• 512MB RAM - at least this amount of memory is needed to run.
• 80MB available storage to install or/update. (This is not a requirement to show up for the user.)

Firefox Hello

Needs new permissions for:

• mobileid
• moz-attention
• moz-audio-channel-ringer
• moz-audio-channel-telephony
• moz-firefox-accounts

These are available after OS version 2.0; mobileid will be used as the key for the entire set (meaning: we're only going to detect that one and, if present, assume the rest).

The marketplace that is shipping with 2.0 doesn't have permission ("feature-detection") to use hasFeature/getFeature, so we need to update the package regardless of the "real" vs "iframed" packaged app.

Development Roadmap

History

• Marketplace used to detect features using an "old method" (non-API based), across all platforms
  • this was unreliable (misdetection and didn't work due to permissions issues on FxOS) and was disabled
• Q2 2014: feature detection was removed as part of the Tarako project, because in testing we discovered that even those checks were negatively impacting performance (load time)
  • performance impact was tested on old hardware, desktop, and old FxOS versions
    • never on Android
• Q4 2014: WMW/Hello re-introduced the need for API-based feature detection (on FxOS)
  • API-based feature detection -- beyond WMW/Hello -- has not been performance tested

Initial release for FxOS (WMW/Hello, Q4 2014)

For getFeature itself:

1. add a buchet for 512MB RAM minimum
2. enable feature detection
3. update developer submission tools

For being able to notify the user of an available marketplace update:

1. how do we determine it?
2. while we aren't attempting to force install (or any other clickable action from the update notification) for this project, if there is a permission that needs to be requested for it, we should add that now so it's there when we need it later

Full release for FxOS (Q1/Q2 2015)

We will implement feature detection using hasFeature and getFeature APIs where possible; we will resort to manual checks where not possible. For devices that do not support those APIs -- whether they are on older versions of the Marketplace or Gaia -- we will simply apply a limited feature profile.

This means that any marketplace originally shipped on 2.1 or lower, or any marketplace running on a version less than 1.4 will be checked for feature compatibility in a very limited capacity.

Known Issues

getFeature

1. There is an existing issue with getFeature() in that it will test for the existence of the API, but this could be out of sync with the actual hardware.

Updating the Marketplace

1. We cannot update the marketplace app on 1.1 (962524)
2. In order to accommodate the largest group of devices that have Firefox Hello on it (and Where's My Water available to it), we want 2.0 users to update their shipped marketplace with our new one.
   1. Rather than specifically target 2.0, we want to just notify all users if there's an update.
      1. we can detect that there is an update available for our app already
      2. we CAN force install the update, no additional permissions necessary

The packaged iframe

There are a variety of options for implementing getFeature in the packaged iframe:

1. Iframe package does detection via getFeature in advance and postMessage()s it to the app. Problem: The old iframe package does not post the message, but we need to block on it before making the search API calls. How do we differentiate between an up-to-date package that is just taking some time to post the message and an old package that is never going to send the message? How long do we wait? Possible perf impact.
2. Iframe package does detection via getFeature in advance and passes it via the querystring. Problem: getFeature is asynchronous, blocking on it might also have a perf impact.
3. Iframe package passes via the querystring that it has getFeature (?getfeature=true) and waits for messages. Then the iframe knows it can postMessage to ask for features. Problem: This is getting complicated.

We are going to attempt blocking on the iframe creation, performance TBD.

QA time needed vs timeline

In addition to the technical issues surrounding the iframe, there is the timeline consideration. QAing getFeature is involved and will take time:

1. If it takes so much time to QA that we cannot get this done in time for Where's My Water and Firefox Hello, we must consider implementing less of getFeature and focusing on only the parts we need for those two apps. This is not ideal.
2. If it takes so much time to QA that we CAN get this done in time, but we could also be a real packaged app by then, there is less point to pursuing the packaged iframe.

Bugs

Tracking bug: 983880.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Future product feature phases

1. add full API-based feature detection for FxOS; if hasFeature/getFeature APIs do not/appear to not exist, we will send a limited profile string that assumes little interoperability rather than do manual feature detection
2. extend force install on marketplace (from Caitlin Galimidi)
3. do a fota update to marketplace with the system update 1.1 open c zte (arog / clee / bialer) (from Caitlin Galimidi)