Serve ASP.NET Website Content to Mobile Users

Thanks to larger and larger screen resolution and increasing processing power, the latest smartphones can blissfully display regular websites. But is this really what users want? Typically, regular websites are too rich with information; in most cases, the font is too small and nearly impossible to read. Following links can be as challenging as catching a fly. Sure, users can browse a website using a smartphone, but at the cost of continuously zooming in and out pages and relying on the browser's ability to reflow text quickly and effectively in the actual screen real estate.

Not all websites have a mobile version and not all of them need one. In general, having a mobile site with certain features is part of a company's mobile strategy and relates to the business model and the vision that management has for it. How would you take visitors to your mobile site after it has been deployed to production?

One option requires that visitors explicitly point to a specific mobile website such as m.yoursite.com. Another option is that your website detects mobile devices and automatically redirects them to a mobile site, or to the section of the regular site that can serve content optimized for mobile devices. As a user, I prefer to be automatically redirected to content tailor-made for the device rather than having to type the mobile site URL myself. As an ASP.NET developer, how would you redirect visitors to another site? At first this doesn't seem like such a complex task. Rocket science isn't required, but the devil can be found in the details. Let's find out more.


Detecting Mobile Browsers

Detecting Mobile BrowsersIn ASP.NET, you have a simple way to determine whether the browser that placed the request is running on a mobile device or a desktop. You just check the value of the IsMobileDevice property exposed by the Request.Browser object and take a route based on the Boolean value you receive. The MSDN documentation says the IsMobileDevice property returns true if the browser is a recognized mobile device. And that's the sore point. The logic the property uses to detect devices is not really accurate and it fails on quite a few browsers running on the latest mobile devices. Without beating around the bush, let me say that the default implementation is not useful; a replacement is required.

The code to write is not complex. You need an HTTP module that intercepts incoming requests as early as possible and parses the user agent string identifying the capabilities of the browser and the underlying device. The problem here isn't writing the HTTP module; the problem is figuring out the information in the user agent string.

Today, an interesting number of ASP.NET sites use a specific framework for browser detection—51Degrees.mobi. You can obtain the framework from http://51degrees.codeplex.com or directly from Visual Studio as a NuGet package. The 51Degrees.mobi framework is based on an HTTP module that intercepts requests and determines a device's capabilities. In doing so, the framework also updates and, in some cases, extends the information in the browser object. If you have NuGet installed in Visual Studio, all you have to do is locate the package in the library manager. Figure 1 shows the window you see from within an ASP.NET project when you choose to add a package reference.

Figure 1 The Visual Studio package list

Installing the package makes some changes to the current project. In particular, a couple of assemblies are added to the Bin folder and, more importantly, a zipped XML file is added to the App_Data folder. This file contains the most accurate up-to-date information about the capabilities of mobile devices. The HTTP module uses this information to identify the capabilities of the requesting device. Note that the 51Degrees.mobi framework doesn't query the device directly; it just attempts to identify the record in the WURFL database that matches the browser's user agent. Any information WURFL contains about the device capabilities is copied into the Request.Browser object and returned to the ASP.NET application. WURFL, an open-source project started by Luca Passani about 10 years ago, matches the browser's user-agent to the corresponding device profile. Because the WURFL database is frequently updated and extremely detailed, the odds that you'll fail with a particular mobile browser are low. By now, WURFL is the de facto standard solution for device recognition. I'll return to WURFL later.

A Look at a 51Degrees-Enabled Project 

The key changes the 51Degrees package introduces in your project are in the web.config file. First and foremost, a new HTTP module is registered to capture incoming requests:

    
                 type="FiftyOne.Foundation.Mobile.Redirection.RedirectModule, 
                 FiftyOne.Foundation" />
    

 


The behavior of the module is driven by settings entered in a custom section. Figure 2 lists the attributes you can set.

Figure 2: Settings in the section

As you can see, the framework is quite flexible; allowing you a lot of freedomn setting up things while being unobtrusive with the structure of the site. In particular, the framework provides an optional landing page meant to be the home page of the mobile site or the root page of your site's mobile section. Redirecting every single request might represent an unneeded burden for your application. With the firstRequestOnly attribute you can redirect only the first request. If your pages use relative links, no further redirection would be required after the first. The timeout attribute (set to 20 minutes by default) indicates the time of inactivity after which a new request should be considered again as the first and be redirected.

The flexibility of the framework shows up well in the description of the attribute, which lets you group together a bunch of pages in the site and redirect them to a given mobile URL. By defining multiple entries under the node, you easily map a set of regular pages to a section of the mobile site and even achieve a one-to-one mapping. Here's the default configuration you get from the NuGet package:

          firstRequestOnly="false"
          devicesFile="~/App_Data/Devices.dat" 
          timeout="20" 
          mobilePagesRegex="/Mobile/" />

The package adds to your site a default landing page and operates on each and every request. All pages in your site that match the /Mobile/ URL are treated as mobile pages and ignored by the redirect module. With this code in place, let's see what happens when you visit the site with a few mobile devices.


Testing Devices

The code of a sample ASP.NET application equipped with 51degrees.mobi has been uploaded to my site. You can try it out by visiting www.expoware.org/mobi. Figure 3 shows the effect of navigating to the website with an Android device and the Windows Phone 7 emulator.


Figure 3: Redirected to the mobile landing page from Android and WP7 browsers


At present, you can't easily grab a screenshot of a real Windows Phone 7 device, but I guarantee that the real experience is exactly the same as the emulator demonstrates.

Figure 4 shows what happens when using an iPad. Note the reported values of properties like IsMobileDevice and IsTablet.

Figure 4: Redirected to the mobile landing page from an iPad

The identification of the device is definitely accurate. In particular, the screenshots reproduce the output generated by the code Figure 5 shows.

Figure 5: Code that generates the screenshots Figure 4 shows

Manufacturer: <% =Request.Browser.MobileDeviceManufacturer %>
Model: <% =Request.Browser.MobileDeviceModel %>
Model: <% =Request.UserAgent %>
IsMobileDevice: <% =Request.Browser.IsMobileDevice %>
Screen Width: <% =Request.Browser.ScreenPixelsWidth %>
Screen Height: <% =Request.Browser.ScreenPixelsHeight %>
Tablet Device: <% =Request.Browser["is_tablet"] %>
Pointing Method: <% =Request.Browser["pointing_method"] %>

Some attributes of modern devices are missing in the public interface of the HttpBrowserCapabilities class, an instance of which is returned by the Request.Browser property. Aware of this, designers of the HttpBrowserCapabilities class added an indexer property that 51Degrees leverages to add extra information that the WURFL database offers and that isn't reflected by the public browser capabilities API. Attributes like is_tablet and pointing_method just demonstrate the usefulness of the indexer. Another interesting WURFL attribute you might want to check is device_os:

Device OS: <% =Request.Browser["device_os"] %>

51Degrees.mobi is a framework through which you can easily control the behavior of the site when accessed from a mobile device. The framework serves the purpose of automatically redirecting users to mobile content. But you could let users decide whether a redirect will occur.

Some mobile browsers have a nice feature that lets users decide about the user agent string the browser sends out. Figure 6 shows how you can enable (or disable) the mobile user agent on an Android device's native browser.

Figure 6: Enable or disable mobile versions of web pages

IE on Windows Phone 7 offers the same capability. Currently, I'm evaluating the usability and implementation of a feature that would allow users to control a redirect on a per-site basis, for example through a popup message and saving preferences to a cookie.

What's WURFL?

51Degrees is an excellent piece of work, seamless to set up, effective, and flexible enough to meet most of your expectations. The WURFL database, an XML file that contains detailed information about myriads of mobile devices, does amazing work in the background. The project site is at http://wurfl.sourceforge.net. Open to contributions from the entire web and mobile community, the project has the goal of tracking capabilities of new devices as they hit the market. To contribute a new device profile, or just to read about an existing profile, you connect to a public service called WURFLDB. To do so, however, you must first register as a contributor. You can find details at http://www.wurflpro.com/static/top.htm. The link also contains information about the WURFL schema and the fallback mechanism.

To explore the information that WURFL can serve you, you can read the source XML file—not really a recommended experience, although sometimes necessary. It's easier if you go to www.tera-wurfl.com/explore, and much better if you follow the link with a mobile device.

You can freely incorporate WURFL in any of your applications and components, regardless of their personal, open-source, or commercial nature. Of course, a requirement is that any modification you apply to the file is returned to the community.

The Best Practice

Although more and more mobile browsers can display regular websites, this is not often the best experience for end users—or at least, not for all of them. On tablet devices, you can probably display a regular website with little trouble; the same can hardly be said for a smartphone. From a developer's standpoint, arranging a mobile site, a mobile section of the site, or just mobile views is more and more a mandatory step.

The problem is finding the best way to let users know about mobile content and serving that. A common choice these days is automatically redirecting a user to the mobile content. For this to happen, it's critical to correctly identify the device. In this regard, WURFL plays a fundamental role because it's the most accurate mobile device database. How would you integrate WURFL? You can do that manually by leveraging the public WURFL API, or you can resort to platform-specific frameworks that do that for you.

Dino Esposito, author of Programming Microsoft ASP.NET 4 and Programming Microsoft ASP.NET MVC (Microsoft Press), is a trainer and consultant specializing in web and mobile architectures and effective code design principles and practices. Follow Dino on Twitter at @despos.