Controlling View State

Article
09/14/2006

Microsoft ASP.NET Web Forms pages are capable of maintaining their own state across multiple client round trips. When a property is set for a control, the ASP.NET saves the property value as part of the control's state. To the application, this makes it appear that the page's lifetime spans multiple client requests. This page-level state is known as the view state of the page.

On ordinary Web Forms pages, their view state is sent by the server as a hidden variable in a form, as part of every response to the client, and is returned to the server by the client as part of a postback. However, to reduce bandwidth demand when using mobile controls, ASP.NET does not send a page's view state to the client. Instead, the view state is saved as part of a user's session on the server. Where there is a view state, a hidden field that identifies this page's view state is sent by the server as part of every response to the client, and is returned to the server by the client as part of the next request.

Managing View State History

Because the view state for a given page must be kept on the server, it is possible for the current state to be out of synchronization with the current page of the browser, if the user uses the Back feature on the browser to go back in the history.

For example, suppose the user goes to Page 1, then clicks a button to go to Page 2, then presses Back to return to Page 1. The current page on the browser is now Page 1, but the current state on the server is that of Page 2.

To alleviate this problem, ASP.NET mobile Web Forms maintains a history of view state information in the user's session. Each identifier sent to the client corresponds to a position in this history. In the previous example, if the user again posts from Page 1, mobile Web Forms uses the identifier saved with Page 1 to synchronize the history.

The size of this history is configurable by the developer, and must be tuned to the application. The default size is 6, and can be changed by adding a numeric attribute to a tag in the Web.config file, as shown in the following example.

<configuration>
   <system.web>
      <mobileControls sessionStateHistorySize="10" />
   </system.web>
</configuration>

Dealing with Expired Sessions

Because view state is saved in the user's session, it is possible for view state to expire if a page is not posted back within the session expiration time. This expiration is unique to mobile Web Forms pages. When the user posts back a page for which there is no view state available, the OnViewStateExpire method of the page is called. The default implementation of this method throws an exception indicating that the view state has expired. However, if an application is able to restore view state manually after expiration, it can override this method at the page level and choose not to call the base implementation.

Enabling and Disabling View State

The advantage of ASP.NET using the session to manage the view state is shorter response sizes. The disadvantage is that inefficient use of the session state can lead to poorer performance. When developers use controls with large amounts of data, they can use techniques, such as custom paging or disabling view state, to improve efficiency. For example, consider a site that shows news stories. Instead of saving article content on a per-user basis in the session, such a site can use smarter data access so that only one copy of each article is cached on the server, and session state usage is minimized.

To disable the view state for a control and its children, set the EnableViewState property of the control to false. To disable the view state for an entire page, add an EnableViewState="false" attribute to the @ Page directive.

Even when view state is disabled, some mobile controls save essential state information across client round trips. An example of such information includes the currently active form on a page. When you turn off view state, the page saves this essential information as a hidden form variable that is sent on a round trip to the client.

Managing Cookies and Client State

By default, the session management features of ASP.NET require the server to write out a session cookie to a client. The client subsequently submits the cookie on each request during the session, and the server looks up the session state from this information. Many mobile devices, however, do not support cookies. For session management, including view state, to work correctly on these devices, you must configure the application to use cookieless session management. With this feature enabled, ASP.NET automatically inserts the session key in application URLs.

Some devices do not support cookies. To persist long-term client state, an application can use a pre-entered customer number. Because you cannot rely on a client having cookies, your application must take you to an alternate page that can be bookmarked. The following sample shows an example of such a site. Users that browse to this URL view a form where they enter their customer IDs. The application then displays an alternate URL, which users can bookmark.

<%@ Page Inherits="System.Web.UI.MobileControls.MobilePage" Language="C#"
   EnableViewState="false" %>

<script runat="server" language="c#">

protected void Page_Load(Object sender, EventArgs e)
{
   String customerID = Request.QueryString["cid"];

   if (customerID != null)
   {
      // A customer ID was found. Here, you would normally look
      // up the customer's profile in a database. 
      // This code simulates such a lookup by converting the client ID
      // back to a user.

      int underscore = customerID.IndexOf('_');

      if (underscore != -1)
      {
         // If visiting the first time, prompt the user to bookmark.

         if (Session["FirstTime"] != null)
         {
            Session["FirstTime"] = null;
            WelcomeLabel.Text = String.Format("Welcome to the site, {0}", 
               customerID.Substring(0, underscore));
            ActiveForm = WelcomeForm;
         }
         else
         {
            ReturnLabel.Text = String.Format("Welcome back, {0}", 
               customerID.Substring(0, underscore));
            ActiveForm = ReturnForm;
         }
      }
   }
}

protected void LoginForm_OnSubmit(Object sender, EventArgs e)
{
   // Generate a customer ID. Here, you would normally create
   // a new customer profile.

   String customerID = CustomerName.Text + "_" + 
      System.Guid.NewGuid().ToString();
   String path = AbsoluteFilePath + "?cid=" + 
      Server.UrlEncode(customerID);
   Session["FirstTime"] = true;
   RedirectToMobilePage(path);
}

</script>

<mobile:Form runat="server">
   <mobile:Label runat="server" StyleReference="title">
      Welcome to the site. Please register to continue.
   </mobile:Label>
   <mobile:TextBox runat="server" id="CustomerName" />
   <mobile:Command runat="server" OnClick="LoginForm_OnSubmit" 
      Text="Register" />
</mobile:Form>

<mobile:Form id="WelcomeForm" runat="server">
   <mobile:Label runat="server" id="WelcomeLabel" />
   Please bookmark this page for future access.
</mobile:Form>

<mobile:Form id="ReturnForm" runat="server">
   <mobile:Label runat="server" id="ReturnLabel" />
</mobile:Form>

Optimizing View State for Mobile Applications

For mobile Web Forms pages, the following considerations are important:

Saving view state to the session is highly optimized. If there is no view state to be saved, nothing is stored in the session, and no identifier is sent to the client. However, application developers who want to avoid using session management, or who want pages capable of high throughput, can consider reducing or eliminating the use of view state. In many application cases (such as rendering a page of formatted text), view state is unnecessary and is best turned off.
In addition to the application view state, a mobile Web Forms page must store other types of additional state information about the page. This information might include the active form, or pagination information about the form. Such information is always sent to the client rather than kept on the server, and is usually generated in an optimized way. For example, if the first form is active, or the first page of a form is being shown, this information is not saved, because these are default states. Such state information is called the private view state. All controls can override the LoadPrivateViewState and SavePrivateViewState methods to read and write private view state.

For information about hidden variables and how they can be used to save view state information, see ASP.NET State Management.

Note Good security practice demands that if you include sensitive information in the session state, you use a connection with HTTPS and SSL/TLS authentication.