The standardization of Widget-APIs as an approach for overcoming device fragmentation

Contents

1 Abstract

2 Introduction
2.1 Widgets
2.1.1 Device APIs
2.1.2 Security
2.1.3 Packaging
2.1.4 Configuration
2.2 Widget Engine
2.3 Shortcomings of mobile web
2.3.1 technical reasons
2.3.2 marketing reasons

3 Current Innovations
3.1 W3C Recommendation
3.2 Joint Innovation Labs (JIL)
3.3 OMTP BONDI
3.4 Wholesale Applications Community
3.5 W3C ongoing work

4 Conclusion
4.1 Consequences and Alternatives
4.1.1 J2MEPolish
4.1.2 PhoneGap

5 Phonegap API Tests
5.1 Use Case I: Virtual Microscope
5.1.1 User Interface
5.1.2 Logic
5.2 Use Case II: Shop Finder
5.2.1 Reading geolocation
5.3 Phonegap Deployment

References

Appendix

1 Abstract

Since Apple released the iPhone in 2007 the conversion into a mobile web has ac­celerated strongly. This paper discusses the challenges resulting from that shift.

The diversity of platforms and device specifications put a heavy burden on develop­ers. While each platform offers an own proprietary API for developing applications it is often desirable to develop applications platform independently. One possible way today is to use web technologies. Although this offers a platform independent API many commonly used system APIs are not accessible. For most applications this is not acceptable since the use of sensors and file I/O is a premise to build modern user experiences.

But now another interesting part of mobile development begins to merge into the sphere of web technology. This is the use of widgets. Widgets were originally de­signed for desktop use as small single purpose applications but were quickly adapted on the web. Those applications are written using web standards like HTML, CSS and JavaScript.

The widgets we see on the web today can only use the limited JavaScript APIs that is provided by the browsers. Also the W3Cs current widget specification fails to deliver on device APIs, where only packaging and a widgets configuration is specified. That is why new specifications are about to be made and standardized. They describe Widget Engines and their APIs that wrap around modern handsets system APIs.

During the last two years mayor telecommunication companies founded joint ven­tures like JIL and BONDI to fulfill this goal. Both JIL and BODI have worked out specifications on device APIs and security as well as reference implementations for at least one mobile platform. These results are the input for a new round of widget specification within the W3C.

While there are neither standards nor implementations around today developers have to handle platform diversity themselves. This problem is tackled by some frameworks of which Phonegap and J2ME-Polish are introduced in the conclusion of this paper.

2 Introduction

The shift to a mobile usage of the web has become a mayor influence in advancement of web technology. Pioneering the mobile web was the Apple Newton which in 1996 was the first mobile handset to have a mobile browser [1]. The text-only browser was only capable of displaying a small subset of HTML. Since then the web entered handsets and smartphones till in 2007 Apple boosted the mobile Internet with another pioneering product, the iPhone.

While before the iPhone the Internet was just a feature of a smartphone, the Internet is what the iPhone is build around. The capability to do voice calls became just another feature of a what is now a modern handset. Along with new paradigms in user interface design a new kind of software distribution was introduced.

The first company to react to the iPhone was Google. A hole new mobile operating system that can be seen as Googles response to the iPhone is Android. Android is build on top of the Linux Kernel and follows the same paradigms the iPhone introduced.

- Touch interface
- extensibility via Apps
- App distribution over an online market

As the success of these paradigms became obvious competitors had to react. Today all mayor competitors comply or are at least in convergence to these paradigms.

While the capabilities of todays smartphones become more and more similar the APIs to access those are very different.

illustration not visible in this excerpt

Table 1: avaiable APIs across popular platforms

2.1 Widgets

The term widget is ambiguous. Whereas on the one hand the components building a userinterface are called widgets (e.g. buttons, scrollbars etc.) the term also refers to small single purpose applications. This paper refers to widgets in the form of applications. It is these widgets that are run by a widget engine (see 2.2). Their quick accessibility and their focus on a single purpose (i.e. stock ticker, rss reader, weather forecast) makes them well usable in a mobile context where time is short and usability is a key focus.

“Widgets are a class of client-side web application for displaying and up­dating local or remote data, packaged in a way to allow a single download and installation on a client machine or device. Widgets typically run as stand-alone applications outside of a web browser, but it is possible to embed them into web pages.” [8]

Building widgets on web standards offers a set of advantages of which portability is the most precious. Also there are lots of web developers who already possess the skills needed to develop widgets.

For a widget that is build on top of web technology four considerations are manda­tory.

- Device APIs
- Security
- Packaging
- Configuration

2.1.1 Device APIs

Device APIs are needed for accessing the underlaying operating system. This reaches from the phones hardware (e.g. accelerometer, GPS) over the filesystem to phone specific capabilities (e.g. access to contacts or dialing history).

2.1.2 Security

To protect the user against potentially malicious code a security model has to be established in which the user can grand privileges to a certain widgets. A key question in this context is how privileges are granted. It is an open debate on when and how long a privilege is granted.

At a minimum security level the user would grant permissions at widget installation time. At runtime the widget could use its permissions without further notification to the user (this is the security model embraced by Android).

At at much stronger a security model a widget would ask for permission at runtime. While this is more protective to the user it also has the risk of negatively influencing the usability by continuously prompting the user for permissions (this security model is embraced by Symbian S60). A security model has to be a tradeoff between protection and usability.

2.1.3 Packaging

As with web resources in general widgets are composed of multiple documents and resources (i.e. HTML, CSS, images, resources, etc.). It has to be defined what file and folder structure a standardized widget is expected to deliver.

illustration not visible in this excerpt

Figure 1: a widgets file and folder structure (W3C)

The W3C Candidate Recommendation Widget Packaging and Configuration defines a folder structure as displayed in figure 1. Also noteworthy is the .wgt file-extension which is an archive in zip format. It is used so that widgets are contained within a single file. Other considerations are internationalization and a file that holds the widgets configuration (i.e. config.xml).

2.1.4 Configuration

The configuration of a widget consists of a set of metadata-fields that define how a widget is handled by its runtime. There are fields for display properties (i.e. size, icons) and metadata for the name, version and author of a widget. The runtime uses the metadata for installation and initialization of a widget.

The appendix contains example configurations for widgets that follow different spec­ifications (i.e. W3C Widget 1.0, JIL (Vodafone 360), Nokia WRT).

2.2 Widget Engine

Widget engines provide the runtime environment for widgets. They handle its lifecy­cle, offer a window for drawing, the user interface and supply APIs that can be used by the widgets code. Most interesting for standardization are widget engines that are build on top of a browser engine. They are capable of rendering HTML/CSS and interpreting JavaScript for doing the business logic.

Another kind of widget engine is one that is build on top of the native OS and uses its UI and event environment. The advantage of those widget engines is that their widgets fit generally better into the userinterface. There are lots of those today but there is little hope that they will ever become standardized. Which in turn binds the widgets to a specific platform.

As pointed out, widget engines provide the application context. For running a widget it is mandatory not only to define the APIs but also to specify the packaging, a security model and a document structure (see 2.1). Of those definitions packaging and security have already been specified by the W3C [4].

[...]