Control and Adapter Interaction
Two types of interaction occur during the life cycle of ASP.NET mobile controls and their associated adapters: the interaction between controls and device adapters, and the interaction between pages and page adapters.
Controls and Control Device Adapters
During a mobile control's life cycle, the following interactions occur between a control and its associated device adapter:
ASP.NET first checks whether there is a copy of the page in the cache. If one exists, the cached page is sent to the client. For more information about caching, see the "Output Caching" section of Mobile Text Writer Rendering Best Practices.
A control is created. On the first attempt to access the Adapter property of the control, a control adapter is selected and a new instance of it is created, as described in the "Understanding the Device Adapter Selection Process" section of Adapter Mappings.
The control device adapter's Control is set when the new adapter is created.
If the page is cached, the page calls the adapter to determine whether caching needs to be varied by any additional headers.
The control's private view state is loaded, if it exists. If the device adapters store any device-specific state for the control, the MobileControl base class implementation of the LoadPrivateViewState method calls the control device adapter's LoadAdapterState method.
If the control implements the IPostBackEventHandler interface and receives a postback event, the RaisePostBackEvent method of the control is called. If events sent to the control can vary depending on the target device, the control implementation of this method calls the HandlePostBackEvent method of the control device adapter. The HandlePostBackEvent method returns true or false, indicating whether the device adapter handled the event.
The control's private view state is saved, if applicable. The MobileControl base class implementation of the SavePrivateViewState method calls the control device adapter's SaveAdapterState method, in case the adapter needs to store any device-specific state for the control.
Pages and Page Adapters
Although the MobilePage class inherits from the .NET Framework Page class instead of the MobileControl class, the adapter-related behavior of the MobilePage class is very similar to that of the MobileControl class.
Mobile page adapters in ASP.NET, such as ChtmlPageAdapter, HtmlPageAdapter, WmlPageAdapter, or XhtmlPageAdapter, implement the IPageAdapter interface (which itself implements the IControlAdapter interface). Thus, much of the life cycle of a page adapter is similar to that of a control adapter. A mobile page and its device adapter interact specific to the Page class, and go through the following steps during their life cycle:
ASP.NET creates a page. When the first attempt is made to access the Adapter property of the page, a page adapter is chosen and an instance of it is created, as described in the "Understanding the Device Adapter Selection Process" section of Adapter Mappings. The page adapter's Page property is set when the adapter is created.
To determine the postback mode of a page, if applicable, the MobilePage base class calls the DeterminePostBackMode method of the page adapter. This method has the opportunity to inspect and modify request variables. This method is also responsible for translating any persisted view state information back into a form variable, if the information is not already in one.
The page's private view state is loaded, if applicable. The MobilePage base class calls the LoadAdapterState method of the page adapter, in case the adapter stores any device-specific view state for the page.
The page's private view state is saved, if applicable. The MobilePage base class calls the page adapter's SaveAdapterState method, in case the adapter needs to store any device-specific view state for the page.
The Render method of the page is called. The MobilePage base class implementation calls the Render method of the page adapter. At some point during rendering, the adapter is also responsible for accessing and writing the page's private view state, through the ClientViewState property of the page.