Chrome just got Web Intents support in Dev and Canary builds (18 onwards). This is a huge milestone and I am very excited by this first step along the path of building a more connected web of apps.
A lot of developers have asked me how to get started as it seems some of the demos on http://demos.webintents.org don't register correctly. I have a good answer for that - in short: Chrome doesn't yet detect the intent tag, instead applications currently can only register their support for an action such as "share" via the Chrome apps manifest.
The longer version is a little more complex:
- Consensus over the introduction of a new tag in to the spec has not yet been reached.
- Working with members of the DAP in the intents task force, it is clear that discovery of applications and services shouldn't only take place by detecting a tag on a web page. What happens if the service you want to "Share" a video too is a TV connected to your local network? Or an external native application wants to be able to support a "Save" action. To enable this important use case the User Agent should be able to determine the services it presents to users, and this is why this is allowed in the specification (3rd paragraph).
Bringing this closer to home, because the discovery and presentation of an app's capabilities can be managed by the User Agent, and Chrome has the concept of extensions and installed apps we can quickly enable the intents feature by letting developers declare their support for actions in the manifest.
So what does the declaration in the Chrome apps/extension system look like? It is pretty easy, it is an entry into the manifest called "intents". It looks like:
{
"name": "Share to Gmail™",
"version": "0.0.0.2",
"icons" : {
"16" : "favicon.ico"
},
"intents" : {
"http://webintents.org/share" : {
"type" : ["text/uri-list"],
"title" : "Share to Gmail",
"path" : "/launch.html"
}
}
}
It is that simple. The intent section includes a dictionary of supported action (http://webintents.org/share) and in each action object there is an array of data types that the application or extension can handle, the friendly name to appear in the picker and a path to what should be opened when the user selects your app. The client-side code remains exactly the same as it would in a normal web app.
In the long term we want applications to be able to declare their capabilities and services directly through their html and this will be done with the Intent tag. However whilst the standardisation work continues we want to make sure that developers today can start building apps that can take advantage of the Web Intent system.
A lot more examples can be found on the Web Intents Github repository.
Expect a lot more posts about how to build applications that love each other with Web Intents.