Team LiB
Previous Section Next Section

Chapter 12: Going Mobile

The changes that come with ASP.NET 2.0 will affect mobile controls as well. But that's what we developers are used to. No support for mobile devices existed in the first version. Then the Microsoft Mobile Internet Toolkit (MMIT) was introduced. With version 1.1, the MMIT was directly integrated in the framework under the name ASP.NET Mobile Controls.

In version 2.0, the mobile controls with the corresponding System.Web.Mobile namespace are still available, but only for compatibility reasons. It shouldn't be used any more for new web sites.

Mobile Development ASP.NET 2.0 Style

The new ASP.NET version offers a completely new concept for the development of mobile web sites. Instead of using special mobile controls as you've had to do up to now, you'll work with already known controls such as Label, TextBox, Button, and so on—the same as if you were developing a web site for regular desktop browsers. Depending on the device used, the controls are delivered in the required format, regardless of whether you're using (X)HTML, WML, or CHTML (short for Compact HTML, which is used with i-mode in Japan). Just forget about the separate <mobile:...> controls!

Instead of rendering their content individually, the controls utilize a set of adapter classes that have been assigned to them during configuration. This new concept is called adaptive rendering. Many adapters are already included with ASP.NET for all the standard controls.

Due to the separation of control and adapter, support for new or individual target devices can be added without any problems. You can even modify the output of a control to serve different purposes without changing the control itself.

Adaptive Rendering in Action

Just access any page in different devices or emulators to see adaptive rendering in action. I've created the page in Listing 12-1 as a test. It consists of a simple input form, Button control, and Label control.

Listing 12-1: Creating Mobile Pages Using the Regular Web Controls
Start example
<%@ page language="C#" %>

<script runat="server">

void BT_Submit_Click(object sender, System.EventArgs e)
{
    this.LT_Name.Text = string.Format("Your name is: {0}", this.TB_Name.Text);
}

</script>

<html>
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form runat="server">
        <p>Please enter your name:
            <br /><br />
            <asp:textbox id="TB_Name" runat="server"/>
            <asp:button id="BT_Submit" runat="server"
                text="OK"
                onclick="BT_Submit_Click" />
        </p>
        <p><asp:literal id="LT_Name" runat="server"/></p>
    </form>
</body>
</html>
End example

The result isn't really exciting, though. Much more exciting is the fact that you can access the page through completely different browsers without any changes. Figures 12-1 through 12-3 show the example page in the regular desktop Internet Explorer, the Internet Explorer for Pocket PCs, and the Openwave WAP Emulator.

Click To expand
Figure 12-1: The same page in Internet Explorer ...
Click To expand
Figure 12-2: ... in Internet Explorer for Pocket PC ...
Click To expand
Figure 12-3: ... and in Openwave WAP Emulator. (Image courtesy Openwave Systems Inc.)
Tip 

Check out the Mobile area on the www.asp.net web site if you want to get a good overview of emulators. The Pocket PC Emulator is included with the Microsoft Pocket PC 2003 SDK. This SDK requires Microsoft eMbedded Visual C++ 4.0, including Service Pack 2. All of the three setups are shipped as a part of MSDN Subscription or can be downloaded (at a total of more than 400MB) from the Microsoft web site.

One UI for Different Devices?

When faced these new possibilities, one urgent question comes to mind: Will it be sufficient in the future to develop only one UI for all devices? The answer is absolutely clear: No! In 90% or more of all cases you'll still need a UI for regular desktop browsers and one for mobile devices. A unique surface doesn't make sense because the differences are just too big.

However, you can now use the same controls and the identical programming model without any problems. Maybe you can even port some parts of the UI more easily.

Device Filter

Another option that the new controls offer is the so-called Device Filter. You can use it to assign properties in a declarative way for different target devices. For this purpose, you just have to assign the unique ID of the device in front of the parameter name. The ID is defined by the configuration. This may look as follows:

<asp:image imageurl="foo.jpg" netscape:imageurl="foomozzila.jpg" />

This approach works for any properties as well as for attributes and templates. The filter can even be used on many attributes offered by the @Page and @Control directives.

Browser Configuration

By including the new adaptive rendering feature, the configuration possibilities have become remarkably more numerous. Also, administrators have access to any of these settings so that they can quickly make changes and enhancements. Until recently, configuration was integrated in the machine.config file. From now on it will be placed in a separate directory:

<windir>\Microsoft.NET\Framework\<version>\CONFIG\Browsers

In this directory, you'll find a separate file for each browser type with the extension .browser that contains the necessary settings.

The configuration for the emulator of Openwave used earlier is stored in the openwave.browser file and partially looks as shown in Listing 12-2. The assigned unique ID is marked in bold.

Listing 12-2: The Browser Configuration File Used to Assign the Adaptive Rendering Class
Start example
<browsers>
    <!-- sample UA "UP.Browser/3.1.03-DS13 UP.Link/5.0.2.7" -->
    <browser id="up" parentID="default">
        <identification>
        <userAgent match="(UP\.Browser)|(UP/)" />
        <userAgent nonMatch="Go\.Web" />
    </identification>

    <capture>
        <userAgent match="..." />
    </capture>

    <capabilities>
        <capability name="browser" value="Phone.com" />
        <capability name="canInitiateVoiceCall" value="true" />
        ...
    </capabilities>

    <controlAdapters markupTextWriterType="System.Web.UI.WmlTextWriter">
        <adapter controlType="System.Web.UI.Page"
                 adapterType="System.Web.UI.Adapters.WmlPageAdapter" />

        <adapter controlType="System.Web.UI.DataBoundLiteralControl"
                 adapterType="System.Web.UI.Adapters.
                 WmlDataBoundLiteralControlAdapter"/>

        ...
    </browser>
</browsers>
End example

Team LiB
Previous Section Next Section