jscript editor
Web designer
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
You can create a Web page from the
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 create custom rendering for a control based on the requesting browser. With the adaptive architecture, you can use ASP.NET pages that inherit from the
In both cases, 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. You can create adapters for individual ASP.NET or for mobile Web server controls that allow these controls to render for both desktop and mobile device browsers, but the limitations of browsers on mobile devices often mean that pages designed for desktop browsers do not translate very well 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 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, it is recommended that you 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. When considering building such pages, therefore, you should use mobile Web server controls if your application must support a wide range of mobile devices, support browsers that do not use HTML, or support devices with limited display and input capabilities.
Mobile Web Server Controls
The ASP.NET 2.0 System.Web.Mobile namespace is devoted specifically to mobile Web development. You can 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 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 Unified Adapter Architecture
All ASP.NET 2.0 Web server controls adhere to the unified adapter architecture. This means that all controls can render and 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 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.
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.
Choosing Custom Adapters or Mobile Controls
For most page developers, using the mobile Web server controls and creating pages that inherit from MobilePage is the recommended approach to mobile development. 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 allows 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, the recommended approach is to 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. This provides you with mobile support without having to create custom adapters.
The mobile Web server controls also follow the unified adapter architecture, so 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.
A benefit of creating custom adapters for the ASP.NET Web server controls is therefore that you can use the Page base class for your Web pages and be able to take full advantage of the ASP.NET 2.0 feature set.
See Also
Other Resources
