WURFL API: Luca Passani Explains Its Benefits for Mobile Website Development

Editor's note: Welcome to .NETRocks Conversations, excerpts of conversations from the .NET Rocks! weekly Internet audio talk show. Hosts Richard Campbell and Carl Franklin chat with a wide variety of .NET developer experts. This month's excerpt is from show 653, with Luca Passani, a software engineer focused on mobile development who created the WURFL open source mobile-device-information repository and founded WURFL-Pro. Luca explains the value of WURFL as a time-saving tool for mobile website developers.

Carl Franklin: We got an email from your friend Dino Esposito, also from Rome, who said you guys have got to have Luca on. He has done something amazing for mobile devices. Tell us.

Luca Passani: Yes. So WURFL is exciting news for people who are approaching mobile now and are discovering that it's not like the web because every device is different and needs to be handled sometimes singularly. But people who have been doing mobile for some time have heard of WURFL or even use WURFL because it's been around for almost 10 years now.

CF: Now what does WURFL stand for?

LP: So that stands for Wireless Universal Resource File. Now about 10 years ago, the term "wireless" was used for what you would call "mobile" today. So if WURFL was created today, it would probably be called MURFL.

CF: MURFL.

LP: Which, yes, we thought it would be even worse than WURFL. But anyway, I digress. So it's WURFL. You Windows guys probably remember those INI files, the resource files.

CF: I'm trying to forget.

LP: Yes, right. Anyway, the point here was that WURFL would be some kind of resource file on steroids where the programmers could put information about the different devices. This way, updating mobile applications to accept and perform optimally with new devices will just be a matter of configuration, not recompiling or rebuilding your application to hardware device information. That was the basic point, to externalize their device information.

CF: Yeah.

LP: So WURFL is a repository of device information. The two main functions that the WURFL API performs are looking at the HTTP headers of request from a mobile device-and, most notably, the utilization string-and then after that [looking at] the WURFL ID, which is a string of the unique ID of an XML profile that contains information about the device. So the first function will map a utilization to the WURFL ID, and the second main function will map this WURFL ID and a capability name. Capability means property in WURFL speech.

CF: Yeah.

LP: So given an HTTP request, a developer can programmatically figure out how large the screen is, how many colors you have, and whether your device is Windows [Phone] 7.0 or not, or if it's Android, or if it's an iPhone. And also more detailed functions, like can I use the data when you write a schema to a nice picture inside the page? Are you familiar with the data you write? CF: Yes. Basically what I hear you saying is that this does what ASP.NET was supposed to do for us but for all of these devices. It's a huge repository of capabilities information for every mobile device out there.

LP: Right. In fact, there have been quite a few .NET programmers hanging out on the WURFL mailing list, and they never could figure out why Microsoft didn't come up with something along the lines of WURFL. Well, actually they did.

CF: They did.

LP: I remember there was something called Mobile Controls, but the device information was so poor or at least so simple that people preferred to look elsewhere, and WURFL was, of course, there. I know of some big companies that use WURFL in a .NET environment.

CF: Yeah.

Richard Campbell: So, this sounds like the BrowserCaps file for regular desktop browsers from years ago.

CF: Yeah. I mean, probably there is a similarity in the concept there, but WURFL, of course, took it a lot further because on a day-by-day basis it was a collective requirement from the community of the developers using WURFL.

RC: Digging all the way down to like, does the particular device have GPS or things like that?

LP: Yes. Well, actually we don't track GPS per se, but one of the capabilities in the JavaScript group is about which API can be used for location, whether it's a Google gear, or the W3C one, or whatever.

CF: And is this a static repository like a file that you have to constantly update, or is it a service?

LP: Essentially this is about a static repository, which any developer can download from the WURFL website, and off they go. They're totally independent. They don't need to rely on a third-party service to be available somewhere on the Internet.

CF: And you'll let us know when there are new versions of the repository, so we can keep that updated?

LP: Yes, if you are on the WURFL mailing list or just check the website regularly. About once per month we release the so-called WURFL snapshot. Originally the WURFL repository was a big XML file that we used to edit manually. But once it got over a few megs, it was not very nice to edit such a humongous file. So we created what we called the WURFL DB, which is a relational database where myself and contributors from the community can log in and add device information.

Now once per month we generate the wurfl.xml [file], which is the serialization in XML of the content of the database and that's syntactically identical to the old manually edited wurfl.xml. So nothing has changed for WURFL users, but now there is a public UI that contributors use to update device information.

CF: OK. That was the only thing that-I mean, I love the idea, but the automatic updating of that kind of thing would be a very, very nice feature, so I don't have to constantly update it.

LP: Yeah. So this is coming, and you will need to hold your breath for just a few weeks.

CF: Well, it's good that you're thinking about it.

LP: Yeah. Well, it's been a long time. So actually, let me do a little bit of history here.

CF: OK.

LP: When I created WURFL about 10 years ago, I was working for a company called Openwave, and so doing WURFL was related to my job of working with developers and helping in the ecosystem around development on mobile applications and mobile websites. In 2007 when I joined AdMob, I was not dedicating 100 percent of my time to WURFL. So today I no longer work for AdMob, which has been acquired by Google. In the meantime, I've been consulting for other projects and 50 percent to 80 percent of my time was taken by the process that paid the bills.

So I was the guy that was doing WURFL, but I was not dedicating 100 percent of my time to WURFL, which in hindsight is a stupid thing to do. I mean, I created WURFL. The whole world is using it, people constantly come to me, oh, look, how can you figure this, can you support that, and so what's going to happen in the next few weeks? I'm starting a new company around WURFL, and I will only be doing WURFL. As part of this project, we are building a portfolio of new tools and among them also the one about remotely updating WURFL with some kind of a web-service approach to the program.

CF: That's awesome.

LP: So to summarize, small shops that are totally OK with the free and open source approach will still have access to WURFL. Companies who like the idea of an open project but are OK with throwing some money at the problem of getting commercial, professional support for the tool, they're going to get it, too.

RC: How many devices are currently in your repository?

LP: That's a very good question. So if we talk about devices, I'll say in the order of 7,000.

RC: Wow.

CF: I didn't even know there were that many devices on the market.

LP: Well, to be fair, this process has been going on for like 10 years. So a lot of the devices there you will only find they should go to Washington, D.C., and in the Smithsonian museum.

RC: So yeah, you were talking about like back in the Nokia 6000 class WAP phones.

LP: The very first device was the Nokia 7110, which was really what we called the banana phone here in Europe. Anyway, it's 7,000 if you talk about make and models, but something that you should know is that certain devices are available on the market with a lot of different firmware variations. So you may find that the same device is available with 20 firmware variations, plus some devices will also have the localization and user agent's clique, plus some operators will modify the user agent to have gateway information.

RC: Right.

LP: So if you're talking about the number of different user agents being recognized, we're in the order of half a million, seven hundred thousand different user agents recognized by WURFL.

CF: Oh, my God.

LP: Yeah, because it could be that you take any Android phone. Because of the fact that the localization substring, NUS, NGP, IT, Text.it, it's Italian, those are all minor modifications in the user agent. Now it's not like WURFL lists all of those variations, but the WURFL API has the logic to still measure the device regardless of what the locale is.

CF: So I imagine a simple RSS feed might be a good way to do an automatic update, or Windows Service, or something, I don't know. I'm just thinking. I'm thinking I don't want to babysit just everyone.

LP: It's a good point because it's the kind of reaction that I get from developers who approach the program for the first time.

CF: Yeah.

LP: You'd be surprised at how manual the work of updating devices needs to be, because a lot of times you really need to do some research for each device and figure out the information about the device specifically.

CF: What does the code look like when you're querying this database? I mean, is it just a series of switches where you're checking for particular capabilities, and then...? I mean, what does the developer do with all that information?

LP: OK. So for the developer, the API is very simple… apart from setting up the objects, which in Java, and in PHP, and in .NET happen in different ways. The basic API is just a handful of methods. So basically, say, you get me a device object, which represents, which molds this device, which is a request in the page, and then you can request the value of the property like Device.Get Capability or Resolution With.

CF: Yeah.

LP: And this will give you the ways of the device clean.

CF: I guess another question is, one of the things that ASP.NET Web Forms programmers have been spoiled by is that the controls just sort of automatically know what to do with that information, but you're really talking about a situation in which a developer has to look at those capabilities and then craft the custom UI depending on those capabilities.

LP: Yes. So I remember looking at the Web Forms by Microsoft a few years back, and I recognized a certain pattern by Microsoft of making things as simple as possible for developers. Now Albert Einstein used to say, make things so simple, as simple as possible, but not simpler. This is actually a quote from my friend Dino, but it came from Einstein. I think this totally applies to the way Microsoft was approaching the problem, because sometimes you want the developer to do a little bit more effort but then to learn in the process and to have control to fix the particular programs that will come along the way.

CF: Right.

LP: Rather than pre-packaging and trying to fix all the worst problems up front, but then you want to have a framework that's powerful enough to really go deep to the right level of detail in fixing your program. You see what I mean?

CF: Yeah, definitely.

There's much more in the full interview!