WURFL ASP.NET Implementations

Introduction

It is very well documented how the inbuilt Request.Browser object has shortcomings in the mobile web-application world (here and here). WURFL is an open-source project which succeeds in filling the void left by these problems. There are a growing number of ASP.NET implementations of WURFL. We will be discussing three of these:

RedCircle - An implementation that seems to have been authored by Paulo Gomes whilst working for RedCircle.

wurflAPI (aka WURFL as a dotNetAPI) - An initiative of the WURFL Sourceforge project.

Background

WURFL is based on matching the user-agent string as identified by the request object (on the server), with an "ambitious configuration file that contains info about all known Wireless devices on earth" (http://wurfl.sourceforge.net/backgroundinfo.php). The resulting node is parsed into a Capabilities collection which enumerates the known properties of the mobile browser. These include groups of properties (full breakdown) like:

product_info - Human readable brand and model name and other generic info

wml_ui - User Interface for WML browser

chtml_ui - User Interface for Compact HTML

xhtml_ui - User Interface for HTML/XHTML-MP browser

css - CSS-issues

ajax - Supported Mobile Ajax features

markup - Supported markup languages

cache

display

image_format

bugs

wta

security

bearer

storage

object_download

drm

streaming

wap_push

mms

sms - Binary SMS and SCKL capabilities

j2me

sound_format - supported sound formats

flash_lite - Macromedia/Adobe Flash Lite

transcoding - Handle abusive transcoders

rss - Native support for RSS feeds

pdf - Native support for PDF documents

These properties can be queried for conditional rendering for different devices (implemented manually), or if Adaptive Control Behaviour is supported and mobile controls are used, the page is automatically rendered in different ways depending on the capabilities of the browser. A good practical example of Adaptive Control Behaviour is explained by Paulo Gomes formerly of RedCircle here.

The Tests

As some metrics were needed, objects that can be initialized in the Global.asx file were initialized in the page code-behind so that the processing could be timed. Also the code is not optimized in any way (do not use it in its current form); it has been designed solely to be audited (via time logs). The time results shown cannot be taken seriously in an absolute sense, but the patterns and relative values can be compared. The files were deployed to a Virtual PC with Windows XP Professional Version 2002 Service Pack 2 and IIS 5.1 running.

For the most part, I expect that the project will be browsed by desktop computers (for evaluation); the WURFL data file included doesn't have all of the desktop user-agents included and will use generic values. This in itself is a disparity with how the code will run in production as it adds lookup(s) to get the generic value.

The test plan was fairly simple; general comparisons were of interest but caching and the handling of data changes were important features to assess. The tests included:

My Observations

RedCircle

Other than the very first load (test #1) it performed very well; most of the times were less than a millisecond. To achieve this, a capabilitiesWhiteList was added to the Web.config file.

On a previous test-drive of the RedCircle Framework, I asserted that there was a mechanism that reloaded the data when it was changed. In these tests, this was not the case: with test #9, none of the WURFL implementations reloaded the data when the WURFL.xml file was modified.

The API was easy to use although quite a lot of configuration is needed in the web.config file.

Although not tested in this article, the framework has a plain vanilla Adaptive Control Behaviour implementation particularly useful if outputting WML.

WURFL.Marg

Marg performed well across the board; test #5 result seems like an anomaly though.

The API is a little more complex to use, but as the Request.Browser is assigned to, the built-in Adaptive Control Behaviour is functioning based on the WURFL device list.

There is more tight coupling than the other implementations. Log4net must be referenced from the consuming project and there are more modifications needed in the web.config file.

wurflAPI

This implementation performed the worst; I'm not sure whether it is being maintained anymore, even though it is a Sourceforge project.

It does not seem to support Adaptive Control Behaviour.

Points of Interest

There did not seem to be any automatic mechanism in the frameworks for reloading objects on data file modification. Fortunately System.Web.Caching can monitor and reload data files with very little coding.

The team that is working on Marg (Miha Valenic seems to be a senior member) also offers a more comprehensive hosted solution for adaptive rendering; dialogs of the details can be found here.

My organisation, 51degrees.co.uk, has released an open source .NET Mobile API at www.51degrees.co.uk. The API takes WURFL data and integrates it into the .NET framework. We've focused on performance in the design and a performance test page is included in the demonstration project. It may be useful to readers of this article.

Hi, Nic.
New Official WURFL .NET API is under development. If you want more info, check WURFLDotNetAPI group[^]. It is a direct port of Java NG API.
The SVN repository seems to be closed, but I can send you a snapshot if you want.

Other API, but outdated, is my personal implementation: Somms.NWURFL[^]. It was a try of abstracting search logic from data access. I'm working on a new version, with heuristic and browserCaps mapping.

I checked out another implementation (not Somms.NWURFL) which was a direct port of the JavaApi and it was "flakey as". I hope this one has more momentum...

> I'm working on a new version

I think it will be important to factor in a decent caching model where the WURFL tree (or a whitelisted subset of it) can the loaded into application scope, and quicker calls made for user-agent specific methods.

Hey Nic,
The .net wurfl API is not a direct port of the latest java api.
For an .NET version of the latest java api (including the LD string comparison), check out:

http://www.5thfinger.com.au/corporate2/wurflApi.asp

Also, there's a web application the company i work for has recently released that provides an http web service to return the device data. It's available at http://www.mobileelements.com and its built on our custom useragent matching technology.

If you'd like to contact me privately, i'd be happy to set you up an account so that you can add it to your list of api's to test.

I also built out a test harness that was intended to test accuracy instead of speed, that i'd like to share with you for feedback, and maybe inclusion in the article.

First off, I work for dotMobi and am the lead developer of the DeviceAtlas API, that's the disclaimer out of the way.

I wanted to fill you in on the facts re DeviceAtlas. I don't want to go into a hard sell but rather to encourage you to do some impartial testing of our API vs WURFL, we had one user on the mobiForge.com forums who did one last year that generated some healthy debate around the two systems however his tests were with the Java API, and the old one at that

We have recently released v2.3 of our API as a Beta and hope to have it thouroughly tested and released officially in the next month or so. I'd encourage you to download it and try it out, http://deviceatlas.com/downloads/beta.
(Yes, you do need to register to download Your membership is shared with all our sites by the way, I'm sure you'd be a valued contributor at mobiForge)

The download comes with a sample data file that you can use for your tests. The data in the sample file was generated in late January so should be relatively up to date. It is a new format that will become official when the API does as it includes data about UA Profile headers and allows you to add these to your API queries. We have found this greatly improves the accuracy of your queries, especially when the device uses a generic UA like many Windows Mobile devices and Blackberrys.

A few general points to note:

1. The developer licence available on our site is FREE and valid for only one year but is NOT limited in any way. The data you get and the API you download are exactly what you get with a paid licence. We just trust you to be honest and buy a licence if you use DeviceAtlas commercially.

2. The number of properties we have is smaller than WURFL, however we have chosen the set of properties we offer carefully based on user feedback to:
a) Not bloat the data with properties that you don't need and mostly have no data for
b) Offer the properties that developers tell us are important.

We regularly add new properties that are requested by our users. If we don't have a good data source for them we create tests on our test suite at deviceatlas.mobi (Also ta-da.mobi). Every person that visits deviceatlas.mobi with a mobile phone completes a set of tests that help us gather data about their device.

3. Our data is distributed as a JSON file for a few reasons:
a) Speed, it parses very quickly.
b) Size, the data file is much smaller than it would be if we used XML and as a result improves the speed.
c) Layout, our data is structured in a special tree structure allowing it to be searched very efficiently without the need for regular expressions. There is no need for developers to look into or even understand the data structure, that's what the API is for

4. We have numerous data sources. The most powerful of which is our test suite, deviceatlas.mobi, which I have already mentioned. Users are also able to manually submit data via our web interface. Other sources include WURFL itself, data from numerous operators and manufacturers and other valueable partners such as Volantis. What we try to do with DA is pull all of these sources together and distill the data such that we get the best and most accurate dataset. Each source has gradings based on our confidence in their data and as such conflicts are resolved based on this. These weightings constantly change as we reassess our sources and compare their data to the data we receive elsewhere.

So there you go, DeviceAtlas in a very big nutshell

One of the new features we're particularly happy about with the new .NET API, and one I'd REALLY appreciate your feedback on, is the IIS module that is now part of the new API. It plugs into any ASP.NET app and suppliments the existing Request.Browser object with the up-to-date data from DeviceAtlas.

When I undertook the article, I just wanted to share some of the findings that I encountered when doing my own research. The article is about WURFL implimentations; so it would be out of context to discuss APIs other than WURFL. It certainly is a good enough topic for another article but I cannot commit to that at this point in time.

Some brief feedback on what you have mentioned:
1. > developer licence available on our site is FREE and valid for only one year but is NOT limited in any way - I prefer open-source, or at least free without limits.

2. > The number of properties we have is smaller than WURFL - that is fine for web development if you have the crucial ones.

3. > data is distributed as a JSON file - I like JSON.

4. > We have numerous data sources - the source, relevance, and continual maintenace of the data are decisions the customer will have to make a decision on.

> It plugs into any ASP.NET app and suppliments the existing Request.Browser object

No problem. As you say a comparison of the 2 is out of context for this article. If you are interested in comparing the 2 as the subject of a new article at any time please feel free to contact me for any help or information. (Also we may ask your permission to re-publish the article.)

Obviously you prefer Open Source Who doesn't prefer something free over something you have to pay for, count me amongst that number too. That said DeviceAtlas tries to cater to the whole web developer market from individual developers doing small websites right up to large systems integrators working on massive enterprise level websites.

The support contracts we offer our enterprise customers are an important differentiating factor between ourselves and WURFL, as I believe is the case with most OS software. The need for a strong SLA, as you say, is down to the developer and the project requirements, but it's always interesting to know how we compare "down on the track".

Hi, thanks for the info!. In your article you mention a fairly simple way to reload objects when wurfl.xml or any of the other data files gets updated using System.Web.Caching, can you share how you do that? I've been unable to find a simple way

I finally published the article on caching WURFL (www.codeproject.com/KB/aspnet/WURFL_AbstractCacheShare.aspx). It wraps WURFL.Marg but with a little retooling can wrap the other implementations as well.

UPDATE (2009-02-08): I have temporarily pulled the project while I check out a few new contenders...

UPDATE (2009-02-09): The article is up again. Stuck with marg as other solution was in beta.