MWI Team Blog
Dispatches from members of the W3C Mobile Web Initiative Team
Categories: Current state (31) | Developing Countries (14) | Events (16) | Looking forward (10) | News (35) | Technical (28) |
Exposing device capabilities to web applications — 6 February 2008
There is huge potential for mobile web applications that can access device capabilities from client-side scripts. There has been a lot of work on J2ME APIs for Java based applications, but we lack standards for exposing local device capabilities to applications running in web browsers. The time has surely come for W3C to bring interested parties together to work on fixing this as a matter of priority.
Properties like location, with privacy and associated legal issues, will clearly be more complicated to deal with, as we will need to address the security and trust models involved. But other properties like battery level, signal strength, light and vibration control, should be much easier to progress.
The Device Description WG is defining APIs for access to properties of classes of devices, and the OMA is defining a protocol and server-side API for access to dynamic properties (DPE) that will enable servers to dynamically adapt media streams to match device orientation and bandwidth. The UWA WG has recently moved DCCI to CR and published the first draft WD for an ontology for the delivery context, where the ontology is decoupled from the APIs that it models. DCCI is a client-side framework, but doesn't itself define any properties. With a little work, DCCI could be used for:
- dynamic content adaptation on client
- checking battery level, signal strength
- controlling the display brightness
- turning the phone's vibrator on and off
- checking screen orientation and size
- checking available free memory
- implementing location-based services
- interface to on-phone applications (PIM) including calendar and contacts
- allowing web page scripts to initiate phone calls
Comments, Pingbacks:
Comment from: Peter Cranstone [Visitor]
· http://www.5o9inc.com
Dave,
Everything you have outlined above can be done using nothing more than the current HTTP standard and a simple browser plug-in on the mobile device.
We can show you everything you are talking about in your post right now running over current HTTP standards talking to standard Apache or IIS web servers.
In addition our design allows for the consumers privacy to be maintained while keeping in place the current JavaScript sandbox - but yet allowing JavaScript to talk to the mobile device "IF" the consumer allows it.
Our solution can do all of the following:
# dynamic content adaptation on client
# checking battery level, signal strength
# controlling the display brightness
# turning the phone's vibrator on and off
# checking screen orientation and size
# checking available free memory
# implementing location-based services
# interface to on-phone applications (PIM)
including calendar and contacts
# allowing web page scripts to initiate phone calls
And more.
Cheers,
Peter
Everything you have outlined above can be done using nothing more than the current HTTP standard and a simple browser plug-in on the mobile device.
We can show you everything you are talking about in your post right now running over current HTTP standards talking to standard Apache or IIS web servers.
In addition our design allows for the consumers privacy to be maintained while keeping in place the current JavaScript sandbox - but yet allowing JavaScript to talk to the mobile device "IF" the consumer allows it.
Our solution can do all of the following:
# dynamic content adaptation on client
# checking battery level, signal strength
# controlling the display brightness
# turning the phone's vibrator on and off
# checking screen orientation and size
# checking available free memory
# implementing location-based services
# interface to on-phone applications (PIM)
including calendar and contacts
# allowing web page scripts to initiate phone calls
And more.
Cheers,
Peter
Comment from: Dave Raggett [Member]
Thanks for the info. A number of companies have explored the plugin approach, but so far there has been little work on common APIs. I think it is critical to bring together all of the stakeholders and perhaps a W3C Workshop sponsored by the Mobile Web Initiative might be a good way to assist with that.
Comment from: Mark Baker [Visitor]
· http://www.markbaker.ca
The WHAT-WG/HTML-WG seems to have picked a handful of client-side services in HTML 5 that are in need of standardization, but beyond those I think there's a whole lot of innovation yet to happen, so premature standardization could really hurt. If any does happen though - because I admit that sometimes the need for a standard is greater than the cost of not standardizing - we should make sure that it's really truly needed.
Regarding dynamic content adaptation on the client, can you please elaborate a little more? Does this mean, that the server rendering the service (service delivery platform for example)will not play a role in adapting the content according to the device capabilities? The client device will adapt the content by itself?
Comment from: Dave Raggett [Member]
One mechanism for client-side adaptation is CSS media types This allows you to specify media dependencies for style rules. Unfortunately, few mobile browsers implement the "handheld" media type which CSS 2.1 defines as being appropriate for handheld devices (typically small screen, limited bandwidth).
Another approach to client-side adaptation is to use a web-page script to show or hide parts of the markup, or to actively modify the DOM tree. Currently browsers provide very limited access to the delivery context, although you can get the width and height of the screen. However, it may also be possible to use XMLHttpRequest to access further information held on the Web server from which the page was downloaded. For instance, making use of the Device Description Repository API, defined by the W3C Device Descriptions Working Group.
Another approach to client-side adaptation is to use a web-page script to show or hide parts of the markup, or to actively modify the DOM tree. Currently browsers provide very limited access to the delivery context, although you can get the width and height of the screen. However, it may also be possible to use XMLHttpRequest to access further information held on the Web server from which the page was downloaded. For instance, making use of the Device Description Repository API, defined by the W3C Device Descriptions Working Group.