Apps & Widgets

transcript

Apps & Widgets

Scott Wilson

[1] CETIS

scott.bradley.wilson@gmail.com

[2] Apache Wookie (incubating)

http://incubator.apache.org/wookie

scottbw@apache.org

[3] W3C Webapps WG

QuickTime™ and a decompressor

are needed to see this picture.

are needed to see this picture. Widgets

HTML &| SVG

JavaScript

config.xml

mywidget.wgt

Icon.png

W3C Widgets: for Web, Mobile, or Desktop?

Apple DashboardWindows SidebarGoogle DesktopKonfabulatorOpera Widgets

OpenSocialGoogle GadgetsGoogle Wave

GadgetsWidgetBoxSpringWidgets

Nokia WidgetsiPhone AppsAndroid AppsSamsung Bada

How about, “yes”?

Basic Widget Authoring Process

• Make a webapp (HTML5, JS, CSS)• Make a basic config.xml with

name, author• Give it an icon (icon.png)• Zip it up• Change extension from .zip to .wgt

Device APIs: Adding Extra Capabilities to Widget

JavaScript

• W3C Widget API

• BONDI (WAC)

• W3 DAP

• W3 Geo

• Address Book• Calendar• Files• Media capture

(camera)• Messaging• System• Policy• Media Gallery• Tasks• Comms LogJavaScript

</script> </head> <body>

<button onclick="takePicture()">Take Picture</button><img id="picture" src="" width="64" height="64"/>

</body></html>

Feature mapping

<feature name=“http://bondi.omtp.org/api/camera.capture”

required=“true”/>

JavaScript

Feature mixing!<feature name=“http://opensocial.org/osapi.person” required=“true”/>

You can connect all kinds of functionality to widgets by injecting a JS API for it at runtime - and not just device APIs either

JavaScript

Did you know that Opera Unite services were W3C Widgets?QuickTime™ and a decompressorare needed to see this picture.

“W3C Widgets are better than websites because they download only the data; and not the core files.”

“Widgets are better than app systems because you don't have to write 4, 5, or 10 of them. Just the one is enough.”

“And hundreds of thousands of web developers already know how to create widgets.It's just HTML/CSS/JavaScript, after all.”

- Peter Paul Koch

W3C Widget App Stores & Implementations

“A fundamental part of WAC is to ensure that developers have the simplest method by which they can create applications for the long tail. A key part of this is to endorse and encourage the use of technologies which are based around open standards. WAC plans to initially use both the JIL and OMTP BONDI requirements, evolving these into a common specification within the next 12 months. The long term goal will be to collectively work with the W3C for a common standard based on our converged solution.”

Aplix WRT for Android

Ripple - Emulator for JIL/BONDI widget dev.

BlackBerry Widgets is a platform to allow developers to leverage their existing web knowledge to build compelling mobile applications. A BlackBerry Widget combines standard web technologies with local device functionality in a familiar fashion while still providing industry leading security. Based off of the W3C Widget specification, a BlackBerry Widget is an alternative approach to building a mobile application in a native SDK yet still provides the same power and functionality. By using standard web technologies, the barrier for building compelling BlackBerry applications has been significantly lowered.

* “Wookie” is not a clever acronym. so if you spell it WOOKIE you’re shouting!

A Java server application in the Apache Incubator. Includes a W3C Widget parser library.

http://incubator.apache.org/wookie

How Wookie Works(pretty much* like shindig/opensocial)

Integrating Wookie• Connector Framework

– Java, PHP, Python, C#, Flex…

• Plugins– Elgg, Wordpress, Jetspeed, Drupal, Moodle,

LAMS…

• IMS BasicLTI adapter– Blackboard, D2L, Sakai …– https://code.google.com/p/basiclti4wookie/

• Backend:– JPA, JCR– Shindig adapter/deployment config*

• Participants:– Userid, display name, profile image

• Instances– Shared id (e.g. for courses)

• Properties– Key, value

• Widgets– Gallery-type metadata

Basic LTI parameter Wookie usage

lti_message_type Not used

Lti_version Not used

Resource_link_id Mapped to shareddatakey

User_id Mapped to userid

Roles Can be mapped onto “moderator” preference setting, or “isOwner” participant property

Lis_person_name_given Not used

Lis_person_name_family Not used

Lis_person_name_full Mapped to participant.displayname

Lis_person_contact_email_primary Not used

Context_id Not used

Context_type Not used

Context_title Not used

Context_label Not used

Launch_presentation_locale Mapped to locale.

Launch_presentation_document_target Could be mapped to Widget View Modes but is currently not compatible.

Launch_presentation_width Not used

Launch_presentation_return_url Used for redirecting to an error page if a request doesn’t work

Tool_consumer_instance_guid Not used

Tool_consumer_instance_name Not used

Tool_consumer_instance_description Not used

Tool_consumer_instance_contact_email Not used

Moodle…

Basic profile info from platform is shared with widgets through plugin

LAMS…

WebCT, Blackboard, D2L, Sakai…

Elgg… etc*(*Wordpress, Apache Wicket, Jetspeed, Simal…)

A few widget best practices

Build widgets to W3C, not for Wookie alone

– Don’t rely on special internal Wookie features (e.g. DWR) if it can be avoided

– Try to provide fallbacks for installed features which may not be available for other widget containers (e.g. Wave)

Consider mobile users tooW3C Widgets can also run in MS Windows Mobile, Opera,

Aplix and other platforms - if you design them with mobile use in mind

• Don’t navigate or use popups - always use widget.openUrl()– Will use device native best practice and user prefs (e.g.

switch to mobile browser app, open new tab, prompt user etc)

• Don’t rely on cookies - use widget.preferences– User may access from different devices; use preferences

instead to store user personalisation or tracking info.• Do keep your widgets as small as possible• Do follow the W3C mobile web guidelines where it

makes sense

Security and privacy

• While you can store user credentials in widget.preferences, this is not necessarily a very secure place to put them

• In future oAuth may be added to Widgets and Wookie, which will make life a lot easier (see also Apache Amber)

• Widgets are bound by same-origin policy; until CORS is implemented, you need to use the server-side proxy offered by wookie for AJAX calls. You can use WARP to indicate access is needed in config.xml, e.g.<access origin="https://example.net"/>

Thanks

scottbw@apache.org@scottbwhttp://incubator.apache.org/wookie

Apps & Widgets

Documents