asp.net mobile Web forms and ASP.net compatibility

Asp.net|web

When writing asp.net mobile Web applications, you can use almost all of the features of ASP.net. However, you first need to consider compatibility issues.

Error handling and reporting
If the ASP.net application encounters an unhandled exception or other error while processing the request, an error page is generated. Exceptions may occur at any time during the request processing process. For example, they might occur when reading a configuration file (Web.config), compiling a page, or running a page.

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

Many mobile devices cannot render the details of the error page. These devices typically display only device-specific error messages or error codes. In this case, the ASP.net mobile Web Forms page attempts to format the error page so that it renders on the device. However, this device-specific rendering is limited to exceptions that occur when the page is run. Therefore, if you are using the default error page, you should first try the mobile Web Forms page from your desktop browser to detect potential configuration or compilation errors.

If you plan to use custom error pages in asp.net mobile Web applications, asp.net can format the error page appropriately for different mobile devices If you have written a custom error page using mobile controls.

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

Tracking
asp.net provides an easy-to-use feature called "Tracing" that you can use to debug Web applications. ASP.net provides two levels of tracing: page-level tracking and application-level tracking. Page-level tracking provides trace information in the form of HTML code attached to each tracked page, while application-level tracing provides trace information through a special mapping URL (Trace.axd) in the application.

If you use page-level tracing in a asp.net mobile Web application, attaching to the rendered HTML code may prevent the output from being rendered on the mobile device. For ASP.net mobile Web applications, you must use application-level tracing and check the trace output from your desktop Web browser.

For more information about ASP.net's tracking capabilities, see asp.net tracing.

Session state and Cookies
ASP.net provides rich session management capabilities that enable you to easily manage state across requests. Typically, the asp.net session state feature uses cookies on the browser, but it can also be configured to run without using cookies.

In asp.net, you can use sessions to save information about a user's session across multiple requests. Session Management in ASP.net is scalable and reliable, so you can even use that functionality across a Web farm. By default, ASP.net session uses a client Cookie to store identifiers on the client computer. You can use this identifier to find a session across the server round trip. In addition, the ASP.net session supports a Cookie-free conversation mode that initially redirects the client to a new URL that contains a session identifier. The session identifier is then automatically parsed from the URL.

When writing asp.net mobile Web applications, it is important to 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 a session without cookies.

For more information about ASP.net session management features, see Introduction to Web Forms State management and understanding of state management.

Considerations when working with session state
When writing a asp.net mobile Web application that uses session state management, you should consider the following factors:

Some mobile devices and gateways do not support cookies. To enable ASP.net mobile Web applications to run on these devices, the Web server must set session management to no Cookie mode.
Some mobile devices have problems processing relative URLs after redirection through technology that is used without Cookie session management.
For example, if you send an openwave.com browser to an. aspx file that is located in Http://localhost/a.aspx, and the Web site redirects the browser to/12345678/A.APSX, the browser still treats its current path as the root path. The browser will then request a relative reference to the b.aspx as a/b.aspx.

The workaround for this problem is to include a URL with a root path (such as/12345678/a.aspx) on the page, rather than a relative URL when rendering after redirection. The built-in ASP.net mobile control performs this task automatically, but any newly-written control or adapter must include code that processes the rendering after redirection. The MobilePage and adapter base classes have methods to help mobile control developers write URLs with root paths.

Using redirection
As a response to HTTP redirection, some devices and browsers currently require a fully qualified URL. Set up usefullyqualifiedredirecturl=true in the system.web section of the Machine.config file or Web.config file (application-level). For more detailed information, see Redirecting to a mobile WEB application.

Grammatical problems
Valid syntax (such as <%=) in asp.net is invalid in the ASP.net mobile control and must be replaced with a data-binding mechanism.

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

<%# Binding Expression code goes here%>