The Google Chrome team recently released Web Intents, which is an API for enabling web applications to integrate with third party services without utilizing custom APIs for each target service. Web Intents is the web equivalent of Android intents, which uses a late runtime binding mechanism that enables loose coupling between applications and services. Web Intents puts the user in the driver seat by providing user friendly mechanisms to control service integrations and in the process simplifying the developer's job.
In the Intents system, services are explicitly registered against intents, which are basically generic actions such as edit, view, share etc with relevant data parameters that accompany the action. At run time, the user is prompted to make a choice among the registered services for the action. The chosen application is then delegated the responsibility of executing the action using the data passed by the user. An equivalent usecase scenario in the web world is photo sharing capability in a custom web application. Instead of writing custom API to integrate with various photo sharing services such as Flickr or Picasa the custom web application can leverage invocation of web intents which is a few lines of code that in turn will utilize the browser's functionality, to first enable services such as Flickr and Picasa to register as handlers for the intent to share and then prompt the user to make a choice among the handlers when the intent to share is invoked. At this point no browser has implemented the functionality necessary for supporting this feature but the Web Intents project has shared a Javascript Shim that will support execution of Web Intent applications in IE 8 and 9, FireFox 3 and upwards, Chrome 5 and upwards and Safari browsers.
James Hawkins, Software Engineer at Google, has provided a detailed javascript example on the Chromium blog to illustrate the API functionality.
Consider an online photo storage site run by a cash-strapped startup: the developers don’t have the resources to add image editing abilities to their app, but they feel the site won’t be a hit without it. The Web Intent system will make it easy for them to offer this with little effort.
var intent = new Intent(Intent.EDIT, ‘image/png’, getImageDataURI());
window.navigator.startActivity(intent, loadEditedImage);
// This callback will be called when the service replies with the edited
// image data.
function loadEditedImage(data) {
var image = document.getElementById(‘image’);
setImageData(image, data);
}
When the user visits her favorite memegen service, the site will request registration to handle the EDIT intent for files of type ‘image/*’ using the following declaration:
<intent
action=”http://webintents.org/edit”
type=”image/*”
/>
When the user initiates the EDIT action, this service is presented to the user, along with other registered image editors. Once the user selects Meme Generator, the referenced site is opened in a new context and is able to load the image data from the intent payload:
var intent = window.intent;
memeImg.src = intent.data;
memegenForm.onsubmit = function() {
// Transform the image - meme it.
addMemeTaglines(memeImg, memeTopText, memeBottomText);
// Send the generated meme back to the client.
intent.postResult(getImageData(memeImg));
};
Once postResult() is called, the Meme Generator context is closed and the output data is sent back to the client via the callback passed to startActivity().
Discover: The discover intent is designed to let developers query the API's and services that might live on external services.
Share: The share intent is designed to give applications the ability to offer a simple mechanism for sharing data from the current page.An action that can handle share could be anything that the user has installed, including and not limited to Social Networks and Email services.The "Share" protocol is intended to be a lightweight sharing facility.
Edit: The edit intent is designed to give applications the ability to offer a simple mechanism for to edit data from the current page. An action that can handle edit could be anything that the user has installed, including and not limited to image manipulation tools and text editors.The "Edit" protocol is intended to be a lightweight edit facility.
View: The view intent is designed to give applications the ability to offer a simple mechanism to view data in their application.An action that can handle view could be anything that the user has installed, including and not limited to specialist image tools or audio players.The "View" protocol is intended to be a lightweight view facility.
Pick: The pick intent is designed to give services the ability to allow their users pick files from their service for use in a client application.An action that can handle pick could be anything that the user has installed, including and not limited to an image gallery such as Picasa or Flickr. A client application might be an email client such as Gmail or Hotmail.The "Pick" protocol is intended to be a lightweight cloud file picker solution facility.
Google is working with Mozilla to unify their approachs to this problem. Mozilla has also been interested in this space and introduced Web Activities earlier last month through their launch of the Open Web App Addon 0.3 for Firefox. The Open Web App EcoSystem consists of the application's machine readable manifest, the user's app repository, a dashboard for launching apps and the supported interactions. The manifest is similar to an intent in the Web Intents system.
At this point it is not very clear on how successful user adoption will be but it seems promising for application integrators and service providers, what do you think?