Web Intents FAQ

Table of Contents

Questions

Why not just use navigator.registerProtocolHandler?

registerProtocolHandler is designed to handle cases where there is a specific type of application that needs to be launched, commonly via an anchor or form, for instance "mailto://". When a user launches a link with mailto defined it will open the registered native application or web application.

We don't think this goes quite far enough, the protocol handlers have no concept of what data will be presented to the launched application; what happens when the opened application can't handle the data? how do you send an image to an app? There is no way to communicate data back to the calling application. Web Intents solves both of these problems.

Web Intents uses a filter mechanism to let applications register the commands that they wish to handle and also the data-types that they can support.

Why not just use navigator.registerContentHandler?

The answer is very similar to the problems that navigator.registerProtocolHandler suffers from. It's primary usecase is for registering the browser as a handler for a type of file data, it doesn't provide context as to the action's it can perform on those files.

Why not just improve both navigator.registerContentHandler and navigator.registerProtocolHandler?
Why do we need a new tag? And why can't you use create an new registerIntentHandler() API
  • We can easily index the intentions of services and provide a list of possible apps for the users to use;
  • It is declarative;
  • It can be validated;
  • Less developer API surface area;
  • Copy and Pastability. It is very easy for developers to start handling intents without any code
Why not simply use a manifest file to register intents?
  • It is another file to manage and deploy - our experience with AppCache and the deployment issues irk us.
    • It hasn't got the copy and paste-ability that a plain tag has.
    • It is another request for the UA to make:
      • Management issues: if the manifest 404's do we uninstall intents, if the manifest changes do we uninstall/install etc.
      • Increased latency and load on the server
  • Syntax, should it be text like AppCache? should it be XML? should it be JSON?
    • We would also have to spec out the format of the file and the exact parsing semantics
    • It is another dialect for developers to learn - The chrome manifest are simple, but we have had to build tools (appmator.appspot.com) to help developers because it was too much to grok the spec.
    • Add a new rel type to the html spec.
  • Other app manifests formats - there isn't consensus about the manifest formats for apps and this would lead us to not have one solid place to put it, and even then it might take longer to get this standardised.
Why is there no inline-in-page disposition?

We want to provide a picker and application context to the user that is not spoofable by a malicious page. An in-page in-line solution would look and feel very similar to an iframe and thus could be spoofable. It would be nearly impossible to provide an interface that could not be spoofed by a site.

Why is there no background disposition?

The user experience of having services that are invisible adds greater complexity to the user-agent and the user experience.

How well does Web Intents work with offline apps?

Very well. Web Intents is designed to be an entirely clientside discovery and communication channel.

The native implementation requires no 3rd party scripts or hosting. It is built in as a function of the User Agent.

The Javascript shim is hosted on webintents.org and is built to work with AppCache, so as long as you have a browser that supports AppCache then Web Intents will work offline.

Why can I only transfer 5MB of data?

This is an artifact of localStorage limits in Chrome, it only affects the use of the Javascript shim, not the native implementation.

Which browsers will support it?

We are working with browser vendors to build Web Intents natively in to their browsers. In the meantime, we have an API compatible Javascript Shim with support for IE8, IE9, Opera, Safari, Firefox 3+ and Chrome 3+.

Why is Action a URL?

The action in the intent tag is a URL to facilitate the following cases:

  • Namespacing;
  • Versioning;
  • Documentation

Throughout the Android intent eco-system you see regular use of com.domain.intentname for custom intents. Looking at Android (not the external apps), every intent is already in a namespace, the documentation suggests that everyone prefix it with their package name, therefore "android.intent.action.SEND" is different "com.example.intent.SEND". Given that they are namespaced to a physical location on an Android device (the package) translating this to the web, is through URL's.

What are Type strings going to be? How will they be matched?

Type strings are a filter used by the User agent to resolve the list of services that are known to be able to handle a particular type of data. For example, there is no point in listing a service that can only edit images at the start of an activity to edit audio.

Type strings are based on a MIME-type style syntax and can be resolved either via a full string match or via a simple wildcard system.

Wildcard types can be specified both in the intent tag and at the time of "startActivity".

  • Registering at the intent level allows an app to specify a selection of datatypes that it can support. Applications can choose to handle a very specific type: image/png; a range of types: image/* - every image, or any type of data "*"
  • Client apps can invoke an intent by saying the type of data the expect to send to the app, or recieve from the app. The app can support a vvery specific type: image/png; a range of types: image/* - every image, or any type of data "*"
Intent type resolution matrix
<intent>
text/uri-list image/jpg image/png image/* *
startActivity text/uri-list Yes Yes
image/jpg Yes Yes Yes
image/png Yes Yes Yes
image/* Yes Yes Yes Yes
* Yes Yes Yes Yes Yes