Mobile Web Development in Visual Studio 2005

Visual Studio 2005 Brings New Choices and New Capabilities

CoverStory

LANGUAGES: C# | VB.NET

ASP.NET VERSIONS: 2.0

 

Mobile Web Development in Visual Studio 2005

Visual Studio 2005 Brings New Choices and New Capabilities

 

By Andy Wigley

 

Visual Studio .NET 2003 supports development for mobile devices with the ASP.NET Mobile Controls server controls that have the unique capability of rendering different types of markup according to the type of mobile browser making the HTTP request. This allows the mobile Web developer to create a single ASP.NET Web site that renders successfully on HTML 3.2, HTML 4.01, Compact HTML (i-mode), WML 1.1, and XHMTL 1.1 browsers (including WAP 2.0). This technology has been used successfully on many mobile Web development projects.

 

If you create a new Web site in Visual Studio 2005, you ll find that on the New Web Site dialog box the ASP.NET Mobile Web site project type is no longer offered. So has support for mobile Web development been dropped in the new product?

 

Not at all! There are some differences to the way you build mobile Web sites as is clearly evident from the New Web Site dialog box but in fact, the functionality available to mobile Web developers has been increased.

 

In Visual Studio 2005, mobile Web developers have two distinct technology choices for building Web sites for mobile browsers:

  • You can continue to use the ASP.NET Mobile Controls to develop ASP.NET Web sites that render successfully to differing mobile browsers. You can also take advantage of ASP.NET 2.0 features such as Membership, Profiles, and Personalization though there are some implementation differences compared to a PC browser Web site. You are probably an ASP.NET developer building a mobile portal for wide public access; you should use the ASP.NET Mobile Controls if you don t know which mobile devices will access your Web site and you need to support a wide range of different devices and markup languages.
  • You can use the regular ASP.NET 2.0 server controls if you know your Web site will be accessed only by high-end mobile browsers such as Pocket Internet Explorer (Windows Mobile 2003 and later) or Opera Mobile. You can take advantage of advanced formatting, including CSS and all ASP.NET 2.0 features. There are a few ASP.NET 2.0 controls, such as the MultiView and View, that specifically support mobile Web development.

 

Use the regular ASP.NET 2.0 controls if you don t need to support lower-end devices. You are probably an enterprise developer where your IT department has approved a known set of high-end Smartphones or Pocket PC devices, or similar smart devices for use by company personnel. Figure 1 shows how Microsoft has released technologies for mobile Web development since the launch of .NET Framework 1.0.

 


Figure 1: Timeline for ASP.NET Mobile Web technologies.

 

Microsoft s Roadmap for Mobile Web Development with ASP.NET

Before we look at how you develop mobile Web sites with Visual Studio 2005, I must draw your attention to the Microsoft Roadmap for Mobile Web Development with ASP.NET, which you can find at http://www.asp.net/mobile/mobileroadmap.aspx?tabindex=6. This document, published in spring 2005, explains Microsoft s plans for mobile Web development and contains important information for existing and future mobile Web developers. To summarize the important points:

  • ASP.NET 2.0 includes the ASP.NET 1.x Mobile Controls. You can run existing ASP.NET 1.x Mobile Controls applications on an ASP.NET 2.0 Web server without any modification required.
  • The implementation of ASP.NET 1.X Mobile Controls in ASP.NET 2.0 includes the device adapter classes and device configuration compatible with Device Update 4. (For full details of which devices were supported by each device update, see http://www.asp.net/mobile/testeddevices.aspx?tabindex=6). However, Microsoft will not be releasing any more Device Updates. Instead, they have released tools to allow developers to create their own device configuration.
  • Regular ASP.NET 2.0 controls have a new architecture, modeled on that used by the ASP.NET 1.x Mobile Controls. This architecture separates the developer view of a control (how the developer programs the control in the ASP.NET page) from the rendering functionality (implemented in device adapter classes) which spits out the markup sent back to the requesting device. In effect, this means that all ASP.NET 2.0 controls could be extended to support different markup languages (be fully mobile-enabled ), although in the release version of ASP.NET 2.0, only XHTML 1.1 device adapters are shipped for the regular controls.

 

The second bullet point above deserves much more explanation. The ASP.NET 1.x Mobile Controls worked their chameleon-like magic by separating the design view of a control from the rendering duties. That way, a developer can build a single ASP.NET mobile page that will work with very different mobile browsers. The device adapter classes are responsible for writing the correct markup to the output stream that is sent back to the requesting devices. The architecture is completely extensible, so you could have as many different device adapter classes for each control class as you want the extreme position being to have a single device adapter for every different requesting browser. However, to go to that extreme would clearly be unmaintainable; so instead, the standard mobile controls have a device adapter class for each markup language (HTML, cHTML, WML1.1, and XHTML 1.1) that can further customize their output by reading XML configuration files that further describe the capabilities of each requesting device. Figure 2 shows how the control class and device adapter classes were configured, taking the example of the List control.

 


Figure 2: Control and device adapter classes.

 

A Device Update then, was a release from Microsoft of new XML configuration files describing the newer browsers that had come to market, and on rare occasions a new release of device adapter classes supporting a new markup language (Device Update 2 added device adapters to support XHTML browsers).

 

However, as the Roadmap document states, Microsoft will not be releasing any more Device Updates. The main reason is that, although Microsoft released Device Updates on a regular basis, they still didn t come out quickly enough for some users. A new device could be available on the market for some months before a new Device Update was released to provide the configuration files for the device. If you request an ASP.NET mobile Web site from a device browser that is not recognized by the configuration system, then the runtime simply sends back HTML 3.2. The device browser may or may not be able to render HTML 3.2, but even if the browser can render it, it s likely to provide sub-optimal presentation, with text misaligned and incorrect line wrapping. Correct device configuration is important for ensuring your mobile Web site renders correctly on the requesting device. Many users requested the ability to create their own device configuration for devices rather than wait for Microsoft to release a new update.

 

Instead of releasing Device Updates, Microsoft has released the configuration tools to allow you to develop your own device configuration files. What you have to do is point your desktop browser to http://www.asp.net/mobile/profile/default.aspx, register for the service, and then follow the instructions. After you register a new device, point your device browser at the URL listed in the instructions and run through a series of tests. At the end of the process you can download the device configuration file. At present, this file is an ASP.NET 1.x format .config file, but Microsoft will be releasing an update to this tool to create ASP.NET 2.0 .browser files instead (more on those later in this article).

 

Building ASP.NET Mobile Controls Apps in Visual Studio 2005

In a follow-up to this article in a future issue of asp.netPRO, I ll explain how to use the ASP.NET 2.0 Server Controls to target high-end mobile browsers those that can render XHTML 1.1 markup, such as Pocket Internet Explorer. However, if you want to target a broad range of browsers with differing capabilities, you ll need to use the ASP.NET Mobile Controls which I ll explain how to do in this article.

 

To get started, create a new Web site in Visual Studio 2005. Choose the Empty Web Site template in the New Web Site dialog box. One tip here: I m sure you ll be aware that Visual Studio 2005 supports development of IIS-hosted Web sites just as we re used to doing in Visual Studio .NET 2003, but that it also supports development of Web sites hosted by the file system that you access using the Visual Studio 2005 built-in development Web server. Hosting Web sites in the file system is great for developing many ASP.NET applications and allows many developers to avoid installing IIS on their development machines. Unfortunately for mobile Web developers, you can t really take advantage of this feature because the Visual Studio 2005 development Web server only supports connections from a browser running on the local machine and not remote connections (for security reasons). Inevitably, mobile Web developers test Web sites using browsers running on real devices that are connected to your LAN via WiFi or are synced to your desktop PC or on emulated devices running in virtual machines. These devices make remote connections to your development machine (even the Smartphone and Pocket PC emulators built into Visual Studio 2005), so the development server blocks the connections. Consequently, you ll need to ensure you have IIS installed on your development machine, and make sure you select HTTP as the Web site location when you create it (see Figure 3).

 


Figure 3: Make sure you select HTTP as the location for your new mobile Web site.

 

When Visual Studio 2005 has created the Web site, right-click on the project in Solution Explorer and use the Add New Item dialog box to add a Mobile Web Form and a Mobile Web Configuration File. Existing ASP.NET Mobile Controls developers will immediately feel on familiar ground! If you switch to the Design view on your Mobile Web Form, you ll see the familiar Mobile Web Designer from Visual Studio .NET 2003, and in the Toolbox all the Mobile Controls are listed in the Mobile Web Forms tray (Figure 4).

 


Figure 4: Mobile Web Designer and Mobile Web Controls in the Toolbox.

 

If you are new to developing applications with the ASP.NET Mobile Controls, unfortunately I don t have space to provide a primer here. The sample code for this article (available for download, see end of article for details) will give you a brief introduction, but to learn more, you can work through the Quickstart samples at http://samples.gotdotnet.com/mobilequickstart, or purchase my book Building ASP.NET Applications for Mobile Devices, published by Microsoft Press.

 

Design-time Data Binding

Whenever you start to play with a new technology, one of the first things you are likely to do is drag a database table onto a Form to try out the RAD data binding. Of course, you are not very likely to want to do this in a real production application, being a million miles away from building scaleable applications that implement good n-tier architecture, but it s a useful tool for building quick demo applications, or for giving flashy demonstrations at conferences.

 

If you try this with the application we ve just started to build, you ll run into problems. Make a connection in Server Explorer and drag a table onto your Web Form. If you do this with an ASP.NET 2.0 project, you get a GridView control in your Web Form bound to a SqlDataSource instance that connects to the database. In our Mobile Web form, you simply get an error dialog with the message Non-mobile controls are permitted only inside templates. Please delete this control or move it into a template. When you dismiss the dialog, it does carry on and insert the GridView and SqlDataSource, but there s no point in trying to continue with this, as the GridView can only render XHTML and so will be useless with many mobile browsers.

 

The workaround for this limitation and to still retain the RAD data binding is to add another New Item to your project, this time a DataSet. (When you do this, another dialog box pops up asking if you want to place the DataSet in the App_Code folder; reply Yes to this). After Visual Studio adds the DataSet to your project, the DataSet designer starts and asks you for a connection string and the SQL statement to select the data in which you are interested (the sample code for this article uses the Authors table from the SQL Server Pubs sample database). When the wizard completes, you have a strongly typed DataTable with a TableAdapter class to connect with the database. You can drag tables from Server Explorer onto the DataSet Designer to auto-generate TableAdapters and strongly-typed DataTable objects for any table in the database.

 

To display the data on the form, drag onto your Web Form a suitable control from the Mobile Web Forms tray in the toolbox, such as an ObjectList, then add code similar to that shown in Figure 5 to fill an instance of the DataSet with data from the database and to manually databind the control to the DataSet.

 

protected void Form1_Load(object sender, EventArgs e)

 {

   if (!this.IsPostBack)

   {

     PubsDataSetTableAdapters.authorsTableAdapter ta =

         new PubsDataSetTableAdapters.authorsTableAdapter();

     PubsDataSet.authorsDataTable dt =

         new PubsDataSet.authorsDataTable();

     ta.Fill(dt);

     ObjectList1.DataSource = dt;

     ObjectList1.LabelField = dt.au_lnameColumn.ColumnName;

     ObjectList1.DataBind();

   }

 }

Figure 5: Fill an instance of the DataSet with data from the database and manually databind the control to the DataSet.

 

As long as you have configured database security to allow read access to the account running your application (by default, ASPNET on IIS 5.1 on Windows XP or Network Authority on IS 6.0 on Windows Server 2003), this will display a list of author surnames as links that you can click to display the individual fields of the author s record.

 

Using ASP.NET 2.0 Features: Membership and Profiles

The RAD data binding restriction I ve just explained is the only place where it could be argued that Visual Studio 2005 offers reduced functionality over its predecessor. Any inconvenience from that is far outweighed by the ASP.NET 2.0 features that we can take advantage of, such as Membership and Personalization.

 

The Membership system makes it a breeze to implement Forms Authentication, something that required a great deal of work under ASP.NET 1.x. The ASP.NET 2.0 Membership system is highly configurable, although space constraints prevent me from going into detail here. However, if you want to enable Membership using the default configuration, simply open the ASP.NET Configuration tool from the Visual Studio 2005 Web site menu, go to the Security tab, click the Select Authentication Type link, then select From the Internet. This is sufficient to cause Visual Studio 2005 to configure a SQL Express database to store Membership data in the \App_Data folder of your Web site. You can then use the ASP.NET Configuration Tool to define user accounts. The final step is to configure access rules to deny access to your site to anonymous (unauthenticated) users and instead redirect them to your login form, called login.aspx by default. To do this, get to the Security tab in the Configuration tool, click Create Access Rules, and on the Access Rules page select Anonymous Users and Deny, then click OK.

 

The next step is to build the login.aspx page. If this was an ASP.NET 2.0 Web site, all you d need to do is to create a Web Form called login.aspx and drag the Login control from the Toolbox onto the Form. Unfortunately that won t work for mobile clients because the Login control and the rest of the controls in the Login tab of the Toolbox only render XHTML markup, and thus are useless with the diverse mobile clients we need to serve.

 

Instead, we must access the Membership APIs directly. First of all, add a new Mobile Web Form to the project called login.aspx. Then add controls to accept the username and password and a button to post back to the server, as shown in Figure 6.

 

<%@ Page Language="C#" AutoEventWireup="true"

 CodeFile="login.aspx.cs" Inherits="login" %>

<%@ Register TagPrefix="mobile"

 Namespace="System.Web.UI.MobileControls"

 Assembly="System.Web.Mobile" %>

 

   

     Runat="server">Username: 

   

     Runat="server">

   

     Runat="server">Password: 

   

     Runat="server">

   

     Runat="server">

   

     OnClick="Command1_Click">Login

 

Figure 6: Add controls to accept the username and password and a button to post back to the server.

 

In the Click event handler, call the Membership API to authenticate the user:

 

protected void Command1_Click(object sender, EventArgs e)

{

 if (Membership.ValidateUser(UserName.Text, Password.Text))

 {

   FormsAuthentication.RedirectFromLoginPage(

      UserName.Text, false);

 }

 else

 {

   ErrorMessage.Text = "Login failed. Please try again.";

 }

}

 

This simple example shows how easy it is to take advantage of ASP.NET 2.0 subsystems, such as the Membership system. You can also use the Personalization features of the Profiles feature and you can use Role Management. Unfortunately, you can t use all the new ASP.NET 2.0 features; Web Parts, Master Pages, and Themes are not supported in ASP.NET Mobile Controls projects.

 

Inside .browser Files: Handling Device Configuration

Before leaving the subject of ASP.NET Mobile Controls projects, I must return to the subject of Device Updates, as this is a big area of change for Mobile Web developers since Visual Studio .NET 2003.

 

I mentioned earlier that Microsoft won t be releasing any more Device Updates, that the responsibility for writing configuration files for new device browsers passes to the developer. This task is eased by using the Microsoft online profiling tool, available at http://www.asp.net/mobile/profile/default.aspx. You must register on this site, and after you login you can view a list of devices you ve already profiled, or click the Start Profiling a New Device link to start the configuration process for a new device (see Figure 7).

 


Figure 7: The ASP.NET profiling tool.

 

When you start profiling a new device, you must first select which markup language the browser requires: WML, HTML, XHTML, or desktop HTML. Then you are told to access a particular URL using the device browser. The pages you then run through on the device browser consist of a series of tests that are used to establish the precise characteristics of the browser. At the end, you can save the configuration for later download, as shown in Figure 7.

 

The download page provides instructions on how to use the configuration file on ASP.NET 1.0 and ASP.NET 1.1 Web servers, but does not at the time of this writing describe how to configure a device for ASP.NET 2.0. As stated in the Roadmap document, Microsoft plans to update this profiling tool to generate ASP.NET 2.0 .browser files; but until that happens, you must manually convert the .config file to a .browser file.

 

You can find the supplied .browser files in the \Windows\Microsoft.NET\ Framework\v2.0.50727\CONFIG\Browsers folder. If you view the contents of one of the .browser files, you ll see that modifying these is not for the faint hearted! If you need to support a new device, my advice is to wait for the updated Device Profiling tool if you can; but if you can t, study the files carefully to ensure that you make appropriate changes.

 

Frequently, a new mobile browser is simply a new version of an existing one, without substantial differences in its capabilities compared to its predecessor. If this is the case, you can take advantage of the inheritance capabilities of the .browser configuration system.

 

For example, the release version of ASP.NET 2.0 does not contain support for the Openwave SDK V7.0 simulator, but does support V6.0 and earlier. To support the V7.0 browser and inherit settings common to all Openwave SDK browsers, use a .browser file such as that shown in Figure 8.

 

 

 

   

     

        match="OPWV-SDK UP\.Browser/(?'majorVersion'[7-9]).*" />

   

   

   

   

     

         value="V${majorVersion}.x Mobile Browser" />

   

         value="true" />

   

         value="text/html" />

   

         value="xhtml-mp" />

   

         value="true" />

   

         value="Openwave ${majorVersion}.x Browser" />

   

 

Figure 8: Support the V7.0 browser and inherit settings common to all Openwave SDK browsers.

 

In Figure 8, the parentID attribute specifies the parent settings to inherit. The match attribute of the element specifies a regular expression used to match the User Agent HTTP header that every browser sends with each HTP request.

 

How do you work out whether ASP.NET 2.0 already supports your new device or not, and how do you discover the User Agent string for a browser? The easiest way is to write a simple WhoAmI and call it from your device (see Figure 9). If it returns a device type of Unknown , your device is not configured and will receive HTML 3.2 markup from your application without any formatting optimization. You should create a .browser file for it to ensure you get satisfactory results.

 

<%@ Page Inherits="System.Web.UI.MobileControls.MobilePage"

   Language="c#" %>

<%@ Register TagPrefix="mobile"

   Namespace="System.Web.UI.MobileControls"

   Assembly="System.Web.Mobile" %>

<%@ Import Namespace="System.Web.Mobile" %>

 

   

 

 

   

     

      ID="lblTitle">Browser Identification

     

     

     

     

     

     

     

     

     

   

 

Figure 9: Write a simple WhoAmI and call it from your device.

 

One word of warning: unlike ASP.NET 1.x, changes to files in the \Windows\Microsoft.NET\ Framework\v2.0.50727\CONFIG\Browsers folder are not detected dynamically. If you make any changes to files in that folder, you must recompile the browser definitions using the aspnet_regbrowser.exe utility in \Windows\Microsoft.NET\ Framework\v2.0.50727. This does not apply to .browser files you place in the \app_browsers folder of your Web site those are detected dynamically at run time, similar to ASP.NET 1.x.

 

Conclusion

In this article, I ve summarized Microsoft s Roadmap for Mobile Web Development with ASP.NET, showed how to create ASP.NET Mobile Controls applications in Visual Studio 2005, as well as how to take advantage of ASP.NET 2.0 features such as Membership, Profiles, and Roles. I ve also introduced you to .browser files, the new format for describing browser capabilities in ASP.NET 2.0.

 

In a follow-up article, I ll demonstrate how to use the ASP.NET 2.0 Server Controls to build Web sites targeting mobile browsers.

 

The sample code in this article is available for download.

 

Andy Wigley is the author of Building ASP.NET Applications for Mobile Devices and lead author of Microsoft .NET Compact Framework (Core Reference), both from Microsoft Press. He is an independent consultant who helps customers implement solutions using ASP.NET, the .NET Compact Framework, and .NET Framework 2.0, and is an MVP for the .NET Compact Framework. Contact him at mailto:[email protected]. Andy lives in the beautiful mountains of North Wales, UK and unwinds by walking and climbing in the hills, or by performing with his rock band, Rainbow Bridge. Look out for us in the pubs of Bangor or Caernarfon!

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish