Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries. Thanks for all your past and future contributions.

Detecting Mobile Devices on Web Services

From Wiki
Jump to: navigation, search
Article Metadata
Created: jaaura (27 Apr 2009)
Last edited: NokAndrea (14 Oct 2011)



Most of today’s Web sites are laid out for presentation on high resolution desktop displays. Accessing such a page on a mobile device often results in a poor user experience. Due to limited screen size, the context and overview are lost. Other challenges are limited connectivity, cost of bandwidth, and input method.

Device detection is the most important step when optimizing Web services for mobile devices. The wide variety of hardware and software types makes static mobile pages a poor choice. For example Nokia N900 has a resolution of 800 x 480 pixels and touch screen as its input method. Nokia N95 has a resolution of 240 x 320 pixels and keyboard as its input method. Clearly, two devices with this different input and screen attributes have different interaction requirements.

This document will go through some of the currently popular solutions for device and device attributes detection, as well as provides few basic optimization examples based on such information retrieved.

Device detection options

Devices and their attributes can be identified in many ways, and each has its pros and cons. The solutions covered in this document are user agent string, user agent profile, device information database and categorization patch to WURFL device database. Visual looks can also be changed with CSS media queries, but with CSS media query you cannot really change content, you can only change how it is presented.

Method Pros Cons
User agent string Easy to implement Good only for detecting if it’s mobile or desktop
User agent profile Lots of info Causes overhead, because profile must be loaded
Device information database Common database for all data Requires resources and harder to implement
Custom categories in WURFL Custom categories in WURFL Requires updates
CSS media query Simple way choosing CSS file to load Doesn’t save bandwidth as much as other ways

Table 1: Comparison of different detection methods

User agent string

The HTTP header field contains information about the user agent originating the web request. The device model is displayed clearly. For example Nokia N95 sends the user agent (UA) string Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/11.0.026; Profile MIDP-2.0 Configuration/CLDC-1.1) AppleWebKit/413 (KHTML, like Gecko) Safari/413. This clearly identifies Nokia N95 as the device, but no real device attributes are stated in the UA string, such as resolution or input method. A list of these has to be built separately. If resolution and input method are the category factors, the result looks like Table 2.

Resolution Touch Keyboard Both
240 x 320 Group 1 Group 2 Group 1/2
320 x 240 Group 3 Group 4 Group 3/4
360 x 640 Group 5 Group 6 Group 5/6
800 x 352 Group 7 Group 8 Group 7/8

Table 2: Example Web service grouping for S60 devices

There are many devices available, and maintaining such a grouping is an endless and pointless task. The number of client devices supported by a Web service is a major factor that determines if the service will be a success or failure.


  • Easy to implement
  • Detection is very fast and needs no resources


  • No device attributes, one size fits all mentality

The UA string works perfectly for simple services that only need to know if the client is a mobile device or not. See Example 1 for implementation in the PHP language.

Example 1 - detecting mobile devices

The following is a simple example written in PHP for detecting if a device is mobile or not. The code is split in three functions where lite_detection is the main entry point and returns a simple boolean value if the visitor is a mobile device or not. While the example covers most of the mobile devices, you should check your Web server logs and make sure there are no false positives.

Copyright (c) 2009 James Pearce & friends, portions mTLD Top Level Domain Limited, ribot, Forum Nokia
Online support:
This file is part of the WordPress Mobile Pack.
The WordPress Mobile Pack is Licensed under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with the
You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed
under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
CONDITIONS OF ANY KIND, either express or implied. See the License for the
specific language governing permissions and limitations under the License.

function lite_detection() {
if (isset($_SERVER['HTTP_X_WAP_PROFILE']) ||
isset($_SERVER['HTTP_PROFILE'])) {
return true;
$user_agent = strtolower($_SERVER['HTTP_USER_AGENT']);
if (in_array(substr($user_agent, 0, 4), lite_detection_ua_prefixes())) {
return true;
$accept = strtolower($_SERVER['HTTP_ACCEPT']);
if (strpos($accept, 'wap') !== false) {
return true;
if (preg_match("/(" . lite_detection_ua_contains() . ")/i", $user_agent)) {
return true;
if (isset($_SERVER['ALL_HTTP']) && strpos(strtolower($_SERVER['ALL_HTTP']), 'operamini') !== false) {
return true;
return false;
function lite_detection_ua_prefixes() {
return array( 'w3c ', 'w3c-', 'acs-', 'alav', 'alca', 'amoi', 'audi', 'avan', 'benq', 'bird', 'blac',
'blaz', 'brew', 'cell', 'cldc', 'cmd-', 'dang', 'doco', 'eric', 'hipt', 'htc_', 'inno', 'ipaq', 'ipod',
'jigs', 'kddi', 'keji', 'leno', 'lg-c', 'lg-d', 'lg-g', 'lge-', 'lg/u', 'maui', 'maxo', 'midp', 'mits',
'mmef', 'mobi', 'mot-', 'moto', 'mwbp', 'nec-', 'newt', 'noki', 'palm', 'pana', 'pant', 'phil', 'play',
'port', 'prox', 'qwap', 'sage', 'sams', 'sany', 'sch-', 'sec-', 'send', 'seri', 'sgh-', 'shar', 'sie-',
'siem', 'smal', 'smar', 'sony', 'sph-', 'symb', 't-mo', 'teli', 'tim-', 'tosh', 'tsm-', 'upg1', 'upsi',
'vk-v', 'voda', 'wap-', 'wapa', 'wapi', 'wapp', 'wapr', 'webc', 'winw', 'winw', 'xda ', 'xda-',
function lite_detection_ua_contains() {
return implode("|", array(
'android', 'blackberry', 'hiptop', 'ipod', 'lge vx', 'midp', 'maemo', 'mmp', 'netfront', 'nintendo DS',
'novarra', 'openweb', 'opera mobi', 'opera mini', 'palm', 'psp', 'phone', 'smartphone', 'symbian',
'up.browser', '', 'wap', 'windows ce',

UA profile

Just like the UA string, the UA profile is available in the HTTP headers. There is no standard header field for the UA profile, but usually it is x-wap-profile or profile. The UA profile is an RDF document that contains detailed information, which can be used by content providers to produce the appropriate format for a specific device. The UA profile provides a good amount of information about a device, for example the screen size, multimedia capabilities, and character set. More recent profiles include more detailed information, such as video, streaming, and MMS capabilities. The lack of a universal central repository for UA profiles and the lack of a guarantee for the validity of the data provided in the files are the major downsides of this approach.

For example Nokia N5800 XpressMusic sends an x-wap-profile header field that contains the document at From this document, you can parse resolution <prf:ScreenSize>360x640</prf:ScreenSize>, but the input method is not specified in the document.


  • Detailed information resulting in a dynamic site based on individual device properties


  • Not all devices have a UA profile
  • No universal central repository
  • Data errors
  • Retrieving and parsing a profile in real time adds a lot of overhead to a Web request

For more information check the UA profile specifications:

Device information databases

Device information databases are an alternative source of information to UA profiles. Device information databases aim at providing as much information as they can about any given device. Databases provide more information and details than UA profiles. There are numerous different database solutions, but this document concentrates on introducing an open source solution called WURFL (

WURFL is a free open source project that provides a comprehensive resource of device information and contains more than 10 000 device variants. Because WURFL is an open source solution, anyone can contribute to the device information database, and submit new information and corrections. WURFL provides the device database in XML format and interface for parsing it in several languages (PHP, Perl, Ruby, Java, Python, C++, dotNET). Example 2 shows how to install and request parameters from WURFL with PHP.


  • Detailed information resulting in a dynamic site based on individual device properties
  • More information than in a UA profile
  • Framework for requesting device attributes
  • Local database means less overhead


  • Harder to implement

Device attributes

Currently, WURFL has offers lots of information about the device. Features that WURFL offer:

  • Basic information about device
  • Information about WML browser, CHTML browser and XHTML browser interface
  • Known CSS issues
  • Ajax support
  • Supported markup languages
  • Browser cache
  • Devices display size and colors
  • Supported image formats
  • Bugs in browser
  • WTA features
  • Security features
  • Network connection options
  • Storage space
  • Downloadable objects
  • Playback features
  • DRM
  • Streaming support
  • WAP Push
  • Supported MMS features
  • Supported SSM features
  • J2ME features
  • Flash lite support
  • Support for RSS feeds
  • Support for PDF files

Complete list of information offered by WURFL can be found here.

As stated, the browsing behavior varies significantly depending on the device used, but also on what kind of service is being developed.

Example 2 - retrieving device attributes

This example shows how to retrieve device attributes using WURFL. The new WURFL PHP API is very easy to use and does not need installation like its predecessor did. The device cache is built from the XML file the first time WURFL is initialized. This takes from ten seconds up to few minutes.

// initialisation code
require_once "WURFL_Installation/WURFL/WURFLManagerProvider.php";
$wurflConfigFile = "WURFL_Installation/resources/wurfl-config.xml": //provide the absolute or
relative path to the config file.
$wurflManager = WURFL_WURFLManagerProvider::getWURFLManager($wurflConfigFile);
$requestingDevice = $wurflManager->getDeviceForHttpRequest($_SERVER);
// request device attributes
$width = $requestingDevice->getCapability("resolution_width");
$height = $requestingDevice->getCapability("resolution_height");

A fully working example is included in the WURFL package under examples directory.

Example 3 - optimization based on the device attributes

Navigation and easily click-able links provide a good basis for the best possible user experience on touch devices.

Illustration 1 (non-optimized) demonstrates the problem. Navigating or clicking such a menu using a finger or a touch pen is very difficult, especially if there is any movement, such as when using the device on a bus or a train.

Illustration 2 (optimized) demonstrates an optimized result. The font and margin are scaled based on device height in pixels.

Before optimisation.jpg After optimisation.jpg

This following code shows how to use WURFL to achieve this.

$inputmethod = $requestingDevice->getCapability( 'pointing_method');
$mobile = $requestingDevice->getCapability( 'is_wireless_device');
// mobiles with touchscreen
if ( $inputmethod == 'touchscreen' && $mobile)
$height = $requestingDevice->getCapability( 'resolution_height');
$size = round($height / 30);
$padding = round($size / 2);
echo '
a {
margin: '
.$padding.'px 0;
font-size: '
display: block;
// all other mobiles (joystick, wheel)
else if ( $mobile)
// non-mobile
<li><a href="index.php/home">Home</a></li>
<li><a href="index.php/references"References</a></li>
<li><a href="index.php/services">Services</a></li>
<li><a href="index.php/about-us">About us</a></li>

Device categorization using WURFL and WURFL patchfiles

Usage of WURFL can be made easier if devices inside WURFL are assigned to few categories. One possible way of categorization is: low-end, mid-range, high-end and touch devices.

Low-end category

Low-end devices have simple support for web pages and therefore pages must be greatly optimized so they work like they are supposed in end device. Low end devices also can’t handle great amount of data, so unneeded images and graphics must be removed. Low end devices also usually have very small screen, which limits web page layout.

Mid-range category

Mid-range devices have better support for web pages, but still cannot handle all web elements that desktop browsers can handle. Mid-range devices can handle little bit more data in pages.

High-end category

High-end devices almost have same kind of support for web pages than desktop browser. Main limitation in high-end devices is the screen size. Also web pages must be optimized so user can easily move in them without mouse.

Touch category

Touch devices are high-end devices which have touch as their input device. With touch devices the navigation in pages is easier, but sizes of interactive things must be considered, because user must be able to click what he wants.

Why to use categories rather than just WURFL

It makes easier to develop pages, because you have to make just few different versions and redirect visitor according to its category to right version. Also WURFL patch is easier to maintain than always coding new conditions to your code when new devices appear.

In WURFL patchfile you can also categorize whole product group to be on specified category. Like you can specify that all S60 5th devices are in touch category, and then by only updating WURFL database, all new S60 5th devices will belong to your category.

Implementing categories to WURFL

Best way to implement categories to WURFL is to make WURFL patchfile which extends WURFL’s database. WURFL patchfile is XML which defines new capabilities, new devices or changes old values. First you have to define default values of new capabilities values in generic device.

<device id="generic" user_agent="" fall_back="root">
<group id="dd_group">
<!-- low_end / mid_range / high_end / touch / desktop -->
<capability name="dd_category" value="low_end"/>
<!-- "" / 1.0 / 1.1 -->
<capability name="dd_nokia_wrt" value=""/>

This XML file generates new capability group "dd_group" to WURFL and then adds two new capabilities inside it. The "dd_category" capability defines the category in which the device belongs and "dd_nokia_wrt" device defines if device has Nokia’s Web Runtime installed.

Devices are then categorized to their corresponding categories. With this code we can define Nokia S60 5th to be touch devices with WRT 1.1 installed.

<device id="nokia_generic_series60_dp50" user_agent="Nokia 60 Developer Platform 5.0" fall_back="nokia_generic_series60_dp30_webkit">
<group id="dd_group">
<capability name="dd_category" value="touch"/>
<capability name="dd_nokia_wrt" value="1.1"/>

In WURFL patchfile those "id", "user_agent", "fall_back" attributes must be correctly copied from their correspondent in WURFL database.

Adding new device to patchfile

First you have to find your device from the wurfl.xml file.

<device id="nokia_generic_series60_dp30" user_agent="Nokia 60 Developer Platform 3.0" fall_back="nokia_generic_series60_dp20">

Here we are adding information to Nokia S60 3rd devices, so we need "id", "user_agent" and "fall_back" strings from wurfl.xml to the patchfile. Then you add to your patchfile same line as in wurfl.xml and add your changes inside it.

<?xml version="1.0" encoding="UTF-8"?>
<device id="nokia_generic_series60_dp30" user_agent="Nokia 60 Developer Platform 3.0" fall_back="nokia_generic_series60_dp20">
<group id="dd_group">
<capability name="dd_category" value="high_end"/>

Here we added group called "dd_group" and inside it we added capability "dd_category" with value "high_end". Now all S60 3rd devices should have this value added in them.

Enabling WURFL patchfile

To enable WURFL patchfile in WURFL you only have to add entry to your WURFL configuration.


Then you just you WURFL like normally, but now you can ask those new capabilities from WURFL and make easier decisions in your code when you have only few choices rather than all the data of WURFL.

define("WURFL_DIR", dirname(__FILE__) . '/../WURFL/');
require_once WURFL_DIR . 'WURFLManagerProvider.php';
$wurfl = WURFL_WURFLManagerProvider::getWURFLManager("config/wurfl-config.xml");
$device = $wurfl->getDeviceForHttpRequest($_SERVER);
$category = $device->getCapability("dd_category");
$wrt = $device->getCapability("dd_nokia_wrt");
if ($category!="desktop") {
if ($wrt != "") {
header("Location: wrt.php");
} else {
header("Location: $category");
… desktop browser site

This example redirects mobile browsers to subdirectory according device’s category or if device has WRT features then it will try to install it. Desktop browsers won’t be directed anywhere.

Source for demo are here.

Steps to enable WURFL categorization

If you want to start using WURFL categorization in your site, here are few steps which you must do to get it working.

  1. Get WURFL and install it
  2. Download and activate WURFL patchfile to your installation. Patchfile has good base which can be easily updated.
  3. Update patchfile if needed.
  4. Now you can get category of accessing device and modify content based on that.

Related Articles

Mobilizing Website Using Nokia Mobile Web Templates

This page was last modified on 14 October 2011, at 12:33.
152 page views in the last 30 days.