ASP.NET Mobile Web Development Overview
Developing ASP.NET pages for mobile device browsers does not differ substantially from developing pages for desktop browsers. To help you create applications for mobile devices, ASP.NET provides a System.Web.Mobile namespace devoted specifically to mobile Web development.
You can create a Web page from the MobilePage base class and add controls from the System.Web.Mobile namespace. This namespace defines a suite of Web server controls and adapters that are especially useful when creating applications that need to be available to many different mobile devices, such as cell phones.
ASP.NET 2.0 also provides a control-adaptive architecture that allows custom device adapters to be created for ASP.NET 2.0 Web server controls. The adapters can create custom rendering for a control based on the requesting browser. With the adaptive architecture, you can create custom adapters for ASP.NET Web server controls to render output specific to the devices that access your application on desktop browsers.
Whether developing for desktop browsers or mobile devices, development follows the standard .NET event-driven model in which your application responds to user requests, button clicks, and so on.
Mobile Application Architecture
Although ASP.NET integrates technology to make ASP.NET mobile Web application development follow the same paradigm as traditional Web application development, the architecture's primary intent is not to allow you to create single pages that can target browsers in both desktop and mobile devices. The limitations of browsers on mobile devices often mean that pages designed for desktop browsers cannot translate to mobile device browsers.
For example, if you create an ASP.NET Web page that includes a site header, a navigation bar along the top of the page, a secondary navigation structure along the side of the page, and then content in the rest of the page, the page will render as designed in a desktop browser. In that case, there is usually ample space to render all the controls and still provide a scrollable content area. However, in many mobile device browsers, this layout would be impossible. Many mobile devices have a smaller screen area than desktop monitors, so even navigation becomes a multi-step process in which the user must click several controls to get to page content.
Presentation logic follows a similar pattern. For example, when the user fills in a Web form using a desktop browser, the user can see many controls on the screen at once. When the form is validated on the server, validation errors can be displayed next to the controls. With a mobile device, form input and validation can be much harder to display in a format that is usable. Additionally, for mobile devices you might choose to provide shortcuts that allow the user to fill in information with less typing because the device might be difficult to type on.
For these reasons, you must create separate pages in your ASP.NET Web application for use in desktop and mobile device browsers. A page developed specifically for mobile device browsers allows you to break down presentation logic into smaller pieces that work better for the device's display area and input hardware.
Mobile Web Server Controls
The ASP.NET 2.0 System.Web.Mobile namespace is devoted specifically to mobile Web development. You create a mobile Web page from the MobilePage base class and add mobile Web server controls from the System.Web.Mobile namespace. Mobile Web server controls have a number of specialized adapters in the .NET Framework and are therefore especially geared to developing mobile Web applications that target a wide range of mobile devices.
ASP.NET Web Server Controls and the Adapter Architecture
Most ASP.NET 2.0 Web server controls adhere to the unified adapter architecture. This means that all controls can behave differently depending on the requesting device by calling a custom adapter that provides appropriate behaviors for that device, such as creating the proper markup language. If an adapter is configured in the browser definitions file for the requesting device or browser, ASP.NET calls the adapter at each life-cycle stage of a Web server control. The adapter can then adjust rendered output for example, and handle any device-specific view state logic or device idiosyncrasies. Browser definition files can be found in the Browsers folder of the .NET Framework Config directory or in the App_Browsers folder of a Web application.
There are currently no adapters provided for the ASP.NET controls. There are, however, a rich set of adapters for the ASP.NET mobile controls to provide for a wide variety of devices and browsers.
You can create custom adapters for each device and have the ASP.NET page framework use those adapters when a specific device accesses your page. For more information, see Architectural Overview of Adaptive Control Behavior.
Choosing Custom Adapters or Mobile Controls
For pages targeting mobile devices, you must use mobile Web server controls and create pages that inherit from MobilePage. These controls support many mobile devices, such as cell phones. ASP.NET includes mobile Web server controls for a wide variety of general Web development and mobile-specific needs. Additionally, mobile-control device adapters already exist for major devices and their markup languages.
Microsoft will continue to provide adapter updates for the mobile Web server controls when major markup languages evolve. This enables you to support new markup languages with the same controls that you are already using. For example, if you are creating an e-commerce site that supports desktop browsers as well as a large array of mobile devices, you would create a set of ASP.NET pages that inherit from the Page class, and a separate set of pages that inherit from the MobilePage base class and use mobile controls.
If you need to, you can create your own custom adapters or modify existing ones where new devices dictate new behavioral requirements in mobile Web server controls.
There are scenarios where using ASP.NET Web server controls and writing custom adapters makes sense. These typically will be applications for rich desktop browsers where browser behavior variations are required, or for applications to be targeted by a constrained device class for which mobile controls and their feature set is not warranted. One example might be if you were creating an insurance-claim application that had a browser-based interface for office use and a rich-device interface for field use. Your application could then use the same base page classes for both the regular pages and the rich-device pages. You would then need to create custom adapters only for the device that was deployed in the field.