Adding Support for a New Browser

You can add support for a new browser in two primary ways. The first approach is to modify the configuration so that the browser is recognized with the correct capabilities and the adapters can render the proper markup, and it is successful when the markup produced by the existing adapters works with the new browser. If the browser requires markup changes that can’t be configured, you need to write custom adapters and then modify the configuration so that it can utilize them. In the section “Writing a Custom Adapter,” which appears later in this chapter, we’ll go through the steps for writing and configuring new adapters.

The browserCaps section is made up of sets of use and filter elements. The use element indicates which request header to use in the filter elements that follow it. The filter element contains one or more case elements that match elements from the header being used and set the browser capabilities. For example, in the browserCaps section in the following code, the first use element specifies that we are using the User-Agent header. It is followed by a long list of defaults. These defaults are then overridden to more specialized values by the various matching case elements.

<browserCaps>
    <result type="System.Web.Mobile.MobileCapabilities" />
    <use var="HTTP_USER_AGENT" />
        activexcontrols=false
        …
        platform="Unknown"
        preferredRenderingType="html32"
        …
        isMobileDevice="false"
    <filter>
        <case match="Windows 95|Win95">
            platform=Win95
        </case>
        <case match="Windows 98|Win98">
            platform=Win98
        </case>
        <case match="Windows NT 5.1|Windows XP">
            platform=WinXP
        </case>
        <case match="Windows NT 5.0|Windows 2000">
            platform=Win2000
        </case>
     </filter>
</browserCaps>

Notice in this snippet from machine.config that after the use element indicates that the User-Agent is being examined, the default capabilities invoked are for a fairly generic HTML device that specifies the most common set of capabilities. This configuration should achieve the broadest coverage for browsers that aren’t recognized specifically in the code.

Tip

When a browser isn’t recognized in the browserCaps configuration section, the default behavior is to treat it as an HTML 3.2 device without support for client-side scripting.

The case elements within a filter element act like a switch-case construct. Once a match is found, evaluating the rest of the case elements within that filter is unnecessary. For example, if the platform is found to be Microsoft Windows 95, the default unknown platform is overridden, and the remaining platform checks are skipped.

Let’s walk through what it takes to add device information by creating configuration for an imaginary sample device. We’ll do it the same way we would to add support for a real browser. This device is from a company just entering the mobile browser market. We’ll call the company NewPlayer. Their new browser is the WmlColor2000. First we need to create a filter entry to match the User-Agent string of the device. If the device were a new model from a manufacturer recognized by the configuration, we would nest the specialization within an existing match. In our example, we create a new top-level filter element to match the User-Agent string: “NewPlayer Color 2000.” We then specify the preferred rendering type and set the MIME type to be WML. These two capabilities are used in selecting the adapter and in returning the correct header values in the HTTP response.

<filter>
    <case match="NewPlayer Color 2000.*">
        browser="NewPlayer WmlColor2000"
        preferredRenderingType="wml11"
        preferredRenderingMime="text/vnd.wap.wml"
     </case>
</filter>

Ascertaining which properties will be set for a particular browser by the other filter elements can be difficult. Two simple pages can help to illustrate. The first (shown in Listing 4-3) displays just the HTTP headers sent by the device. This page gives you an idea of which headers you have available to identify the device and to set the characteristics correctly in the configuration.

Code Listing 4-3: DisplayingHeaders.aspx

 <%@ Page Inherits="System.Web.UI.MobileControls.MobilePage" %>
<script runat="server" language="c#">
protected void Page_Load(Object sender, EventArgs e) {
    NameValueCollection nvc = Request.Headers;
    string[] keys = nvc.AllKeys;
    for(int i = 0; i < keys.Length; i++) {
        string[] values = nvc.GetValues(keys[i]);
        System.Web.UI.MobileControls.Label lbl = new
            System.Web.UI.MobileControls.Label();
        lbl.Text = keys[i] + ":" ;
            for(int j = 0; j < values.Length; j++) {
                lbl.Text += " " + values[j]; 
            }
        form1.Controls.Add(lbl);
    }
}
</script>
<mobile:Form  runat="server" Paginate="true" >
</mobile:Form> 

Now that you have the headers available for the device, you can iterate through the capabilities being set for the browser. When you first configure a device, some of these settings will be incorrect, but by having the capability list, you can more easily identify the properties that will need to be set explicitly. This list also comes in handy when you need to find the filters that are incorrectly matching headers and setting properties for the browser. In the case of incorrect matching, you can add a specialization to the existing filter to correct the setting. Listing 4-4 writes out all the configured capabilities of the MobileCapabilities object for the requesting device.

Code Listing 4-4: ShowCapabilities.aspx

 <%@ Page Inherits="System.Web.UI.MobileControls.MobilePage"
    Language="cs" %>
<%@ Import Namespace="System.Reflection" %>
<%@ Import Namespace="System.Web.Mobile" %>
<script runat="server" language="c#">
protected void Page_Load(Object sender, EventArgs e) {
    MobileCapabilities capabilities = 
        (MobileCapabilities)Request.Browser;
    Type t = typeof(MobileCapabilities);
    PropertyInfo[] propertyInfos = t.GetProperties();
    foreach(PropertyInfo pi in propertyInfos) {
        System.Web.UI.MobileControls.Label lbl = new
            System.Web.UI.MobileControls.Label();
        lbl.Text = pi.Name + " = " + capabilities[pi.Name];
        form1.Controls.Add(lbl);
    }
}
</script>
<mobile:Form  runat="server" Paginate="true" >
</mobile:Form> 

Understanding the large quantity of filter and case elements within the browserCaps section is a somewhat daunting task at first, but as you configure more and more devices, you quickly become acquainted with the browserCaps section’s capabilities. The various groups of filter elements isolate particular settings such as those for the platform, or handle multiple device models from a single manufacturer. You will become proficient at manipulating browser configurations as you become more familiar with individual browser capabilities.