In the past weeks I've done some experience with Opera mobile widgets, and would like to share first some tips and guidelines about porting a widget, originally developed for the Vodafone/Opera widget runtime, to the S60 Web Runtime platform. Both platforms use Web standards such as HTML, CSS and JavaScript, and the greatest differences are brought by the runtimes themselves, as will be explained by the following points.

Differences

Widgets' structure is similar for both runtimes. A widget must be composed of a single HTML file, and could allow multiple JS, CSS and image files. In both cases the widget is packed by using a standard ZIP compression, but using different file extensions: WGZ for Web Runtime, and WGT for Opera widgets.

The only important structure difference is represented by the configuration file: config.xml for Opera widgets, Info.plist for Web runtime. Specifications for both files can be found here:

• Info.plist specifications
• config.xml specifications

Similarities

Luckily enough, some useful objects and methods work on both environments, allowing for faster and safer widget porting. Some examples are:

• widget setPreferenceForKey() and preferenceForKey() methods
• widget openURL() method

Not all methods of the widgets objects are supported by both runtimes. For full details:

• Web Runtime widget object
• Opera widget object API

1. Managing the user interaction

Both widget runtimes allow to choose between cursor navigation (so, with the classical mouse cursor) or tabbed navigation. What changes is the way to declare which mode the widget should use. On the Opera runtime, the tabbed navigation mode must be declared in the configuration file, by using the <nocursor /> tag, while on Web Runtime this can be easily handled from JavaScript, by using the setNavigationEnabled() or setNavigationType() methods.

2. Tabbed navigation differences

Tabbed navigation works similarly in both cases, allowing users to move focus by using the 4-way navigation pad. Anyway, there's an important difference in the way the Opera runtime moves focus: apart from standard links (<a> tags) and elements with onclick handlers, the Opera runtime also focuses standard images (<img> tags) even if they have no onclick handlers defined. This could bring to weird behaviors if not appropriately taken into account, and could confuse users in their interaction

3. Screen size

Opera widgets are currently constrained to a subportion of the available display resolution, by leaving the upper part of the screen for the widget information (e.g.: title) and the lower part for standard softkeys. The Web Runtime allows for full-screen widgets, so layouts should be appropriately resized to benefit from this extra space.

4. CSS opacity

Web Runtime does not currently support alpha transparency for HTML elements, while the Opera widget does. When porting, the opacity should be so appropriately managed, by choosing a suitable alternative effect, or by removing it. A possible way to implement opacity in Web Runtime is represented by the use of PNG24 images with alpha transparency, well supported by the Web Runtime platform.

5. GIF support

A known issue with first Web Runtime versions was the lack of support for animated GIF images, so you should take this into account if your widget uses them. In this case, some JavaScript-based workarounds are available on Forum Nokia Wiki:

• How to create animated images in Web Runtime widgets

6. Move the icon

The Opera runtime allows to use any paths for the widget's icon, just specifying it in the configuration file. When porting to Web runtime, the icon has instead to be moved to the predefined path, that is: '<widget_root>/icon.png', without the need to specify this in any configuration file.

7. Display rotations

Opera runtime does not allow to block the display orientation to landscape or portrait. Web Runtime allows to do this, by using the JavaScript methods:

• widget.setDisplayLandscape() to force landscape orietation
• widget.setDisplayPortrait() to force portrait mode

So, you could use this functionality to let your widget display in only one orientation, if your widget needs that.

8. Home screen

One of the cool features of WRT widgets is, on latest S60 5th edition devices, the possibility to have your widget on the home screen of the device, so always visible to the user.

On the other side, Opera widgets allow for a "docked" version of the widget, so allowing to display any dynamic information instead of its static icon.

Home screen and docked widget concepts are really similar, since they actually allow to display smaller versions of the widget. When porting, the resolution should be taken into account: size available for docked widgets is usually smaller than the one available for home screen widgets. So, more space and more content :)

9. Customizable softkeys

One big plus of Web Runtime widgets, when compared to Opera ones, is the possibility to customize the softkeys, allowing to add custom items and functionalities to both the left and right softkey menus. 

For full details, check out the JavaScript menu object reference.

10. Network access

Opera mobile widgets need to declare the remote hosts they want to connect to, as specified by the Opera Widgets security model. When porting to Web Runtime, this step is no more necessary: Web Runtime widgets can connect to any host, without the need to declare them in a configuration file.