Developing for Mobile Browsers

More access to the Web is available with browsers in portable devices than ever before. Cell phones and personal digital assistants continue to offer improved screens and compelling features. However, many of these devices do not accept the markup that is usually rendered from Web pages. ASP.NET provides adaptive rendering so that a single Web page can produce WML, cHtml, HTML, and xHtml. In Chapter 4, we looked at how to use the mobile rendering features of ASP.NET to produce a site targeting the mobile user.

• You might encounter references to the Microsoft Mobile Internet Toolkit on the Web, in magazine articles, and in newsgroups. When version 1 of ASP.NET was released, mobile support was not included. Instead, support was available as part of a separate download called the Microsoft Mobile Internet Toolkit. This mobile support is now included as part of ASP.NET.

• Mobile pages should limit the amount of input required by the user. Strive for maximum relevant information with the fewest key clicks. Entering data can be tedious on a small form factor, and networks for mobile devices are still relatively slow compared to wired devices, so performing postbacks and following links can be somewhat time consuming.

• Use a desktop browser as a debugging aid when developing applications for mobile browsers because debug and tracing information is not included in the output from the MobilePage.

• Use cookieless sessions to ensure that your application works correctly on devices that do not support cookies.

• Device updates installed on ASP.NET 1 using the Mobile Internet Toolkit replace the browserCaps section in machine.config with new content. Customizations for the browserCaps section will be lost when installing Device Updates 1.

• When a browser isn’t recognized in the browserCaps configuration section, the default behavior is to treat it as an HTML 3.2 device without support for client-side scripting.

• The AllowCustomAttributes configuration setting does not cause custom attributes to be passed through to the client. It allows them only to be specified in the server page without causing an error on the server. This setting applies only to the mobile controls where unrecognized attributes on the server controls are treated as an error by default.

• Be careful when defining and using filters. There is a tendency to want to believe that one capability implies another. Although the capabilities of new devices continue to advance rapidly, it is best to explicitly check for support when customizing.