W3C home > Mailing lists > Public > public-bpwg@w3.org > June 2009

MWABP: Revised text for Device Capability Detection.

From: Adam Connors <adamconnors@google.com>
Date: Thu, 18 Jun 2009 16:39:09 +0100
Message-ID: <393b77970906180839j3599013bxae7da4b18f03949d@mail.gmail.com>
To: Eduardo Casais <casays@yahoo.com>, Mobile Web Best Practices Working Group WG <public-bpwg@w3.org>
Hi Eduardo (and rest of group),

I have been working through my TODOs for the next draft of MWABP. Eduardo
raised some very interesting points regarding 3.6 Handling Device Capability
Variation. Here is the revised text. My general feeling is that what is
being said here is correct, but not necessarily useful...

The thing that is limiting the usefulness is that the really useful things
we could say are probably a little low-level / technical / specific to be
useful and there is much that can be said in general terms on this topic
(except that device capability detection remains a necessary evil). If
anybody has any ideas about what we are trying to express here your thoughts
would be appreciated.

Regards,

Adam.

3.6 Handling Device Capability Variation

Device capability variation is a basic characteristic of the mobile Web
environment. Web applications should adapt their content such that they
render as well as possible on as broad a range of target devices as
possible.
3.6.1 Prefer Server-side Capability Detection 3.6.1.1 What it means

Where possible it is preferable to detect device capabilities and
characteristics on the server and adapt content before it is sent to the
client in order to avoid transferring unnecessary data.
3.6.1.2 How to do it

Typically used methods of device capabilities detection:

   - The "User-Agent" header can be used to identify the device, and a
   Device Description Repository (DDR) can be used to retrieve a detailed
   description of capabilities;
   - The "Accept" header can be used to indicate specific MIME types
   compatible-to/preferred-by the device;
   - The "X-Wap-Profile" header (User Agent Profile or UAProf) can be used
   both as device identification and as a source of detailed device
   capabilities.

3.6.2 Use Client-side Capability Detection Where Necessary 3.6.2.1 What it
means

For some device characteristics where the configuration is not known on the
server application behaviour can still be adapted based on capability
detection on the device.
3.6.2.2 How to do it

Use JavaScript to determine device characteristics (screen size,
orientation) or if a given API is active. Two methods can then be used to
adapt on the client to differing configurations:

   1. Encapsulate the different behaviours in the control logic of the
   application. E.g. simply use: if
(some_configuration_variable)decision-points in the code and behave
accordingly;
   2. Use an initial "bootstrap" script to assess device capabilities and
   request the appropriate application bundle from the server.

Option (1) is simpler to implement and is appropriate provided the amount of
inactive code downloaded doesn't have a negative impact on performance.
Option (2) is preferred when the application must change significantly in
response to properties that can only be determined on the client.
Received on Thursday, 18 June 2009 15:39:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:01 UTC