Making Mobile Browsers Work Better with ASP.NET

ASP.NET is architected with a robust scheme for adaptive page rendering. This scheme allows "server controls" or metamarkup to be rendered appropriately to various browsers, and becomes particularly important when using the mobile web controls.

For an overview of how this works, take a look at ASP.NET Web Server Controls and Browser Capabilities (from MSDN/Visual Studio '05 docs)

There are also numreous ways of overriding this framework, from code (Page.ClientTarget) to XML config files, to defining new browsers, or altering attributes of the browser configurations that ship with the framework.

Modification is critical for mobile web development, because the device data that ships with ASP.NET 2.0 doesn't include any of the wireless devices shipped in the past two years or so. (For a list of what is included, check out this list and walk down memory lane)

Since most users of mobile applications will be carrying a device built in the last 2 years the built-in browser profiles will not cover current customer devices. The good news is that the browsers in these newer devices are more advanced than the earlier browsers, and make a credible attempt to process xhtml and javascript. So less divergence from a "basic desktop browser" profile is needed to address these clients.

Here is what I did to handle some problems with newer Motorola and Nokia devices:

If the framework cannot come up with a positive match for the User Agent string to either an individual browser definition or a family of browsers, it is bound to the "default" profile and identified by the name "Unknown"

All major desktop browsers are correctly identified, whereas many (maybe most) late-model mobile browsers are not identified. So if the browser is identified as "Unknown", we'll assume it's a new mobile device.

The framework will render for a base desktop browser, which works pretty well. But certain postbacks cause a processing error which can be circumvented by altering the "default" profile and adding the attribute "requiresPostRedirectionHandling" right into the default definition. Rather than editing the files that ship with ASP.NET (which may be impossible in a shared hosting environment anyway), the preferred approach is:

1. Add the special "App_Browsers" folder to your ASP.NET 2.0 app
2. Add .browser file to that folder -- mine is called Supplement.browser
3. Add the attribute into an XML element that specifies this should modify the existing default definition. Here's how the whole file looks:

<browsers>
 <browser refID="Default">
  <capabilities>
   <capability name="requiresPostRedirectionHandling" value="true" />
  </capabilities>
 </browser>
</browsers>

The refID attribute refers to the Default definition that you can find in [WINDIR]\Microsoft.NET\Framework\[VERSION]\CONFIG\Browsers

For my application, this fix got my app running great on the MOTO RAZR devices, where I had experienced a number of problems before.

4. I also wanted to target newer Nokia phones. They have a family of browsers which are identified even when the individual phone model is not. So I added this element inside the 'browsers' tag to fix the Nokias:

<browser refID="Nokia">
 <capabilities>
  <capability name="cookies" value="true" />
  <capability name="preferredRenderingMime" value="application/xhtml+xml" />
  <capability name="preferredRenderingType" value="xhtml-basic" />
  <capability name="isColor" value="true" />
  <capability name="requiresPostRedirectionHandling" value="true" />
 </capabilities>   
</browser>

As you can see, I noticed that these devices are xhtml capable, but the Nokia default profile was sending them WAP content. I also pointed out to ASP.NET that these devices take cookies, are all color, and handle redirects differently from desktops.

I'm sure I'll find more issues and more fixes, but these have made a big difference once I figured them out.

Incidentally, save yourself a lot of pain and do not rely on either Motorola's ADK emulator or Cingular's online (ActiveX) emulators to test web content on these devices. Many difficult bugs appeared with these emulators, but on the actual devices, everything worked great. Nokia's emulator/SDK on the other hand was pretty solid and very helpful.