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

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

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

Andy Wigley; Peter Roxburgh

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید






Chapter 2 to build a Hello Universe mobile Web application. Although simple, this application illustrates a number of important features of building .NET mobile Web applications, including these:



Using the code-behind technique



Capturing events fired by mobile controls



Dynamically altering the properties of controls within Web Forms



Working with the object-oriented features of .NET applications



To get started, create a new project using the Mobile Web Forms Application template in Microsoft Visual C#. Create the GUI by dragging a label and a Command control onto Form1 from the Toolbox. Figure 3-3 shows how the form should look.


Figure 3-3: Creating the user interface in the Design window





Tip

If you set the Alignment property of the Command and Label controls to Center, the controls will align centrally.


Currently, the application doesn't do anything. To fix this, you'll implement code that sets the Text properties of the controls when the page loads, and which changes the Label text to "Hello Universe" and hides the Command control when a user clicks the Upgrade Now! button. This is a good example of how to work with the event-driven model of a mobile Web application.

In an event-driven program, a specific block of code executes when a specific event occurs, such as a user selecting an item from a menu. In fact, all code you'll write in a mobile Web Forms page is in the form of an event handler—code that executes when a particular event occurs. Figure 3-4 illustrates what happens within the execution of an event-driven program.


Figure 3-4: Execution flow within an event-driven program

Most mobile controls trigger events, some as the result of a user interaction such as clicking a button, and others as the result of an external action. All controls inherit from the System.Web.UI.Control class. This class implements a number of events, such as Init, which fires when the server control initializes, and Load, which fires when the control loads into the MobilePage object. Individual controls can implement additional events that are appropriate to their function.

You can write code to trap events fired by any of the controls in your application. The ASP.NET mobile controls are all examples of ASP.NET server controls, meaning that they are programmable objects that you can manipulate in code running on the Web server. Writing code to handle events fired by ASP.NET server controls differs from developing desktop Windows Forms applications and, to a certain extent, from older Web development technologies such as ASP. In a Microsoft Windows Forms desktop application, when a user clicks a button, the Click event is raised immediately. In an ASP.NET Web application, the user clicks a button displayed in the Web browser on the remote client, but this only causes certain data to be posted back to the Web server with the next HTTP request. It's only after the data that's posted back is analyzed on the server that the control class in your server-side code raises the event and your application can handle it.

To create the method called whenever the Click event of the Command control fires, double-click the Command control shown in the Design window of your mobile Web Forms page. Visual Studio .NET displays a view of the code-behind module, which has the same name as your .aspx file, but with the suffix .cs. Visual Studio .NET automatically creates the event handler method for the control you double-clicked. In this case, the method is Command1_Click, and it looks like this:

private void Command1_Click(object sender, System.EventArgs e)

The runtime calls the Command1_Click method whenever the component with the Command1 ID fires a Click event. This event method takes two arguments:



The object that fired the event (in this case, the sender object).



An object that contains data specific to the event. In the preceding code, this object takes the type System.EventArgs, which is the type used if the event doesn't generate any control-specific data. Most mobile Web Forms controls raise events that don't generate any control-specific data, so they typically take an argument of the type System.EventArgs. Other events, such as those associated with the AdRotator control, do generate data, and so they take different object types. For example, the AdRotator control takes an argument of the type System.Web.UI.WebControls.AdCreatedEventArgs, and the ObjectList control takes an argument of the type System.Web.UI.ObjectListCommandEventArgs.



Before coding the Click event handler, add the following code to the Page_Load method in the code-behind module:

protected void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
{
Label1.Text = "Hello World";
Command1.Text = "Upgrade Now!";
}
}

You might notice that this method takes similar arguments to the Click event handler. Like the Command1_Click method, the Page_Load method handles an event. However, this event isn't directly associated with an action performed by the user such as the Click event of the Command control. Instead, this event is raised by the MobilePage. Whenever the browser on the remote mobile device posts data back to the server, the entire mobile Web Forms page object reloads, whereupon it raises the Load event. The Load event may be handled by an event handler such as the Page_Load method in this application.

The code in the Page_Load method tests the IsPostBack property of the MobilePage. The IsPostBack property is a Boolean value that indicates whether this is the first time the application is processing the page. If the IsPostBack property is false, as it is the first time this code executes when the user accesses the application the very first time, the code within the method simply initializes the text properties of the Label and Command controls. (Of course, you would normally do this by setting properties using the Mobile Internet Designer, but it's just as valid to set properties such as this in your application logic.) After the first call to the page, IsPostBack is true, so the contents of the if statement won't be executed. The code ensures that the controls are initialized only when the page first loads and the Text properties are not reset to their starting values on subsequent postbacks.

Now return to the Click event handler. The code you'll now write will change the text display on the label in the form from "Hello World" to "Hello Universe" and will hide the Command control after the user has clicked it. Edit the Command1_Click method so that it now reads this way:

private void Command1_Click(object sender, System.EventArgs e )
{
Label1.Text = "Hello Universe";
Command1.Visible = false
}

This application is now complete. You just need to build and deploy it. Build the project by selecting Build Solution from the Build menu. If you've made any errors writing the code, you'll see build errors in the Task List. The error tasks detail the names of the affected files, the line numbers of the errors, and error descriptions. Now that you've built the application, you can view it in the test browser. The left screen in Figure 3-5 shows how the output will initially appear if you're using the Openwave simulator. When you click the Upgrade Now! link, the display changes to the one shown on the right.


Figure 3-5: The first page of the application and the application page after you've clicked the Upgrade Now! link








Wiring Up Events and Event Handlers


In the Hello Universe application, you use event handler methods without too much concern for how the actual events and their respective handler methods connect. Both Visual Studio .NET and the .NET Framework hide the details of this connection from you, so you don't really need to follow what's going on behind the scenes.

Wiring Up Primary Event Handlers in Visual Studio .NET

If you use Visual Studio .NET, you don't generally need to worry about wiring up events and event handlers because the IDE inserts the necessary code in the code-behind module automatically. You can just double-click on a control shown in the Mobile Internet Designer, and it will automatically wire up the "primary" event for that control. For example, if you double-click on a Command control, Visual Studio .NET automatically inserts the code into your code-behind module to wire up the Click event for the Command control. It's worth understanding the code that Visual Studio .NET creates because you can use the same technique in code you write.

The class in the code-behind module overrides the OnInit event handler method of its parent which executes when the mobile Web Forms page initializes, and this method contains the code that wires up the event handlers. For the Hello Universe application, OnInit wires up the Click event handler with the following code:

Command1.Click += new System.EventHandler(this.Command1_Click);

This code declares a new delegate of type System.EventHandler, passing the address of the Command1_Click method as the event handler method to execute. As the += operator suggests, this delegate is added to a collection, because you can, if you want, execute more than one event handler method when the Command1 object raises the Click event. The event handler method can be declared using the private access modifier.

Visual Basic .NET provides two alternative ways of wiring up the event handlers at run time. The equivalent of the C# example just given is to use the AddHandler keyword, as shown here:

AddHandler Command1.Click, Me.Command1_Click

The other technique is to use the Handles keyword in the event handler declaration itself. The control declaration must be declared with the WithEvents keyword, as follows:

Protected WithEvents Command1 As System.Web.UI.MobileControls.Command


Private Sub Command1_Click(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles Command1.Click


End Sub


Wiring Up Secondary Event Handlers in Visual Studio .NET

If you want to wire up an event handler for one of the other events of a control, double-clicking on the control in the Mobile Internet Designer won't help you. For example, double-clicking on the Command control wires up the Click event, but perhaps you want to write an event handler for the PreRender event? The technique for doing this differs between C# and Visual Basic .NET projects.

In C#, click on the control in the Mobile Internet Designer to select it, then click the lightning flash icon at the top of the Properties window. This displays a list of all the events for that control. Simply type in the name of the event handler method you want to create in the box next to the event, or double-click there to accept the default name. Visual Studio.NET adds the required code to wire up the event into the OnInit method, just as it does for the primary event, and creates the event handler method in your code-behind class.

In Visual Basic .NET, you don't wire up event handlers through the Properties window. Instead, open the code-behind module in the code editor and click the left-hand dropdown list at the top of the page. Select the control for which you want to create an event, then select the required event in the right-hand dropdown list. Visual Studio .NET inserts the required code to wire up the event into your code-behind module and creates the event handler function for you to complete.

Wiring Up Event Handlers Using Server Control Syntax

If you are writing applications using a text editor, rather than Visual Studio .NET, you can wire up event handlers using server control syntax:

<%@ Register TagPrefix="mobile" Namespace… %>
<%@ Page Language="vb" AutoEventWireup="false" … %>
<mobile:Form id="Form1" runat="server">
<mobile:Command id="Command1" OnClick="Command1_Click" runat="server">
Command
</mobile:Command>
</mobile:Form>

If you use this technique, the event handler method named must be either declared in a <script> … </script> block within the .aspx file, or as a public method in the code-behind module.

Wiring Up Events with the AutoEventWireup Attribute

As a final alternative, you can request that the runtime automatically wire up the events and event handlers. To do this, you must give the AutoEventWireup attribute of the @ Page directive (located at the top of your .aspx file) a value of true. (The default is false.) Here's an example:

<%@ Page language="c#" codebehind="MobileWebForm1.aspx.cs" inherits="Examp
le.Mobi leWebForm1.aspx" AutoEventWireup="true" %>

You don't need to wire up your event handlers in any of the ways described earlier, because the runtime does the wiring up automatically if it finds methods with expected names, such as Page_Load or Command1_Click. The disadvantage of this technique is that your event handler methods must have predictable names. If you wire up the event handlers explicitly, you could handle the Click event of the control with the ID Command1 with a method named ThisCoolMethodHandlesTheClickEvent, but with

AutoEventWireup="true" , the method must be named Command1_Click.











/ 145