Android Web Wigets

Web Widgets
on Android
MobileMonday Developer Day, Dusseldorf, 23 February 2010
Status Quo: Ecosystem View
Android is not YAMP! (Yet Another Mobile Platform)
Pervasive, rich, attractive, (mostly) open
Enjoys wide industry support
Shipping 60,000 cell phones per day (but still competing for market share)
Used increasingly in non-mobile verticals, such as smart home
Paradigm shift for mobile Java
Status Quo: Developer View
Android is YAMP in their portfolio!
Requires new porting efforts, knowledge, testing, devices, marketing
Avalanche of versions (1.0-2.1) in just two years!
OEMs & operators customize UI, features, APIs to bring value and differentiate
Different features and screen sizes to be addressed
Porting for and within Android ecosystem is a full time job!
Q: What happens in 2-5 years?
Hopefully not!
Can web apps help?
Mobile Web App Ecosystem
Browser
Traditional Approach to Mobile Web Apps
Advantages:
Easy, easy, easy!
Common web technologies, portable, variety of tools
Lots of web developers 
Apps in the cloud easy to update
Disadvantages:
No integration with phone functions, like location, messaging, PIM, address book, etc.
Data bandwidth
No offline mode
Web page lifecycle doesn’t feel like native app
How about web widgets?
Web Widgets (for Mobile)
Define web widget:
Application, written using common web technologies (HTML, JS, SVG, Flash, etc.)
Deployed as a single package file into the end user`s browser
Processed and interpreted as a set of locally-hosted web pages
Obeying lifecycle, security and networking requirements
Lifecycle feels like a native app
Originally developed by Opera and called Opera Widgets: http://widgets.opera.com
Evolved further into W3C Widget specification: http://www.w3.org/TR/widgets/
Web Widget Anatomy

id="http://acme.com/MyFancyWidget"
width="240"
height="320">
My Fancy Widget



Example: config.xml
Packaging format: single zip file, .wgt extension
Mime type: application/widget
Configuration (manifest) file: config.xml
Entry point: index.html or custom file
Content: HTML, JS, any resource, any mime type recognized by the browser (Flash, SVG, video, etc.)
Security and networking enforcement
Signing
Web Widget Ecosystem
Browser
Widget
Web Widgets (for Mobile)
Advantages:
Easy, easy, easy!
Common web technologies, portable, several SDKs
Lots of web developers 
Works in offline mode
Lifecycle feels like a native app
Disadvantages:
No integration with phone functions, like location, messaging, PIM, address book, etc.
What about JIL/BONDI/WAC?
Beyond W3C Widgets
BONDI “uses web technologies and builds upon them to provide new APIs to the key mobile phone functionality like Contacts, Calendar, Messaging & Location”
JIL will “enable different widgets and applications to run seamlessly on different handset platforms and operating systems across different mobile operators, while safeguarding customer security, data privacy and billing systems”
Wholesale Applications Community (WAC) “aims to unite a fragmented marketplace by involving players from all related industries to create a community based on openness and transparency to the benefit of all”

Translation please: cross-platform app model, based on W3C Widgets, extended by built-in JavaScript APIs for device access
Use Cases
Social Address Book
Contact list from the native address book
Existing Facebook friends automatically detected
Direct access to the friend’s wall
Messaging editor with merged SMS and Facebook history
Buttons to initiate a voice/video call
Sticky GeoNotes
Paper notes are so lame 
Leave a text/voice/video message for your family and colleagues
Based on your current location
Enriched Web Widget Ecosystem
Browser
Widget
Why Should You Care?
Too many BIG players pushing for it!
JIL devices shipped in 2009
BONDI devices shipping in 2010
Cross-platform apps easier to develop!
But beware of these pitfalls:
Browser-specific workarounds
Screen sizes and orientation
Large amounts of business logic and networking code in JS may not be too much fun
Beyond JIL/BONDI/WAC
(Problem solved! What else can we ask for?)
Beyond JIL/BONDI/WAC
Wouldn’t you like to:
… expose your own services to widgets?
… write business logic in Java rather than JavaScript?
… write networking code in Java rather than JavaScript?
… leave the widget code to UI designers and developers?
You’d be out of luck nowadays: current implementations don’t provide means to extend the device APIs
Mobile OSGi
But there are efforts in that direction based on mobile OSGi:
OSGi used on mobile, embedded, smart home, enterprise platforms, and spreading
Mobile OSGi (JSR 232) deployed on a wide variety of mobile platforms (Android, Symbian, WM, BREW)
Enables dynamic code deployment and update, dynamic service wiring, code reuse, versioning and more:
http://www.osgi.org/About/WhyOSGi
OSGi complements, not replaces Android platform
http://www.osgi.org/About/Technology
Mobile OSGi + Web Widgets
Mobile OSGi
Browser
Widget
Remote OSGi Services
Mobile OSGi and Web Widgets? So, how does it work:

Step 1: Design and implement your service in Java

public interface MyService {
public void doSomething(String param);
}

Step 2: Register in OSGi as “remotable” service

MyService instance = new MyServiceImpl();
Properties props = new Properties();
props.put("org.osgi.remote.publish", Boolean.TRUE);
bundleContext.registerService(MyService.class.getName(),
instance, props);
Using Services from Widgets
Step 3: Use Remote Service Registry JS API to bind services
and get a proxy service object

var so = RSR.bind(“MyService”);


Step 4: Invoke a function on the proxy service object

so.doSomething(“param”);
Easy enough!
Conclusion
Web Widgets increasingly seen as a cross-platform app model with huge market potential
Android-based devices supporting Web Widgets are shipping now
Web Widgets are empowered with rich device access capabilities
Mobile OSGi offers a middleware solution to allow dynamic APIs for Widgets
Additional resources:
www.prosyst.com
dz.prosyst.com
mobileosgi.blogspot.com
Thanks
Sinisha Djukic
[email protected]