Overview
Here you'll find an overview of the logic used in the .NET Mobile API. A guide showing you how to integrate into your web site can be found here. This page covers the process used to determine if a mobile device is making the request to the web site and how this information is used to redirect to a mobile specific landing page.
Operational Summary
UserAgent Strings
Every browser either mobile or traditional will send a string that identifies itself when accessing a web site. This string is called the UserAgent and is transmitted in the header fields of the HTTP request. In .NET the UserAgent string is accessible via the UserAgent property of the HttpRequest object. This API takes the UserAgent string as the primary method of identifying the mobile device, browser and associated capabilities. The most important capability to determine is the mark-up supported so a page can be rendered in the correct format.
Mobile Device Databases & WURFL
Databases of mobile devices with UserAgent as a primary key are needed to determine capabilities not contained in the request header. Operated by WURFL-Pro (the company founded by Luca Passani, the WURFL inventor), the WURFL device database is widely-accepted as the most advanced and up-to-date mobile device database available. More information is available here. WURFL is the primary device database used by the .NET Mobile API.
The WURFL device database contains partial of complete UserAgent strings for all known mobile devices. This API uses a variety of techniques to match the UserAgent provided by the requesting browser to a device held in the database.
When the API is initiated all the available device data is loaded into memory ready for devices to be matched rapidly and capabilities returned to your web site application. During initial load a lot of data is parsed and stored efficiently in memory. During device matching a lot of data needs to be searched rapidly to return devices and capabilities. The API is written specifically to complete these tasks as quickly as possible using the smallest amount of memory. It will perform significantly faster than a generic data storage solution using a database.
Processing Page Request
Every HTTP request received by .NET web site has a browser object associated with it providing information about the browser making the request. The browser object is of type HttpBrowserCapabilities and is accessed via the Request objects Browser property. The standard .NET deployment from Microsoft contains very limited information concerning different browsers and devices. Therefore the browser object is of limited benefit for a mobile web site targeting a wide variety of mobile devices.
This API uses device databases to enhance the browser object making it significantly more useful when developing mobile web sites and applications.
When a new request is received the device making the request is determined from the UserAgent string and the device database. If the device is mobile the capabilities already provided by .NET are enhanced with the capabilities found for the device in the database.
Matching Mobile Devices
When a HTTP request is received the API must find a matching device from the database. As the device database will not necessarily contain an exact match for the UserAgent string other less precise matching logic may need to be applied.
If an exact match fails 3 further actions are followed. The 1st will assign a handler for the match based on a simple check of the UserAgent string. This check will usual involve looking for a word or pattern at the beginning or in the middle of the UserAgent string which is typical of a particular manufacturer. The API contains handlers for 36 manufacturers. Each handler employs an optimal matching algorithm for the device type. During the initial load of data from the device database devices are split across the available handlers based on the UserAgent string held in the device database.
For example all the Nokia devices from the database will be assigned to the Nokia handler. The Nokia handler will be used for any UserAgent string that contains the word Nokia. This approach reduces the number of devices to search for at the 2nd stage. Assigning a handler has reduced the number of devices that need to be checked, and the handler uses a matching algorithm that is optimised to the requesting device. 3 matching algorithms are available, each using different logic to find the best matches.
Edit Distance (ED) – calculates the number of characters that need to be changed for one string to be turned into another. If the strings “The Fat Hog” and “The Fat Dog” were compared by an ED calculation the result would be 1 as the H and D are the only letters that are different. The implementation used in the API is modified from Levenshtein Distance.
Segment – regular expressions are used to break the UserAgent string into relevant segments. For example; the model, version and sub version are extracted from the string and any other information is ignored. The extracted segments are then compared using and edit distance calculation and a value assigned to the closeness of each match. Additionally the handler can assign a weight to each segment controlling the importance of the segment to a successful match. For example; the model name may be extremely important and can be assigned a large weight whilst the sub version number which is less important a lower weight. This algorithm is often quicker than an edit distance calculation on the entire string as fewer characters need to be compared. However it will only work for manufacturers who employ consistent patterns easily detected by regular expressions.
Reduced Initial String (RIS) – device databases will often define a master device for a particular phone. Variants or future versions of the same device will reference the master device. The master device will contain an initial UserAgent string, usually the make and model name, other components of the UserAgent string being removed. Variants that reference the master device will use more complete UserAgent strings. Often it is sufficient to match the initial string only and that’s exactly what a RIS match will do.
Final Start & Tail - Sometimes an ED or Segment match will not result in a single answer. Several devices may share the same results. A further method needs to be used to reduce to a single device. If one string has more initial matching characters than any of the others this one will be returned. If multiple results still exist then the matching initial characters are removed and an ED calculation performed on the tails. The device with the lowest ED value is then returned. If there are still multiple matches then the 1st one in the list is returned.
Detecting Mobile Pages
When a request is received by .NET an HttpHandler is assigned to process it and provide a response. This API intercepts request processing after the HttpHandler has been assigned but before the handler has started to do any processing. If the handler is derived from MobilePage the request is for a mobile page.
Pulling it all Together
So at the start of request processing we know if the device is mobile and if the page is mobile. If a mobile device is attempting to request a non mobile page then the device will be redirected to a mobile specific landing page. Traditional browsers accessing mobile pages will proceed as normal.