Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

ViewState

ASP.NET gives the user the impression that the runtime maintains the state of pages over several server round-trips. The pages don't really exist over multiple requests and responses; instead, the runtime saves the properties of the page and each server control's ViewState to an instance of the StateBag class. When the user makes a request, the runtime automatically reconstructs the page using the property values persisted in the StateBag instance.

As a developer, you might find the automatic reconstruction of a page's state a useful feature. For example, if you define a property in your code-behind class, that property isn't automatically saved and restored each time the page is torn down and then reconstructed on the next request. If you set this property in code on one request, you might want to persist this value across server round-trips. You could add the property to the Session or even persist it by using hidden variables. However, if you use the ViewState property of the MobilePage class to maintain the property's value, the runtime will automatically save and restore that value on your behalf.

The ViewState property has the scope of the current MobilePage object (the current .aspx file plus any code-behind module). If your application moves from one MobilePage object to another, either by sending an HTTP redirect to the client (using MobilePage.Response.Redirect("url")) or by transferring control to another page at the server (using MobilePage.Server.Transfer("url")), in the new mobile page you can't retrieve properties and objects that were stored in ViewState in the first MobilePage object. Use the Session or Application objects to transfer objects between pages; we discuss the Application object in the next section.

Listing 12-6 shows how you might save a property in ViewState and then retrieve it later.

Listing 12-6: Using the ViewState property

using System;
using System.Web;
using System.Web.Mobile;
using System.Web.UI.MobileControls;
using System.Web.UI;
public class MobileWebForm1 : System.Web.UI.MobileControls.MobilePage
{
protected System.Web.UI.MobileControls.Command Command1;
protected System.Web.UI.MobileControls.Label Label1;
// MyMessage property get and set accessors 
// using the ViewState property
public String MyMessage 
{
get
{
// Explicit cast to String
return (String) ViewState["MyMessage"];
}
set
{
ViewState["MyMessage"]=value;
}
}
private void Command1_Click(object sender, System.EventArgs e)
{
// Consume the persisted property.
Label1.Text=this.MyMessage;
}
}

By default, mobile pages and server controls have ViewState enabled. However, you can override this behavior and enable or disable a page or individual controls within that page. If you disable ViewState for a control that contains other controls, such as the Panel control, all child controls automatically will have their ViewState disabled.

To disable the ViewState of an individual control, you must set that control's EnableViewState property to False, either in code or in server control syntax, as the following code illustrates:

<mobile:Label id="Label1" runat="server" EnableViewState="False"/>

To disable the ViewState of an entire page, you can use the MobilePage.ViewState property in code or use the EnableViewState attribute of @ Page directive within the mobile page .aspx file, as shown here:

<%@ Page language="c#" Codebehind="MobileWebForm1.aspx.cs" 
Inherits="MobileWebForm1" EnableViewState="False" %>

When writing ASP.NET applications for wired clients, you'll often want to disable the ViewState to enhance your application's speed. The runtime distributes ViewState information to the client in a way that's similar to the hidden variables you learned about earlier, and sending large amounts of data between the client and server places a large overhead on the network. However, mobile applications are different. For applications built with the ASP.NET Mobile Controls, Microsoft changed the implementation of ViewState because of the extreme bandwidth limitations placed on those clients. For mobile Web applications, the runtime saves ViewState information in the Session object and doesn't send that information to the client; it sends the client only an identifier.

This unique approach to ViewState management means that you can forgo the performance-related considerations a developer working with standard ASP.NET would have. However, you do have to consider the effect of using the Session object to maintain ViewState—something that doesn't concern a developer of nonmobile applications.

When using the Session object to store ViewState, you have two important considerations. First, sessions can expire, which means that you can lose your ViewState information. The number of minutes allowed to elapse before a response is received from a client is set by the timeout attribute of the sessionState element in the application's Web.config file, as shown in the following code. (Twenty minutes is the default.)

<configuration>
<system.web>
<sessionState
mode="inProc"
cookieless="true" 
timeout="20"
/>
</system.web>
</configuration>

If a user posts back data after a session expires, the runtime calls the page's OnViewStateExpire event handler method. By default, this method throws an exception; however, you can override this method in your code-behind class to implement different behavior. Your application could display a friendly page informing the user that the session has timed out and perhaps redirecting the user to a menu page in your application. In some circumstances, you could attempt recovery of the ViewState information manually by calling the LoadViewState method of the MobilePage object.

The second consideration is that the page displayed on the client and the current state of the session information held on the server can fall out of sync. This can occur when a user uses a Back feature on the browser to return to a page viewed previously—for instance, by clicking a Back button. For example, imagine that a user goes to the first page of an application and then clicks a link to go to the second page. If the user then navigates backward to the first page, the user views the first page while the server holds session data for the application's second page. The ASP.NET mobile controls overcome this issue by maintaining a small history of ViewState information in the user's session. When the user posts back to the server from the first page in the scenario just described (when the server "thinks" the user is on the second page), the runtime reconciles the identifier received from the client with the identifier of the ViewState information to pull the correct ViewState out of the history. You can configure the size of the ViewState history, meaning that you can modify it to suit your application. The default history size is 6. To change the history size, use the sessionStateHistorySize attribute of the mobileControls element within the Web.config file, as the following code shows.

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

All items that use the Session object have to deal with the issues of state expiration; however, the automatic management that ASP.NET provides effectively hides these issues from you. The simplest way to avoid unforeseen problems is to ensure that you have a session expiration time and state history size appropriate to your application. For example, it's foolish to set a session expiration time of 1 minute for a shopping application because users often flit between applications or think about a product before making a purchase. Therefore, sessions should reflect your users' pace of browsing through pages, and the time-out should occur after a more realistic time frame, such as 20 minutes. In addition, the user might make significant use of the history stack when browsing through pages in this type of application. You should ensure that you increase the session state history size to reflect this pattern.