Chapter 4: Developing for Mobile Browsers

A growing number of handheld and mobile devices come with built-in browsers. The disparity between the features of these browsers is far greater than it is among more full-featured desktop PC browsers. The most fundamental difference is that the various mobile browsers demand different kinds of markup. An HTML page that renders fine on a desktop browser won’t work at all on many mobile browsers, and the markup language used by one mobile browser might not work on another. In this chapter, we’ll look at writing Web applications for mobile browsers using Microsoft ASP.NET Mobile Controls and the MobilePage class. You’ll also examine how to leverage ASP.NET so that you can minimize what you need to learn about mobile browsers and deploy a mobile-enabled application successfully.

Tip

You might encounter references to the Microsoft Mobile Internet Toolkit on the Web, in magazine articles, and in newsgroups. When version 1.0 of ASP.NET was released, mobile support was not included. Instead, support was available as part of a separate download called the Microsoft Mobile Internet Toolkit. This mobile support is now included as part of ASP.NET.

Introducing Mobile Pages and Mobile Controls

Traditional Web development has us thinking in terms of the HTML tags we need to use. You probably have ideas about how your desired user interface (UI) can be realized using specific HTML markup, but in the world of mobile devices, this mindset won’t get you very far. Some browsers support the Wireless Markup Language (WML), which is part of the Wireless Application Protocol, also referred to as WAP. Other browsers support a subset of HTML specifically designed for mobile devices, called Compact HTML (cHTML). Compact HTML is particularly popular where wireless bandwidth infrastructure supports faster access to more data, such as in Japan. Some more sophisticated handheld devices have browsers that support HTML 3.2 but do not include client-side script support, whereas others have script support as well as some features of HTML 4.

The server controls architecture in ASP.NET moves us away from thinking directly in terms of HTML. It lets us more easily focus on the application logic and high-level user interface (UI) design because the controls render the HTML we need. ASP.NET mobile controls move the emphasis even further from being markup-specific, and guide the developer to think in terms of application functionality. The controls in the System.Web.UI.MobileControls namespace extend the system. Web.UI.MoblieControls.MobileControl class and add a new construct for rendering the different markup required by handheld devices and embedded browsers. Figure 4-1 shows how MobileControls and MobilePage extend the base Page and Control classes.

Figure 4-1: The extended Page and Control classes

The mobile controls do not actually handle the rendering of markup. Each MobileControl class has an associated set of adapters that renders the different kinds of markup. (The section titled “Selecting Page and Control Adapters,” later in this chapter, gives more detail about how an adapter is associated with a control during the page life cycle.) The control is responsible for the primary functionality, whereas the adapters manage the markup. The mobile control delegates the rendering as well as other page framework events to the adapter so that the adapter can effectively manage any unique requirements of the requesting device. This adaptive quality of MobilePage means that you can support a variety of browsers without necessarily learning the associated markup language. For example, to get calendar functionality in your application, you can place a Calendar MobileControl on a MobilePage. The mobile page gets the correct adapter for the requesting device. WML, cHTML, and HTML calendar adapters perform the rendering when the page is executed. Each calendar adapter produces markup targeting a specific language. Figure 4-2 shows how the adapters fit into the page life cycle.

Figure 4-2: The role of the adapter in the life of a mobile page

Other approaches to the problem of multiple markup languages have had limited success, in part because applications are still written with HTML. One such approach is to simply translate the HTML into the markup supported by the requesting device, but this presents the problem of what to do when the translation isn’t straightforward. A way to deal with this complication is to discard pieces of the original content—a solution that’s far from ideal.

ASP.NET mobile controls don’t attempt to translate one type of markup into another. Instead, the controls are themselves an abstraction for the functionality. You program against those controls and their object model, and the adapters emit the markup necessary for the requesting device.