Google Chrome Extensions: Extension API Design


Uploaded by GoogleDevelopers on 07.12.2009

Transcript:
Hi, I'm Raf. I'm a programmer working on the Google Chrome
extension system. I'm here to talk about the design of the APIs
that you'll use in creating your extension. One goal in the design of the extensions system
is that programming extensions should be just like programming web pages.
So as you'd expect, you'll be programming in JavaScript which runs inside web pages.
Many things your extension will want to do, you can accomplish with existing web APIs.
Want it to talk to a server? Use XmlHttpRequest.
Want it to persist some data? Use cookies, LocalStorage, or HTML5 Databases.
Want it to display a nicely designed options page?
Use HTML and Cascading Style Sheets. However, Google Chrome also exposes APIs that
only extension code can access. We've tried to make these APIs feel as much like web platform
APIs as possible. Let's start with an example:
This is code from a simple extension which displays a browser action icon and when the
user clicks on it, it opens up a web page which is packaged within the extension.
Already we see a few key aspects of the extension APIs.
First, you can identify all the extension calls because they exist in the "chrome" namespace.
"chrome" is a global object to which all extension APIs are bound.
The Google Chrome extensions APIs are only visible to extension code and are broken down
into modules. Here we are using the "browserAction", "tabs",
and "extension" modules. chrome.browserAction.onClicked is an event
which can register listeners who act on something interesting that happens -- in this case,
the user clicking the browserAction icon. Most modules expose events and they all have
the same form - which allows for the addition and removal of listeners.
Now, let's look at the call to chrome.extension.getUrl(). This is an example of a synchronous function
call -- meaning that it does it's thing immediately and returns a value to the calling code.
In this case, it's constructing a URL which the browser can use to navigate to a resource
which is within your extension. Some API calls are synchronous, but many are
asynchronous. Let's take a look at another example:
Here, we are asking Google Chrome to modify one of the user’s bookmarks by modifying
its title. This call is asynchronous -- meaning that
the code that makes the call will continue executing and the function you provide as
a callback will be run sometime later -- and which point your code will know that the
bookmark has been updated. The reason why this call is asynchronous has
to do with Google Chrome's multi-process architecture. Web pages and JavaScript run in processes
which are not only separate from each other, but also from the main browser process which
alone has the ability to do things like read & write to the local file system.
This is an important security and stability feature for Google Chrome.
If calls like this were synchronous, your extension would have to stop everything and
wait for the browser process to respond to the request, all the while the user may be
trying to interact with the UI of your extension which has become unresponsive.
Using asynchronous APIs is more challenging, but it's in the service of the best user experience
possible, and it won't take long to get the hang of it.
Just remember that it won't be uncommon to write code like this
rather than this There's one more interesting thing about this
example: There's a bug in it that the extensions system
is going to help us find. If you look at the documentation for this
call you can see that the id that chrome.bookmarks.update() takes as it's first argument is a string,
not an integer. When this call executes, the extension system will throw an exception pointing
out the error. The extensions API uses an implementation
of JSON schema which declares the name, type, number and position of its function arguments.
If you call it with the wrong types or wrong number of arguments, it'll complain.
Additionally, the extension documentation is generated from exactly the same JSON schema
that Google Chrome uses to create it's internal API.
So, for instance, if you are developing using the beta channel of Google Chrome, you can
be assured that the docs at http://code.google.com/chrome/extensions/beta are accurate.
In creating the initial release of the extensions we focused on creating a robust, secure and
easy to use system that included a small set of APIs that we felt would allow many useful
extensions to be made. It initially includes interacting with browser
windows, tabs & bookmarks, but we expect to be adding more soon.
Have fun working with the Google Chrome extensions and please let us know what we can do to make
your extensions better by giving us feedback at our discussion group.