Programming for Different Types of Devices

The main issue with trying to write pages that target multiple devices lies in knowing exactly what each device expects to receive. For example, most mobile phones expect the content to be Wireless Markup Language (WML), of which there are several versions in current use. The devices connect to the Internet through a telecom provider's WAP gateway, which takes the output from a Web site and compiles it into a special format to deliver over what is currently a very narrow bandwidth connection to the device. Then it does the converse with the page requests and any posted content from the client, converting that back into standard HTTP format to send to the server.

However, there are several versions of this gateway software in use with different telecom providers, and each version may treat the content slightly differently during the compilation and decompilation processes. Add to this the huge number of different phones and devices currently available (which support different versions or different implementations of WML or other languages such as cHTML) and it soon becomes a real challenge to decide what output to send to each client.

The Microsoft Mobile Internet Toolkit

The MMIT went a long way toward solving these issues by including support for a large number of popular devices. You use the special controls that are part of the MMIT to build a page, and these controls interact with the page framework to detect the device type (and in some cases the gateway) and generate content that will produce the correct output in the current device. At the last count, over 200 device combinations were documented.

To understand what has changed in version 2.0 of the .NET Framework with respect to mobile devices, it's useful to see how the MMIT was designed. One way to change the output generated by a control is to hard-code within it the equivalent of one (or more) huge case statements. However, this is prone to errors and difficult to implement successfully, and it makes updating the control as new devices appear extremely cumbersome.

Device Adapters

Instead, the MMIT uses device adapters to generate the output. A set of device adapters (one for each markup language) is available, and all the controls can use these device adapters to generate output suitable for a particular device. The device adapter overrides some of the events in the life cycle of the control, in particular the Render event.

This allows the device adapter to generate the appropriate output when the page recursively calls the Render method of each control and its child controls. It means that the control doesn't have to worry about the output format, while the device adapter doesn't have to know what the control actually does.

Device adapters may also have to override other events to ensure that the device is properly supported. For example, they may have to carry out specific actions for the load or save events for the viewstate of the page. (Many mobile devices require special handling of the viewstate because limitations in the total size of the posted values prevent it from being stored in a hidden control within the page.) They may also have to handle special situations for a postback, including issues where redirection to another page is handled differently in mobile devices.

And now Microsoft has moved all the ASP.NET server controls to a new unified control and adapter architecture. This was part of the original intentions for ASP.NET, but it was not fully developed in time to be implemented in version 1.0.