Here you'll find a technical overview of the logic used in the 51Degrees.mobi Foundation solution. It covers the process used to determine whether a mobile device is making a request to your web site and how this information is used to redirect to a mobile-specific landing page. A guide showing you how to integrate the 51Degrees.mobi Foundation into your web site can be found here.
HTTP Headers
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. 51Degrees.mobi Foundation 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.
Some mobile devices, such as Samsung, Nokia and BlackBerry, will send an additional field usually called x-wap-profile that tends to be unique to the type of device. When this field is present, 51Degrees.mobi Foundation uses it to improve device detection accuracy and performance.
Mobile Device Databases
A database of mobile devices with
UserAgent as a primary key is needed to determine capabilities not contained in the request header. 51Degrees.mobi provides two versions of
mobile device data: the free
Lite version and a paid-for
Premium version that includes more mobile device properties and is updated more frequently. Both files are provided as an efficient binary form and also in XML form for those wishing to inspect the data or integrate it into other applications.
The 51Degrees.mobi device database contains a vast number of useragents and their associated hardware, software and browser. The Foundation employs a variety of techniques to match the UserAgent provided by the requesting browser to a device held in the mobile database.
When the 'worker' process 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 large amount of data is parsed and stored efficiently in memory. During device matching, a large amount of data needs to be searched rapidly to return devices and capabilities. 51Degrees.mobi Foundation 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 Requests
Every HTTP request received by a .NET web site has a browser object associated with it to provide information about the browser making the request. The browser object is of the HttpBrowserCapabilities class and is accessed via the 'Request objects' browser property. The standard .NET deployment from Microsoft contains little specific information about different browsers and devices, which means the browser object is of limited benefit for a mobile web site targeting a wide variety of mobile devices. 51Degrees.mobi enhances 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. 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, 51Degrees.mobi 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, three further actions are followed. First, a 'handler' is assigned after a simple check of the UserAgent string. This check will usually involve looking in the UserAgent string for a word or pattern that is typical of a particular manufacturer. 51Degrees.mobi contains handlers for over 70 manufacturers and browsers; 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. This Nokia handler will be used for any UserAgent string that contains the word Nokia, reducing the number of devices to search for at the second stage. The handler can then use a matching algorithm that is optimised to the requesting device. Three 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 slightly 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 an 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 - would have 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, such as Microsoft or Apple based devices.
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. This master device will contain an initial UserAgent string, usually the make and model name, with other components of the UserAgent string being absent. 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 possible devices may be identified. In this case, a further method needs to be used to reduce multiple possibles devices 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, 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, the first one in the list will be returned.
Detecting Mobile Pages
When a request is received by ASP.NET, an HttpHandler is assigned to process it and provide a response. 51Degrees.mobi intercepts request processing after the HttpHandler has been assigned but before the handler has started to do any processing. If the handler is not for a mobile page and the device is a mobile device, the request will be redirected. This precise behaviour can be altered via settings in the web.config file. See the User Guide for more details.
If you'd like to know more, please download the project or have a look at our forum.
Select one of the following headings to read more.