When consumers began demanding access to Internet resources on devices other than their personal computers, system designers had tough choices to make. Their first instincts were to create multiple navigation paths through an existing Web site. This made sense because Web developers were already using this mechanism to deliver pages that would work on different versions of browsers that either supported or lacked support for HTML standards like frames. Although this was simple to implement, the number of pages on a Web site that had to be formatted different ways for different devices began to grow exponentially. Web developers had to find a better solution.
Enter XML and XSLT
XML and XSLT soon emerged as the most effective solution for multiple clients. Using XML and XSLT, a Web developer could create a Web site based on static XML documents or dynamic XML streams returned from a database. The designer could then create an XSL template that would take an incoming XML stream and transform the XML into HTML designed to work on a specific device or markup language that could be identified from a BrowseCaps entry. The developer would then design the Web systems to emit HTML to the client browser based on the transformation performed by the appropriate XSL template without worrying about multiple paths through the site.
This method of creating Web sites was very efficient from a resource standpoint because each page had only one XML file and each device type would have one XSL template that could process the XML file. However, it was somewhat less efficient from a processing standpoint because all the pages in a Web site were rendered dynamically instead of simply read from disk as a user navigated the site.
Unfortunately, the demand for XML and XSLT knowledge required of the designers and developers to implement this scheme was much larger than the supply of designers and developers who already had the requisite XML and XSLT knowledge and experience. The end result has been that not enough Web sites or Web applications have been developed to support mobile devices for the number of available mobile devices to consume them.
Using the MMIT
This is one of the problems that Microsoft has attempted to solve with the .NET Framework and the Microsoft Mobile Internet Toolkit (MMIT). From the beginning, Microsoft has promoted both Visual Studio .NET and the .NET Framework as the premier platform for developing both connected and disconnected applications for mobile devices. Although the tools to support the disconnected model are still in beta (i.e., the Compact Framework and the Smart Device Extensions), the MMIT, which supports creating connected applications, has been available for several months. It will also be included as a standard feature of the next release of Visual Studio .NET and the .NET Framework.
The MMIT allows developers to create Web applications that support mobile devices without requiring the device dependency imposed by the XSLT approach (where each device requires its own set of XSL templates). It does this by providing a set of device-independent controls and a set of device adapters, so the developer can write an application using the MMIT controls without regard for the specific device upon which his or her application will ultimately run. The MMIT places these device-specific controls on the Visual Studio .NET toolbox and even adds templates to the Create New Project dialog box to allow rapid mobile device development. Once the developer completes the application, it can be deployed on servers running the device adapters so the application can be served to multiple device endpoints.
When a connected mobile device requests a page developed using the MMIT controls, the ASP.NET runtime queries the device capabilities and assigns a device adapter to automatically translate the values returned through the controls to a format usable by the device. The device adapter not only handles the display but also generates the markup language code required for the device to manage and return input. For example, a developer can create a single page that will be rendered properly on either a Pocket PC or a cell phone using WAP. The device user responds using either the stylus on the Pocket PC or the keypad on the cell phone. The code generated by the device adapter returns a data stream that ASP.NET can consume and process.
Pros and cons of each approach
Of course, using the MMIT doesn’t obviate the old XML and XSLT methods. In fact, the native XML standards support built in to the .NET Framework makes it easier than ever to create Web applications that take advantage of this method for multiple device support. But for developing connected Web applications, you still may want to consider using the MMIT first.
Using the MMIT approach, you can design the device front end to an application one time and then as new devices become available, you can support them by simply adding additional device adapters to the ASP.NET server. You can also take the existing MMIT controls and extend them to create new control types supported by existing and future device adapters. The other key advantage to using the MMIT is that it can take advantage of the native ASP.NET state management system. Developers creating mobile applications based on XSLT must develop and maintain their own state management methods.