Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

Whenever you use an emulator, you shouldn't assume that ASP.NET mobile controls have been configured to support it. There are two ways in which it can become apparent that support for the emulator isn't present:

The real device works, but an emulator of that device does not.

The emulator appears to work, but formatting problems are apparent with mobile pages.

The first of these problems is easier to identify and to fix. ASP.NET identifies browsers by examining the User Agent string the client sends in the HTTP headers with every request. Normally, an emulator returns the same User Agent string as the real device it is emulating, but this is not always true (particularly if the emulator has been produced by a different company from the manufacturer of the real device). If the emulator specifies an unrecognized User Agent string in the HTTP headers, the ASP.NET runtime classifies it as an "unknown" HTML 3.2 device. If the emulator expects to receive WML and instead gets HTML 3.2, the browser can't understand the markup it has received and displays an Unrecognized Content Type error. The next section, "Chapter 19. On rare occasions, ASP.NET might correctly identify the manufacturer of the device but not identify the specific model. As a result, the MobileCapabilities object that the ASP.NET runtime builds to identify the capabilities of the device is not optimized for that particular model, resulting in the ASP.NET mobile controls not rendering optimum markup for that particular browser. You might find that an ASP.NET Mobile Web application appears to work with the device's emulator, but you might later realize that pages aren't formatted correctly or that navigation buttons or softkeys don't work as expected. You might conclude incorrectly that your application isn't working for some reason; but the reason for the problem might just be that your device is getting only the basic level of support for a browser from that manufacturer.

This is a subtle problem that can be hard to identify. The Chapter 19.

Verifying Emulator Identification

If you encounter the situation in which your application works fine with a real device but doesn't work with an emulation of the same device, the reason is probably that the emulator is not sending the same User Agent string as the real device. For example, the ASP.NET mobile controls support the Ericsson R380 mobile phone. However, when you try to access a mobile ASP.NET application with the Ericsson R380 emulation in the Yospace Smartphone emulator, the runtime reports an error, saying that it can't display the page. Similarly, the Motorola Timeport emulation in the Yospace Smartphone emulator reports error 406 (Unrecognized Content Type). However, the emulations of the Nokia 7110 and 6210 phones work fine with this emulator.

The way that ASP.NET identifies these browsers at run time accounts for these discrepancies. If you're using .NET Framework 1.0, when you install the ASP.NET Mobile Controls, it updates the main configuration file, machine.config, which resides in the /WINDOWS/Microsoft.NET/Framework/v1.0.3705/CONFIG directory. If you're using .NET Framework 1.1, device configuration is found in the machine.config file, and might also be found in the file deviceupdate.config in the /WINDOWS/Microsoft.NET/Framework/v1.1.4322/CONFIG directory.

If you examine the machine.config file or deviceupdate.config file, you'll see that it contains browser identification logic within a section enclosed by the following tags:

<browserCaps> … </browserCaps>

ASP.NET identifies browsers by using regular expressions to match the HTTP_USER_AGENT string that the client browser sends with every request. Once ASP.NET identifies a browser, the runtime extracts all the values for its capabilities from the <browserCaps> element and uses them to initialize the MobileCapabilities object. In Chapter 9, we introduced you to the MobileCapabilities object and the way it defines the characteristics and capabilities of a mobile device. You define each of the properties that you can query through the MobileCapabilities object, including ScreenPixelsHeight, IsColor, and MobileDeviceModel, in the <browserCaps> section of the configuration file. For example, the section that identifies the Ericsson R380 mobile phone looks like this:

<!-- Ericsson -->
<case
match=
"R380 (?'browserMajorVersion'\w*)(?'browserMinorVersion'\.\w*) WAP 1\.1">
browser = "Ericsson"
type = "Ericsson R380"
version = ${browserMajorVersion}.${browserMinorVersion}
majorVersion = ${browserMajorVersion}
minorVersion = ${browserMinorVersion}
isMobileDevice = "true"
preferredRenderingType = "wml11"
preferredRenderingMIME = "text/vnd.wap.wml"
preferredImageMIME = "image/vnd.wap.wbmp"
inputType = "virtualKeyboard"
canInitiateVoiceCall = "true"
mobileDeviceManufacturer = "Ericsson"
mobileDeviceModel = "R380"
screenPixelsWidth = "310"
screenPixelsHeight = "100"
screenCharactersHeight = "7"
screenBitDepth = "1"
isColor = "false"
</case>

If the runtime can't match the HTTP_USER_AGENT string for a particular browser, the settings within the <default> device definition in <browserCaps> apply. These settings define the client browser as an HTML 3.2 browser, of browser type Unknown. The Yospace R380 emulator doesn't work because it sends a different HTTP_USER_AGENT string from the real device, and the regular expression used to identify an R380 model as defined in machine.config doesn't recognize it. Consequently, ASP.NET defines the device as an HTML 3.2 device and formats the page in HTML. The WAP browser can't render HTML, which explains the error message that appears when you access the application through this emulator.

You can easily verify whether there is a device identification problem using the trace output you learned about earlier in this chapter, in the section "Using the ASP.NET Trace Facility." The WhoAmI application, shown in Listing 16-6, simply outputs a few of the properties defined in the MobileCapabilities object to mobile Label controls, including the MobileCapabilities.Browser property, which it also writes to the trace log. More important, the runtime configures the Web.config file for application-level tracing, as Listing 16-7 shows.

Listing 16-6: Default.aspx mobile Web Forms page of the WhoAmI application

<%@ 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" %>
<head>   
<script language="c#" runat="server">
void Page_Load(object sender, System.EventArgs e)
{
MobileCapabilities cap=((MobileCapabilities)Request.Browser);
lblBrowser.Text = "Browser: " + cap.Browser;
lblManu.Text = "Manufacturer: "+ cap.MobileDeviceManufacturer;
lblModel.Text = "Model: " + cap.MobileDeviceModel;
lblContent.Text = "Content: " + cap.PreferredRenderingType;
lblHeight.Text = "PxlsHeight: " + cap.ScreenPixelsHeight;
lblWidth.Text = "PxlsWidth: " + cap.ScreenPixelsWidth;
// Output MobileCapabilities. Browser property to Trace.
Trace.Write("Browser: " + cap.Browser);
}
</script> 
</head>
<body>   
<mobile:Form runat="server" id="frmMain">
<mobile:Label runat="server" StyleReference="title">
ASP.NET Mobile Controls Client Identification</mobile:Label>
<mobile:Label runat="server" id="lblBrowser"/> 
<mobile:Label runat="server" id="lblManu"/> 
<mobile:Label runat="server" id="lblModel"/> 
<mobile:Label runat="server" id="lblContent"/> 
<mobile:Label runat="server" id="lblHeight"/> 
<mobile:Label runat="server" id="lblWidth"/> 
</mobile:Form>
</body>

Listing 16-7: Application-level tracing in the Web.config file of the WhoAmI application

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<!--  APPLICATION-LEVEL TRACING -->
<trace enabled="true" />
</system.web>
</configuration>

If you run this application on a supported device, it displays the values of some of the properties of the MobileCapabilities object, as shown in Figure 16-9 for the Openwave 6.1 browser. However, if you try to access http://localhost/whoami from the Yospace R380 emulator, the application fails to display the output for the reasons just described.

Figure 16-9: WhoAmI application displaying ASP.NET device capabilities settings for this device

If you then use Internet Explorer to access the application-level trace file at http://localhost/whoami/trace.axd and select the most recent trace, you'll see that the MobileCapabilities.Browser property is set to Unknown, as shown in the Trace Information section. You'll also notice that, in the Headers Collection section of the trace, the HTTP_USER_AGENT string for the Yospace R380 emulation appears as Ericsson R380 version 0.0 (compatible; Yospace SmartPhone Emulator Developer Edition 2.0). Figure 16-10 shows this trace output.

Figure 16-10: Trace output showing the HTTP headers sent by the client browser

Here we see the root of the problem! The existing code in <browserCaps> that identifies the R380 model looks for an HTTP_USER_AGENT string that matches R380 majorVersion.minorVersion WAP 1.1, while the Yospace emulator actually identifies itself as Ericsson R380 version 0.0 (compatible; Yospace SmartPhone Emulator Developer Edition 2.0).

To make this change, create or edit your application's Web.config file and write the tags for a <browserCaps> section in a similar way to that in the device configuration file in the /WINDOWS/Microsoft.NET/Framework/

version /CONFIG directory. Remember to include the <use var="HTTP_USER_AGENT" /> and <filter> tags to enable browser matching. The basic structure of the code you need is shown here:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.web>   
<browserCaps>
<use
var="HTTP_USER_AGENT" />
<filter>
<!--  Insert your own browser definitions here. -->
</filter>
</browserCaps>
</system.web>
</configuration>

Locate the section that identifies the R380 model in the device configuration file, copy it, and paste it into the Web.config file you're writing. Modify the matching string used in the regular expression as shown in boldface type in the following example:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<!--
BEGIN Browser support for Yospace emulations
-->
<browserCaps>            
<use
var="HTTP_USER_AGENT" />
<filter>
<!-- YOSPACE Emulations -->
<case match=".*YOSPACE.*">
<filter>
<!-- Ericsson -->
<case
match=
"Ericsson R380 v(?'browserMajorVer'\w*)(?'browserMinorVer'\.\w*) .*" >
browser = "Ericsson"
type = "Ericsson R380"
version = 
${browserMajorVer}.${browserMinorVer}
majorVersion = ${browserMajorVer}
minorVersion = ${browserMinorVer}
preferredRenderingType = "wml11"
preferredRenderingMime = "text/vnd.wap.wml"
preferredImageMime = "image/vnd.wap.wbmp"
inputType = "virtualKeyboard"
canInitiateVoiceCall = "true"
mobileDeviceManufacturer = "Ericsson"
mobileDeviceModel = "R380"
screenPixelsWidth = "310"
screenPixelsHeight = "100"
screenCharactersHeight = "7"
screenBitDepth = "1"
isColor = "false"
maximumRenderedPageSize = "3000"
</case>
</filter>
</case> <!-- End YOSPACE emulations -->
</filter>
</browserCaps>        
</system.web>
</configuration>

This match will work with the Yospace HTTP_USER_AGENT string and set the device up as an R380. You can then save this new Web.config file in your /Inetpub/wwwroot directory, where it will apply to all applications on that server, or you can save the file in the application root directory, where it will apply only to that application. You could even just add this new browser definition to the <browserCaps> section in the deviceupdate.config file (.NET Framework 1.1) or machine.config file (.NET Framework 1.0) alongside the existing definitions supplied by Microsoft.

Remember that if you install a new Device Update issued by Microsoft in the future, the <browserCaps> section in deviceupdate.config or machine.config will be updated to include settings for newly supported devices. Browser definitions in a Web.config file in the wwwroot directory or in the application root directory override any settings for the same browser in machine.config (if any exist). Whenever you install a new Device Update, you should review any custom browser definitions you've implemented because official support for the affected browsers might be included in the device update, in which case you should remove the corresponding custom definition.

With this modification in place, the Mobile Internet Controls Runtime will recognize the Yospace emulation as an R380 and correctly format the response in WML 1.1.

Integrating an Emulator into Visual Studio .NET

You can run some software emulators from the command line, specifying the URL to fetch as a command-line parameter. An example is the Openwave simulator. You can integrate an emulator with this capability into the Visual Studio .NET IDE to make your testing easier. To do so, follow these steps:

Open any ASP.NET project, and right-click any .aspx file in Solution Explorer. Click Browse With on the context menu.

In the Browse With window, click the Add button.

In the Add Program window, browse to the file location of the emulator executable, and click Open. After the file location, add any command-line parameters the emulator requires. Visual Studio .NET automatically sends the URL of the page you are testing as the first command-line parameter, but you can use the %URL variable to insert the location of the starting page elsewhere in the command-line parameters. The Openwave simulator in the SDK 4.1.1 requires the command-line parameters –reload %URL, whereas the simulator in SDK 5.0 and later needs only the URL. For example, to use the WML 1.2 simulator from the Openwave SDK 4.1.1, in the file location, type "C:\Program Files\Openwave\UPSDK411 \upsim411.exe" -reload %URL. (Note carefully the position of the quotation marks.) To use the XHTML-MP browser in the simulator from the Openwave SDK 6.1, in the file location, type C:\Program Files\Openwave\SDK 6.1\program\http \OSDK61http.exe. (Here quotation marks are not needed.)

Type a friendly name for the browser, such as Openwave SDK 4.1.1 simulator, to add to the list of browsers available through the Browse With window.

Click the OK button to accept your changes. If Visual Studio .NET displays the error message File name does not exist, is invalid, or contains parameters that cannot be validated. Do you want to change your entry?, click No.

If you want, you can make this the default browser for the Browse option by selecting the newly added emulator in the list and clicking Set As Default.

You must change a project property to enable your Web application projects to use a browser other than Internet Explorer when you run them for debugging. To change this property, follow these steps:

Right-click the project name in Solution Explorer, and click Properties on the context menu.

Click the Configuration Properties folder in the tree on the left to expand it. Then click the Debugging suboption.

For Visual Basic projects, clear the Always Use Internet Explorer When Debugging Web Pages check box. In a C# project, set the Always Use Internet Explorer option to false. Click OK.

Visual Studio .NET will now use the browser specified as the default in the Browse With window for debugging for all projects.

Alternatively, you can specify debugging with a particular emulator just in a specific project by modifying the project properties as follows:

Open the project properties and set the Always Use Internet Explorer to True so that other projects debug using Internet Explorer as usual.

Set the Debug Mode property to Program.

Set the Start Application property to the full path of the Openwave SDK 4.1.1 executable. If you installed the 4.1.1 SDK in the default location, the path name is: C:\Program Files\Openwave\UPSDK411\upsim411.exe.

Set the Command Line Arguments property to -reload, followed by the absolute URL of the start page of your application—for example, http://localhost/MobileWebApplication1/MobileWebForm1.aspx. You need the URL only and not the –reload command-line parameter if you're using Openwave SDK 5.0 or later.

Click the OK button to accept your changes.

Visual Studio .NET will now use the Openwave browser for debugging in this project but will still use Internet Explorer for other projects.