Types of Adapters
To support multiple devices, the ASP.NET mobile Web page architecture is built on a device adapter model. A mobile Web page and an ASP.NET mobile control are themselves device-independent, but a set of appropriately chosen device adapters provides a device-specific presentation layer for mobile pages and controls.
Device adapters are associated with combinations of individual controls and target devices. For any given device, each mobile control class can have a unique control adapter class associated with it, and each instance of a control is bound to a corresponding instance of an adapter.
For each type of device, you can define the following classes:
Control adapter base class. The base class that all device adapters inherit from.
Page adapter. The adapter associated with the page.
Form adapter. The control adapter associated with each form on the page.
Control adapters. The control adapter classes that correspond to controls in the system.
Text writer. A class that inherits from the HtmlTextWriter class, and that contains target-specific helper methods.
As a rule, if some functionality requires the context of a control, you might want to consider placing it in the control adapter base class.
The following table lists the types of adapters along with some examples of device-specific implementation classes for each adapter.
Adapter and Class type |
ASP.NET Mobile Control Class |
Description |
---|---|---|
Control adapter base class |
All device adapters inherit from this base class. |
|
Page adapter |
A control adapter associated with the page. |
|
Form adapter |
A control adapter associated with each form on the page. |
|
Control adapter |
Control adapter classes that correspond to controls in the system. |
|
Text writer |
A class that inherits from HtmlTextWriter, and that contains target-specific helper methods. |
Every set of device adapters generally includes a base class for all adapters in the set. The ControlAdapter base class provides commonly used functionality specific to the device class. Typically, this consists of helper methods that require control or page context. These helper methods include:
Methods for rendering control postback events.
Methods that render style properties of the control. Style properties are handled differently for each device, so each adapter has a different implementation for style rendering.
Overridable methods that provide device-specific information to the ASP.NET page framework, or to adapters of the containing page or form.
Convenient properties to access adapters of the containing page or form.
It is recommended that the control adapter base class that you provide also inherit from the ControlAdapter class, which is a general base class. This class provides a default implementation of the IControlAdapter interface that is required for all adapters. It is recommended that the default rendering implementation of the base class render all child controls. This enables you to use the base class as an adapter for composite controls.
Every set of device adapters has a page adapter class that is associated with the mobile page itself. Each instance of a mobile page, or each page class inherited from a MobilePage object, is bound to a page adapter specific to the target device. A page adapter usually contains the following:
Device-specific postback and view-state functionality.
Methods that save and load device-specific control state, such as pagination information.
Initialization code that prepares the response returned to the client. This includes setting the MIME type of the response to the appropriate format.
A Render method that renders the skeleton of the page returned to the client. For example, HTML-based page adapters typically render at least the <html> opening and closing tags.
Other device-specific page-level features, such as assembling a page adapter for a device that supports the capability to return multiple pages in a single response.
A page adapter class must provide a full implementation of the IPageAdapter interface. Typically, the page adapter class that you write must also inherit from the appropriate control adapter class. For example, if you were writing solely for a WML-based device, you would want to inherit from the WmlControlAdapter class. For more information about the adapter classes, see Device Adapter Code.
Every set of device adapters also has a form adapter class that is associated with the Form class. Each instance of a form is bound to a form adapter that is specific to the target device. A form adapter usually contains the following:
Methods that handle device-specific form interactivity.
Methods that handle adaptation of a single form to different devices. This might include code to paginate a form or to combine form elements into a menu.
A Render method that renders the skeleton of the form. For example, WML-based page adapters typically render at least the <card> opening and closing tags.
The text writer class is not an adapter class, but rather a class that inherits from the System.Web.UI.HtmlTextWriter class. An instance of the text writer class is created and passed through every adapter for rendering purposes — all rendering is performed through this object. The text writer usually contains helper methods to perform tasks such as encoding data.