Comparing OpenDDR to WURFL
Both WURFL and OpenDDR projects provide an API to access the DDRs, in order to ease and promote the development of Web content that adapts to its Delivery Context.
WURFL recently changed its license to AGPL (Affero GPL) v3. Meaning that it is not free to use commercially anymore. Consequently some free open source alternatives have recently started to show up. OpenDDR is one of them.
In this post I will share my findings on how the OpenDDR Java API compares to WURFL.
Add dependencies to project
This section describes how to add WURFL and OpenDDR to a Maven project. WURFL
WURFL is really straightforward since it is available on Maven central repository. All you have to do is to include the dependency on your project:
<dependency> <groupId>net.sourceforge.wurfl</groupId> <artifactId>wurfl</artifactId> <version>1.2.2</version><!-- the last free version --> </dependency>
OpenDDR
OpenDDR on the other hand is quite difficult to configure. Follow these steps to include OpenDDR in your project:
- Download OpenDDR-Simple-API zip.
- Unzip it and create a new Java project on Eclipse based on the resulting folder.
- Export OpenDDR-Simple-API JAR using Eclipse
File >> Export...
, include only the content of thesrc
folder excludingoddr.properties
file. - Install the resulting JAR and
DDR-Simple-API.jar
from thelib
folder into your local Maven repositorymvn install:install-file -DgroupId=org.w3c.ddr.simple -DartifactId=DDR-Simple-API -Dversion=2008-03-30 -Dpackaging=jar -Dfile=DDR-Simple-API.jar -DgeneratePom=true -DcreateChecksum=true mvn install:install-file -DgroupId=org.openddr.simpleapi.oddr -DartifactId=OpenDDR -Dversion=1.0.0.6 -Dpackaging=jar -Dfile=OpenDDR-1.0.0.6.jar -DgeneratePom=true -DcreateChecksum=true
- Add the dependencies to your project
pom.xml
file:<dependency> <groupId>org.w3c.ddr.simple</groupId> <artifactId>DDR-Simple-API</artifactId> <version>2008-03-30</version> </dependency> <dependency> <groupId>org.openddr.simpleapi.oddr</groupId> <artifactId>OpenDDR</artifactId> <version>1.0.0.6</version> </dependency> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-jexl</artifactId> <version>2.1.1</version> </dependency> <dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> <version>2.6</version> </dependency>
Load repository/capabilities file
This section describes how to load WURFL and OpenDDR repository file(s) and import it in your project. WURFL
Copy wurfl-2.1.1.xml.gz
file (the last free version) into your project src/main/resources
folder and import it using:
WURFLHolder wurflHolder = new CustomWURFLHolder(getClass().getResource("/wurfl-2.1.1.xml.gz").toString());
OpenDDR
Copy oddr.properties
from the OpenDDR-Simple-API src
folder and all the files inside OpenDDR-Simple-API resources
folder into your project src/main/resources
folder. Import them using:
Service identificationService = null; try { Properties initializationProperties = new Properties(); initializationProperties.load(getClass().getResourceAsStream("/oddr.properties")); identificationService = ServiceFactory .newService("org.openddr.simpleapi.oddr.ODDRService", initializationProperties.getProperty(ODDRService.ODDR_VOCABULARY_IRI), initializationProperties); } catch (IOException e) { LOGGER.error(e.getMessage(), e); } catch (InitializationException e) { LOGGER.error(e.getMessage(), e); } catch (NameException e) { LOGGER.error(e.getMessage(), e); }
Using the API
This section describes how use WURFL and OpenDDR Java APIs to access the device capabilities. WURFL
WURFL API is very easy to use and has the big advantage of having a fall-back hierarchy inferring capabilities for devices not yet in its repository file.
Device device = wurflHolder.getWURFLManager().getDeviceForRequest(getContext().getRequest()); int resolutionWidth = Integer.valueOf(device.getCapability("resolution_width")); int resolutionHeight = Integer.valueOf(device.getCapability("resolution_height"));
There’s no need to validate device.getCapability("resolution_width")
against null
value when no data is available.
OpenDDR
OpenDDR is quite the opposite. Very cumbersome and does not have a fall-back hierarchy, forcing the developer to validate each property value.
PropertyRef displayWidthRef; PropertyRef displayHeightRef; try { displayWidthRef = identificationService.newPropertyRef("displayWidth"); displayHeightRef = identificationService.newPropertyRef("displayHeight"); } catch (NameException ex) { throw new RuntimeException(ex); } PropertyRef[] propertyRefs = new PropertyRef[] { displayWidthRef, displayHeightRef }; Evidence e = new ODDRHTTPEvidence(); e.put("User-Agent", getContext().getRequest().getHeader("User-Agent")); int maxImageWidth = 320; // A default value int maxImageHeight = 480; // A default value try { PropertyValues propertyValues = identificationService.getPropertyValues(e, propertyRefs); PropertyValue displayWidth = propertyValues.getValue(displayWidthRef); PropertyValue displayHeight = propertyValues.getValue(displayHeightRef); if (displayWidth.exists()) { maxImageWidth = displayWidth.getInteger(); } if (displayHeight.exists()) { maxImageHeight = displayHeight.getInteger(); } } catch (Exception ex) { throw new RuntimeException(ex); }
Results
The following table shows the results of tests run against an application for server-side image adaptation using both WURFL and OpenDDR.
These tests were performed on real devices and pages were served as XHTML BASIC (same as XHTML MP).
Platform | Device | Property | WURFL max_image_width (1) / max_image_height |
WURFL resolution_width / resolution_height |
OpenDDR displayWidth / displayHeight |
---|---|---|---|---|---|
N/A | Firefox desktop | width | 650 | 640 | Not supported |
height | 600 | 480 | Not supported | ||
iOS | iPhone 4S | width | 320 | 320 | 320 |
height | 480 | 480 | 480 | ||
Android | HTC One V | width | 320 | 540 | Not supported |
height | 400 | 960 | Not supported | ||
HTC Hero | width | 300 | 320 | 320 | |
height | 460 | 480 | 480 | ||
Windows Phone 7.5 | Nokia Lumia 710 | width | 600 | 640 | 480 |
height | 600 | 480 | 800 | ||
BlackBerry | BlackBerry Bold 9900 | width | 228 | 480 | 640 |
height | 280 | 640 | 480 | ||
Symbian S60 | Nokia E52 (Webkit) | width | 234 | 240 | 240 |
height | 280 | 320 | 320 | ||
Nokia E52 (Opera Mobile) | width | 240 | 240 | Not supported | |
height | 280 | 320 | Not supported | ||
Windows Mobile 6.1 | HTC Touch HD T8282 | width | 440 | 480 | 480 |
height | 700 | 800 | 800 |
(1) max_image_width
capability is very handy:
Width of the images viewable (usable) width expressed in pixels. This capability refers to the image when used in “mobile mode”, i.e. when the page is served as XHTML MP, or it uses meta-tags such as “viewport”, “handheldfriendly”, “mobileoptimised” to disable “web rendering” and force a mobile user-experience.
Note: The color #9f9 highlights the results that performed better. Pros and Cons
Pros | Cons | |
---|---|---|
WURFL |
|
|
OpenDDR |
|
|
Related Posts
- Eclipse RCP to Cellphones
- Java EE 6 Testing Part II – Introduction to Arquillian and ShrinkWrap
- Java EE 6 Testing Part I – EJB 3.1 Embeddable API
- Stripes framework XSS Interceptor
- Maven 2 Cobertura Plugin – Updated
- Previous Entry: Java EE 6 Testing Part II – Introduction to Arquillian and ShrinkWrap
Reference: Comparing Device Description Repositories from our JCG partner Samuel Santos at the Samaxes blog.
Have you tried comparing it to Deviceatlas?