You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Ross Gardler <rg...@opendirective.com> on 2012/01/06 00:42:48 UTC
Wookie widgets as standalone widgets
It is possible to retrieve a *.wgt file from wookie for any of the
hosted widgets. Are there any caveats with respect to developing
widgets that are intended to be hosted both in Wookie and in other
environments?
Ross
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Wookie widgets as standalone widgets
Posted by Ross Gardler <rg...@opendirective.com>.
Thanks for your reply Scott. It's really useful so I've moved it to
our docs with some minor changes:
http://incubator.apache.org/wookie/docs/widgets.html
Ross
On 6 January 2012 08:34, Scott Wilson <sc...@gmail.com> wrote:
>
> On 5 Jan 2012, at 23:42, Ross Gardler wrote:
>
>> It is possible to retrieve a *.wgt file from wookie for any of the
>> hosted widgets.
>
> Yes - the Flatpack API is one way to do this for an instance, but we can also expose the download location via the usual /widgets API call. I don't think it does this at the moment, but we do store the original widget location so can retrieve it.
>
>> Are there any caveats with respect to developing
>> widgets that are intended to be hosted both in Wookie and in other
>> environments?
>
> The main ones are to not use any Wookie-specific features or internal calls. The syntax analyzer outputs warnings about this when you deploy the widget, so its worth paying attention to the log output to see if there is anything that needs fixing.
>
> Personally I test widgets by opening the .wgt using Opera Mobile, and by putting it through PhoneGap Build and opening the generated application in the Android Emulator that comes with the Android SDK for Eclipse.
>
> There are quite a few qotchas generally, mostly around things like differences in HTML5 support across different environments. E.g. the Android browser has poor Canvas support, Opera Widgets doesn't handle referenced audio files, etc. I think the only realistic way to deal with this is to do a lot of testing, and where possible check for feature availability in scripts before making calls.
>
> In the widgets I've developed recently, I've taken the approach of:
>
> 1/ develop the widget for in-browser use only, and test in a range of browsers including the Android browser, IOS Safari, and Opera Mobile
> 2/ test for existence of window.widget and if available enable widget features like preferences and metadata
> 3/ add features needed in config.xml, but make them optional, and test for availability in scripts before enabling them in the widget UI
> 4/ create .wgt package
> 5/ upload to PhoneGap build to create mobile apps
>
> http://labs.cetis.ac.uk/monstermath/
> http://labs.cetis.ac.uk/oblique/
> http://labs.cetis.ac.uk/butterfly/ <-- same as the Wookie one
>
> Its not exactly foolproof and automatic, and there are still problems, but if I was being a bit more "serious" about widget development I could use this basic approach to get widgets working correctly across most platforms.
>
>>
>> Ross
>>
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective http://opendirective.com
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com
Re: Wookie widgets as standalone widgets
Posted by Scott Wilson <sc...@gmail.com>.
On 5 Jan 2012, at 23:42, Ross Gardler wrote:
> It is possible to retrieve a *.wgt file from wookie for any of the
> hosted widgets.
Yes - the Flatpack API is one way to do this for an instance, but we can also expose the download location via the usual /widgets API call. I don't think it does this at the moment, but we do store the original widget location so can retrieve it.
> Are there any caveats with respect to developing
> widgets that are intended to be hosted both in Wookie and in other
> environments?
The main ones are to not use any Wookie-specific features or internal calls. The syntax analyzer outputs warnings about this when you deploy the widget, so its worth paying attention to the log output to see if there is anything that needs fixing.
Personally I test widgets by opening the .wgt using Opera Mobile, and by putting it through PhoneGap Build and opening the generated application in the Android Emulator that comes with the Android SDK for Eclipse.
There are quite a few qotchas generally, mostly around things like differences in HTML5 support across different environments. E.g. the Android browser has poor Canvas support, Opera Widgets doesn't handle referenced audio files, etc. I think the only realistic way to deal with this is to do a lot of testing, and where possible check for feature availability in scripts before making calls.
In the widgets I've developed recently, I've taken the approach of:
1/ develop the widget for in-browser use only, and test in a range of browsers including the Android browser, IOS Safari, and Opera Mobile
2/ test for existence of window.widget and if available enable widget features like preferences and metadata
3/ add features needed in config.xml, but make them optional, and test for availability in scripts before enabling them in the widget UI
4/ create .wgt package
5/ upload to PhoneGap build to create mobile apps
http://labs.cetis.ac.uk/monstermath/
http://labs.cetis.ac.uk/oblique/
http://labs.cetis.ac.uk/butterfly/ <-- same as the Wookie one
Its not exactly foolproof and automatic, and there are still problems, but if I was being a bit more "serious" about widget development I could use this basic approach to get widgets working correctly across most platforms.
>
> Ross
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com