分类： 系统运维
2009-04-23 12:11:13
Essentially, a widget is a local HTML/CSS/JavaScript web application. A mobile phone user downloads a widget once, and from that moment on he has a web application stored locally on his mobile phone.
Although currently widgets are mostly used for relatively limited functions such as clocks, RSS readers, or Twitter or Flickr clients, as well as for games, there’s no theoretical reason why they couldn’t contain a complete, complicated, JavaScript-heavy web application; for instance a mobile-optimised spreadsheet application.
The beauty of the widget model is that, even if this spreadsheet application needs 200K of custom JavaScript plus a few libraries, the end user has to download these scripts only once instead of every time he starts up the app, as in the traditional web application model. After the initial download the entire application is installed locally and can be fired up from the local files.
Many web applications will want to display fresh data, and therefore most widgets will fire an Ajax request as soon as they’re started up. For that they need a network connection and some data traffic.
Nonetheless, the fact that the application itself doesn’t have to be downloaded every time the user starts it up diminishes the network traffic by a lot; and that’s important on mobile phones with their unreliable and sometimes crawlingly slow connections.
In itself the widget concept is no different from the countless application models currently being set up for the iPhone, Android, Blackberry, Windows Mobile, and many more systems. These, too, will put the core files on your phone and use the network connection only for data traffic.
All proprietary systems, however, require programmers to train themselves in new skills and techniques that are not interoperable. Widgets, on the other hand, use the open web technologies that hundreds of thousands of developers all over the world are already familiar with.
Better still, widgets will eventually conform to the “write once, run anywhere” principle; though right now that’s not yet the case.
Personally I firmly believe that widgets are the future of the mobile web. They are easy to create, they’re based on open standards, they save the end user quite a bit of network traffic, and many people around the world already know how to create them.
Widgets are nothing more than zipped websites. You create an HTML file, add as many CSS, JavaScript and image files as you need, zip the lot, change the extension to .wgt and it works. Just like that.
Well, almost just like that. The rest of this entry explains the “almost.”
Widgets are specified by the . Currently this spec is still a work in (slow) progress, as so many W3C specifications are, but the outline is pretty clear.
The widget environment I’m working with has been created by Vodafone in close cooperation with Opera. Because they wanted to work according to a standard but the specification was (and is) still in draft stage, at a certain point they decided to freeze the then-current version and implement it. Subsequently it was slightly modified to solve some urgent problems.
All technical details I’m going to give come from this Opera/Vodafone implementation, which does not quite match the current W3C draft. Everything works, though — I tested it personally.
(Once the specification stabilises Opera and Vodafone plan to implement it, and that will probably mean already created widgets will experience minor breakage. We’re planning to release a library that works around these issues for you.)
Unfortunately there’s a zipping issue on Mac. I’m not sure of the details, but if you just use the default zip on Mac, your widget will not work.
In order to solve this problem and several others, Vodafone has released a . Although the site doesn’t state so clearly, it’s in beta right now and a final release is expected later this year. You should take a look at it if you’re serious about creating widgets.
It contains a special version of the Vodafone Widget Manager that allows you to debug your widgets through a Bluetooth connection with Opera Dragonfly. The procedure is sometimes complicated; see Debugging Mobile Widgets with Opera Dragonfly for the technical details.
A widget requires a config.xml file that specifies some configuration information. Here’s a sample config file:
Test widget pix/myIcon.gif 200 200 quirksmode.org
Most of this stuff is pretty simple.
These are start values; if you want you can later on change the widget size by the normal resizeTo() and resizeBy() methods. The widget cannot in any case become larger than the screen.
The
The id attribute is required if you want to be able to update your widget. I’ll get back to the updating process in a later post; for now it’s sufficient to say that an id must be a unique URI.
As to the
(Unfortunately Opera unexpectedly changed the security policy in Opera 10 Desktop. You need the syntax shown above for Opera 9 and the Widget Manager, but a different one for Opera 10.)
Widgets have a docked state that’s pretty similar to minimised applications on your desktop computer, in that scripts may continue to run in a docked widget; for instance to silently update an RSS reader with new data.
However, you have to explicitly allow scripts to continue running by adding the dockable="true" attribute to the
While a widget is docked, it is still visible to the user as an icon, although the viewport now becomes about 60x60 pixels (and remains so until the user undocks the widget).
If you wish you can present the user with a special interface while the widget is docked; for instance a special icon. In order to do that you need to set a widgetmodechange event handler that checks if the current widget.widgetMode equals docked and if so hides the normal interface and shows a special, 60x60 optimised one.
widget object and external linksIn a widget environment an extra widget object is added to the JavaScript global object to contain these useful widget functionalities such as the widgetmodechange event and the widgetMode property. You can find a complete overview in the widget object compatibility table.
Finally, normal hyperlinks open not in the widget itself, but in the default S60 WebKit browser (on mobile phones) or in the regular Opera (on desktop). I do not understand why this should be the case. A widget environment is capable of handling HTTP requests and interpreting HTML, CSS, and JavaScript, after all.
Although I firmly believe support for W3C widgets will become better and better as time progresses, right now it’s still in its infancy.
Opera is a major defender of the widget concept, so it comes as no surprise that Opera Desktop supports it. If you’ve created a .wgt file on your computer, double-clicking it starts up Opera, which shows the widget in a special widget mode. That’s useful for testing.
On mobile phones the situation is murkier. The Vodafone Widget Manager, that runs only on Symbian S60 phones (basically Nokia), supports W3C widgets, but few other applications or phones do.
The Vodafone Widget Manager (surprise!) has been created by Vodafone in order to manage widgets. It contains a system for installing them, as well as a complete Opera Mobile runtime engine that is used to actually interpret the HTML, CSS, and JavaScript.
There are some slight differences between a regular Opera Mobile and the Opera Widget Runtime. In my tables this special Opera is noted as “Opera VF WM” (for Vodafone Widget Manager).
Opera is a pretty good browser, so you can be pretty certain that your widgets will run pretty well as long as you use proper HTML, CSS, and JavaScript. On the other hand, this is a new, untested technology, so nasty surprises will definitely turn up at the worst possible moment in your development cycle.
Opera announced just now that it has built a similar system for T-Mobile. Because all the screenshots feature Windows Mobile interfaces, we kind of assume it runs (only?) on that OS.
Confusingly, when I search for “widgets” on the T-Mobile site I get on the German site, whilt the and sites each have one unrelated match.
Interestingly, this widget manager seems to contain a device API. A device API is a JavaScript interface meant for accessing phone functionality such as the camera, the calendar, the contact list, and so on. It’s obvious that device APIs are going to be extremely important for creating widgets that tie in more closely with mobile phones.
As far as I can see now the Opera/T-Mobile device API is proprietary (and possibly restricted to Windows Mobile). That’s not entirely unexpected; currently the is supposed to formulate a standard for device APIs, but it’s not ready yet and unreadable for non-Java programmers anyway.
Despite this touch of proprietariness I’m very happy with the Opera/T-Mobile initiative. The more companies support widgets, the sooner they’ll go mainstream.
I think Vodafone widgets can be ported to , the native Nokia S60 widget environment. These, too, are HTML/CSS/JavaScript widgets, although they run in S60 WebKit and need an info.plist XML file instead of a config.xml.
As far as I can see, making your widget Nokia-compatible entails nothing more than adding this info.plist to it, and making sure your widget runs well in S60 WebKit. I haven’t tried this for myself, though, so there may be unforeseen circumstances that complicate the matter.
By the way, the “XML” in the plist is weird. Somebody tried (and failed) to port name/value pairs to XML. The schema is based on Apple’s Dashboard Widgets, so if you know those you’ve got the advantage over me here.
Maybe the Palm Pre, which has made Web technologies the very cornerstone of its webOS operating system, will support them, but there’s so little data available that I can’t really tell, except that it would be a logical extension of their plans. The Palm Pre uses a WebKit branch as default browser, by the way.
Other than that I’m not sure where we can easily deploy our widgets right now. I do advise you, however, to test your widgets in a WebKit (Safari or Chrome being the most obvious candidates) in addition to Opera. It will save you some hassle later on.
Ideally, in a few years, I, using an Android, would be able to transfer a widget to a friend’s S60 Nokia and another friend’s Windows Mobile HTC via Bluetooth (or whatever) and They’d Just Work without me or them having to worry about compatibility.
Wouldn’t that be wonderful? Wouldn’t that be absolutely astoundingly interoperable?
Besides, widgets will also work on desktop computers. As I said, Opera already supports them, and it’s only logical that other browsers will eventually do so, too.
Still, this brave new world won’t give birth to itself. We, as web developers embracing open standards, have our work cut out for us. We have to evangelise standard-compliant W3C Widgets. If you see me speak somewhere during this year, chances are I’ll pontificate on exactly that subject.
However, we should be careful to stress that we want widgets not instead of, but in addition to the proprietary systems mobile phone vendors are setting up right now.
These systems have their place, and they might conceivably be a better environment for certain types of applications. Besides, everybody is allowed to innovate and try out new platforms and ideas, as long as they also support the standard.
It will not be easy. Neither will it be quick. But open technologies, and especially open web technologies, are in an upswing throughout the world, while closed systems will gain a hard core of enthousiastic developers, but not the tidal-wave effect their creators so desperately want.
If I were a Marxist I’d say our victory is unavoidable, but since I’m not quite that orthodox I’ll say that it’s likely we’ll succeed.
If you’re interested in widget technology you might consider coming to the 2 May Widget Dev Camp in Pakhuis De Zwijger in Amsterdam. I’ll be around in the afternoon to maybe speak and certainly give some technical advice to help you create your own widgets.