340 likes | 468 Views
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. Widgets. HTML &| SVG. config.xml. JavaScript. CSS. Icon.png. mywidget.wgt.
E N D
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
Widgets HTML &| SVG config.xml JavaScript CSS Icon.png mywidget.wgt
W3C Widgets: for Web, Mobile, or Desktop? Apple Dashboard Windows Sidebar Google Desktop Konfabulator Opera Widgets Nokia Widgets iPhone Apps Android Apps Samsung Bada OpenSocial Google Gadgets Google Wave Gadgets WidgetBox SpringWidgets
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
W3C Widget API BONDI (WAC) W3 DAP W3 Geo Address Book Calendar Files Media capture (camera) Messaging System Policy Media Gallery Tasks Comms Log Device APIs: Adding Extra Capabilities to Widget JavaScript JavaScript
<html> <head> <script> function takePicture(){ var camera = bondi.camera.getCameras()[0]; camera.takePicture(function(pic){document.getElementById("picture").src=pic;},function(){alert("nope");}); } </script> </head> <body> <buttononclick="takePicture()">Take Picture</button> <imgid="picture"src=""width="64"height="64"/> </body> </html>
<feature name=“http://bondi.omtp.org/api/camera.capture” required=“true” /> Feature mapping JavaScript
<feature name=“http://opensocial.org/osapi.person” required=“true”/> <feature name=“http://wave.google.com” 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 Feature mixing! Did you know that Opera Unite services were W3C Widgets? JavaScript
“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
“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.”
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
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*
API • Participants: • Userid, display name, profile image • Instances • Shared id (e.g. for courses) • Properties • Key, value • Widgets • Gallery-type metadata
Basic profile info from platform is shared with widgets through plugin Moodle…
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 too W3C 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. <accessorigin="https://example.net"/>
Thanks scottbw@apache.org @scottbw http://incubator.apache.org/wookie