Matching a WRT widget requirements to current device software configuration

[paulkeogh]

Hi,

Is there any way (programatically or algorithmically) that I can determine if the an instance of WRT installed on a device contains all the Javascript libraries needed to execute a specific widget ?

The reason I ask is twofold;

Firstly, it would be optimal to only package a widget archive with the JS libraries needed for a particular platform (lets assume dynamic packaging).

Secondly, it would allow an active server platform (as opposed to a web accessible file server), to only expose widgets that the device is capable of executing. This is typically a gallery view, prior to any widget download.

Thanks,

[jappit]

Hi,

it totally depends on the way you want to allow users to browse/download your widgets.
As an example: you could build a "gallery" widget, compatible with WRT 1.0, so able to run on all WRT-compatible devices. Through that, It'll be easy to identify which WRT version is shipped (e.g.: checking if 'device' object exist) and so to show to him only supported content.

Hope this matches your question

Pit

[paulkeogh]

Ummm not really. Here's the use case.

I write a widget that uses WRT 1.1 functions. I publish it onto a public gallery that is accessed by devices that use both WRT 1.0 and 1.1.

Who or what tells the WRT 1.0 device that it cannot run my widget ?

Does the user see a runtime exception when the 1.1 JS functions/libraries cannot be found ? If so, this is a poor user experience.

Can a server help here ? Is there a way that it can "know" that the device (maybe from the User-Agent value queried against WURFL) supports WRT 1.0 and hence cannot run a 1.1 widget, and handle the exception in a user friendly manner ?

[jappit]

So, the user will access the widgets gallery via its device's browser, right?

If this is your case, then using the User-Agent would maybe be the only option, but could start to be quite a mess to manage when (if?) devices with WRT 1.0 will be upgraded to 1.1 with firmware updates.

Still looking for a better solution...

Pit

[paulkeogh]

Yes, widget access via the browser.

Agreed that the User-Agent header solution won't work 100% of the time, so it seems to be that what is needed is a Widget Agent on the client, which launches or embeds the browser to render the widget, but which is also capable of other things - primarily being able to figure out if the installed software on the device is capable of rendering the widget.

This is why I dont think web runtime is the silver bullet for cross device compatiblity - its not smart enough to cater for all the use cases out there.