Usually, when a mobile application needs an update, it is necessary to release a new version, and to deploy this new version on all the devices where the old version was installed. This includes scenarios as bug fixing, releases of new features, and also the smallest code changes.

While many mobile users know how to perform an update of an application, Web Runtime widgets offer an attractive alternative approach that could both help the less experienced users, and bring some important benefits to Web Runtime itself.

Summarizing this approach in few words, a Web Runtime widget can download new code with simple HTTP requests, and use it to replace existing code (think about bug fixing, or code changes more in general) or to add new features to itself, without requiring any extra efforts from the user.

So, the update process become much smoother than with the classical application updates. What this means is that updates become transparent to the user, since all he needs to do is to allow its widget to connect to network, to retrieve the new code.

How it works is detailed is this Forum Nokia Wiki article:

How to update WRT widgets without installing a new version

To summarize the limits and benefits of this approach:

Limits

Current Web Runtime JavaScript APIs allow widgets to locally save textual data, with the preferenceForKey() and setPreferenceForKey() functions.

So, the new JavaScript code can be easily saved and used for all the subsequent usage sessions of the widget, without the need to download it each time. But all the binary data, for example images, simply cannot.

So, when some binary data needs to be added or updated, this approach doesn't work, and the only way is to deploy a whole new version of the widget, so updating in the classical way.

Advantages

One major problem with Web Runtime widgets is that, when a new version is installed over an older one, all the data saved from the previous version gets lost. So, the new version of the widget cannot use the data saved by its previous version.

With the approach presented here this does not happen, since the widget isn't "actually" updated.

Repeating what already told, the greatest advantage of this approach is surely the better and smoother user-experience, since updates (with the limits already mentioned) become simple as doing network requests.

Security considerations

One could think about this as a major security hole for Web Runtime widgets. While it is true that a malicious developer could inject evil code in his own widgets, this is equally true with the other mobile technologies, even if with different approaches than the one described here.

Also, and most important, the Web Runtime sandbox and security measures guarantee that all the operations dealing with sensitive data or with potentially costing functionalities (e.g.: network requests, sms sending) are prompted to the user for its explicit permission.

Developing Widgets for Web Runtime is absolutely easy and fun, specially if you come from Web development.

While there are a lot of libraries and components that can be easily adapted and used within WRT Widgets, there are still not many components specifically tought and designed for WRT itself.

So, here are my first Web Runtime components: the WRT JavaScript Battery and Network Signal components, supporting both WRT 1.0 and 1.1.

You can view and download the full implementation of both components from Forum Nokia Wiki:

• Battery JavaScript component for WRT 1.0 and 1.1
• Web Runtime Network Signal JavaScript component

Feedbacks are welcome! :)