لطفا منتظر باشید ...
Chapter 2. This application also highlights these features of building mobile Web applications:
The common language runtime
Control-class relationships
Class member persistence
The Scheduler application you built in Chapter 2 featured a calendar from which a user could select a date. Now you'll rewrite Scheduler to perform the following tasks:
Accept a date that the user selects
Echo the chosen date to the user
Switch to a Thank You screen at the end
You'll create this application from scratch using the Visual Studio IDE, and you'll build the project the same way you did in the previous applications in this chapter.The original Scheduler application contained only a Calendar control. You'll now build a more complex GUI that consists of two Form controls. The first Form contains a Label with the text "Select Appointment Date", a Calendar, and a Command control with the legend "Book Now!" The second Form contains a label with the text "Thank you for using this application!" Figure 3-6 shows how the finished result will look.
Figure 3-6: The Scheduler application with Form, Label, Calendar, and Command controls
Double-click the Command control to create the event handler for the Click event in the code-behind module. Now type the following switch statement in the Command1_Click method body, and also declare a private class member named pageCount, as shown here:
// Declare and initialize an integer private to this class.
private int pageCount=0;
private void Command1_Click(object sender, System.EventArgs e )
{
pageCount++;
switch (pageCount)
{
case 1: ConfirmDates();
break;
case 2: RenderFinalPage();
break;
default: break;
}
}
This code determines a course of action that depends on the value of pageCount, which represents the number of times a user accesses the application. We'll explain this variable in the next section. The two private methods, ConfirmDates and RenderFinalPage, called from the Command1_Click method, alter the properties of the page's controls. Now type the two private methods into your code, after the Command1_Click method, as shown here:
private void ConfirmDates()
{
Calendar1.Visible=false;
Command1.Text="Ok";
Label1.Text="Your Appointment: "
+ Calendar1.SelectedDate.ToShortDateString();
}
private void RenderFinalPage()
{
ActiveForm = Form2;
}
In the Hello Universe application, you wrote code that changed the Text property of a Label control. The ConfirmDates method you've just written changes the Visible property of the Calendar control. You can set this property to True to make a control visible on the display page, or False to hide it. The RenderFinalPage method sets the ActiveForm property of the page (a property inherited from the MobilePage base class) to Form2, so that the Thank You page displays.
Persisting Class Members
Look again at the Command1_Click method. You've probably noticed that the Switch statement in the Command1_Click method evaluates the value of pageCount. You might expect the program to increment pageCount at each call of the Command1_Click method, as shown here:
private void Command1_Click(object sender, System.EventArgs e)
{
pageCount++;
switch (pageCount)
{
case 1: ConfirmDates();
break;
case 2: RenderFinalPage();
break;
default:
break;
}
}
As you might also expect, when you run this application and click the Command button for the first time, the Command1_Click method executes, pageCount increments to 1, and the ConfirmDates method runs, making the calendar invisible and displaying the selected date. The second time you click the button, you might expect the pageCount variable to increment to 2, causing the RenderFinalPage method to execute. However, you find the RenderFinalPage method does not get called, and if you use the debugger, you'll find that the pageCount variable doesn't increment between clicks of the button. Why? The answer illustrates a feature of ASP.NET that often trips up the unwary: Web applications consist of a series of interactions between a Web server and a browser. These interactions are self-contained and essentially stateless, a process that is illustrated in Figure 3-7.
Figure 3-7: An ASP.NET application is destroyed after each response, and runs again to service the next request.
Every time control passes back to the server from the client browser, the runtime starts up the application. After sending the response to the client, the runtime destroys the application. Before it destroys it, the ASP.NET runtime saves state information so that each time the runtime re-creates the application and the controls it contains, the classes in the application and the controls are restored to the same state they had at the end of the previous request. ASP.NET controls know how to operate in this environment, save their state at the end of each request, and restore their state again at the beginning of the subsequent request, so for example, if you set the Text property of a Label control in code, the Label control remembers that value across subsequent requests. However, if you add any properties of your own to the class, you must make the effort to maintain state information across invocations. The simple answer is that pageCount never increments higher than 1 because it doesn't persist between server round-trips.A number of methods for storing data between server round-trips exist—for example, using the ASP.NET Session or Application objects. (You'll learn more about these methods in Chapter 12.) In this example, you'll use the ViewState property of the MobilePage class. The ViewState property returns a dictionary of information that you can use to maintain data over multiple requests for the same page. The ASP.NET runtime persists the property's values by storing them on disk at the server and sending a session key to the client that is returned with the next HTTP request and that the runtime uses to locate and restore the correct persisted ViewState property.
The following code uses the ViewState property to store the value of pageCount between server round-trips. This code declares pageCount as a public property of the class and provides appropriate get and set accessors:
public int pageCount
{
get
{
// Initialize pageCount if not found
if (ViewState["pageCount"] == null)
ViewState["pageCount"] = 0;
return (int)ViewState["pageCount"];
}
set
{
ViewState["pageCount"] = value;
}
}
When accessed by the Command1_Click method for the first time, the get accessor initializes pageCount to zero and returns that value. In subsequent get requests, the pageCount property returns the pageCount value stored within the ViewState object.
Building and Testing the Application
Figure 3-8 shows how the appointment selection page of your application should look when you're using the Openwave emulator. Remember that the Calendar control might render very differently on other devices. In this instance, when you click the Calendar link, a new page appears, showing the date and two options for selection: Type A Date and Choose A Date (depicted in Figure 3-9). Or if you select an appointment date from the appointment selection page and then click the Book Now! button, the screen will display the date of your appointment, as shown in Figure 3-10. Finally, if you click the OK button on the appointment selection page, the application loads its Thank You page.
Figure 3-8: Openwave simulator displaying the Scheduler's appointment selection page
Figure 3-9: The first of the application's calendar pages
Figure 3-10: The application confirming an appointment date
