ASP.NET Mobile Web Forms and ASP.NET Compatibility

Article
09/14/2006

When writing your ASP.NET mobile Web application, you can use nearly all the features of ASP.NET. However, first consider compatibility issues.

Error Handling and Reporting

When an ASP.NET application encounters an unhandled exception or other error while processing a request, it generates an error page. Exceptions can occur at any time during the processing of a request. For example, they might occur when reading a configuration file (Web.config), compiling a page, or running a page.

You can configure your application to generate default or custom error pages. If you configure your application for default error pages, ASP.NET sets an error code in the response and renders a page that describes the error in detail. However, if you configure your application for custom error pages, each error request is redirected to a custom page that you provide for it.

Many mobile devices cannot render the detailed contents of an error page. Instead, such devices usually show only a device-specific error message, or the error code. To address this situation, ASP.NET mobile Web Forms pages attempt to format the error page so that it renders on the device. However, this device-specific rendering is limited to exceptions that occur while running the page. Therefore, if you are using default error pages, you should first try your mobile Web Forms page from a desktop browser to detect potential configuration or compilation errors.

If you plan to use custom error pages in your ASP.NET mobile Web application, ASP.NET can format the error page appropriately for different mobile devices if you write your custom error pages using mobile controls.

For more information about error pages in ASP.NET, see the ErrorPage property documentation. For more information about error management, see Managing Adaptive Error Reporting.

Tracing

ASP.NET provides an easy-to-use functionality called tracing that you can use to debug your Web applications. ASP.NET provides two levels of tracing, page-level and application-level tracing. Page-level tracing provides trace information as HTML code that is appended to each traced page, whereas application-level tracing provides trace information through a special mapped URL (Trace.axd) in the application.

If you use page-level tracing in your ASP.NET mobile Web application, the HTML code appended to the rendering might prevent the output from being rendered on the mobile device. Instead, for ASP.NET mobile Web applications, you must use application-level tracing and inspect the trace output from a desktop Web browser.

For more information about tracing capabilities of ASP.NET, see ASP.NET Trace.

Session State and Cookies

ASP.NET provides rich session management features that allow you to easily maintain state across requests. Normally, the ASP.NET session state facility uses cookies on the browser, but it can be configured to work without cookies.

In ASP.NET, you can use the Session to save information about a user session across multiple requests. Session management in ASP.NET is scalable and robust so that you can use it even across Web farms. By default, the ASP.NET Session uses a client-side cookie to store an identifier on the client's computer. You can use the identifier to locate a session across server round trips. In addition, the ASP.NET Session supports a cookieless session mode that initially redirects a client to a new URL that contains a session's identifier. The session identifier is then automatically parsed out of the URL.

When writing an ASP.NET mobile Web application, you must keep in mind that some mobile devices and wireless gateways do not support cookies. To add support for these devices, you must configure your application to use cookieless sessions.

For more information about session management features of ASP.NET, see Introduction to Web Forms State Management and Understanding State Management.

Considerations When Using Session State

When writing an ASP.NET mobile Web application that uses session state management, consider the following factors:

Some mobile devices and gateways do not support cookies. To enable an ASP.NET mobile Web application to run on these devices, the Web server must have session management set to cookieless mode.
Some mobile devices have problems dealing with relative URLs after they have been redirected through the technique employed by cookieless session management.

For example, if you send an Openwave.com browser to an .aspx file at https://localhost/a.aspx, and the Web site redirects the browser to /12345678/a.apsx, the browser still considers its current path as the root. The browser will request a subsequent relative reference to b.aspx as /b.aspx.

The solution is to include a rooted URL on the page, such as /12345678/a.aspx, instead of a relative URL when rendering after a redirect. The built-in ASP.NET mobile controls automatically do this, but any newly written controls or adapters must include code that handles rendering after a redirect. Both the MobilePage and the adapter base classes have methods that help a mobile control developer write rooted URLs.

Using Redirects

Some devices and browsers currently require fully qualified URLs in response to an HTTP redirect. Set useFullyQualifiedRedirectUrl=true in the System.Web section of either the Machine.config file or Web.config file (at the application level). For more details, see Redirecting to a Mobile Web Application.

Syntax Issues

Syntax that is valid in ASP.NET, for example, <%=, is not valid in ASP.NET mobile controls, and must be replaced by data-binding mechanisms.

Data-binding expressions must be delimited by <%# and %>. The following is an example of the use of data-binding expressions.

<%# binding expression code goes here %>

For more details about activating and deactivating data binding, refer to Property Usage Guidelines.

Share via