ASP.NET Mobile Web Forms and ASP.NET Compatibility
When you create your ASP.NET mobile Web Forms pages, 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 in ASP.NET Mobile Web Pages.
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 Tracing Overview.
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 ASP.NET State Management Overview.
Considerations When Using Session State
When writing an ASP.NET mobile Web application that uses session state management, consider the following factors:
Using ASP.NET controls in the System.Web.UI.WebControls namespace on a mobile Web Forms page is not supported. Mobile Web Forms pages that use mobile Web controls in the System.Web.UI.MobileControls namespace support setting the EnableSessionState attribute of the @ Page directive to false. However, mobile Web Forms pages that use an ASP.NET control from the System.Web.UI.WebControls namespace with EnableSessionState set to false might lead to a compile-time error.
Some mobile devices and gateways do not support cookies. To enable an ASP.NET mobile Web Forms page to run on these devices, set the cookieless attribute of the sessionState element to true.
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 an Openwave browser opens 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, such as MakePathAbsolute, 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 the useFullQualifiedRedirectUrl attribute of the httpRuntime element to 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 an ASP.NET Mobile Web Page.
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 %>
See Also
Reference
Concepts
Managing Adaptive Error Reporting in ASP.NET Mobile Web Pages
ASP.NET State Management Overview
Redirecting to an ASP.NET Mobile Web Page