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

Writing Applications with a Text Editor

In this last example, you'll build a small application that displays the current time and allows the user to click a button to update the display. This application introduces you to writing Web applications with command-line tools, using the .NET Framework SDK. Although you're unlikely to write real-world applications in this way, knowing how the command-line approach works will help you understand the process by which Visual Studio .NET helps you construct a mobile Web application. This example also places code in a code-behind file and overrides the Page_Load method.

Building the User Interface

In this example, you'll use your favorite text editor—for example, Microsoft Notepad—to create the mobile application. You'll write the text that represents the server controls directly into the source file of the mobile Web Forms page, rather than using the drag-and-drop facility that Visual Studio .NET offers.

Create a new file named ClockGUI.aspx, and save it in a subdirectory of the IIS document root directory named TicToc, (c:\inetpub\wwwroot\). The new file commences with the following two lines:

<%@ Page Inherits="MSPress.MobWeb.TicToc.ClockGUI"
Codebehind="ClockGUI.aspx.cs"
Language="C#" AutoEventWireup="true" %>
<%@ Register TagPrefix="mobile" Namespace="System.Web.UI.MobileControls" 
Assembly="System.Web.Mobile" %>

We discussed the meaning of these two lines earlier in this chapter; however, the first line requires further explanation. This line is a page directive that has four attributes: Inherits, Codebehind, Language, and AutoEventWireup.

The value of the Inherits attribute states that this page inherits from the ClockGUI class in the MSPress.MobWeb.TicToc namespace. Thus, the page inherits properties and methods from the ClockGUI class. The value of the Codebehind attribute indicates the name of the module containing this class. In this example, the file containing the ClockGUI class is ClockGUI.aspx.cs, which we'll create in the next section. The third attribute specifies the language that the code-behind module is written with. In this example, the code is written in C#. The AutoEventWireup attribute is set to true, so event handlers such as Page_Load and Command1_Click will be called automatically, without having to be explicitly wired up.

Now that you've referenced the code-behind file and ensured that you can access its methods, you can write the source code that represents the visual elements of the application. These elements consist of a single Web Forms control that contains two other mobile controls, a Label and a Command. Use the following code for the GUI:

<mobile:Form runat="server" method="post">
<mobile:label runat="server" id="Label1" alignment="center"/>
<mobile:command runat="server" text="Update Time" 
id="Command1" alignment="center"/>
</mobile:Form>

You probably recognize this Form design as being the same as in the first application you created in this chapter. Notice that the Label control doesn't have a Text attribute value defined here; you'll set that attribute in the code-behind module.

Creating the Code-Behind Module

Now that you've completed the GUI, save and then close the file. Create a new file named ClockGUI.aspx.cs, and type the following code. Then save the file in the TicToc application directory you created earlier.

using System;
namespace MSPress.MobWeb.TicToc
{
public class ClockGUI : System.Web.UI.MobileControls.MobilePage
{
protected System.Web.UI.MobileControls.Label Label1;
protected void Page_Load(object sender, System.EventArgs e)
{
Label1.Text=DateTime.Now.ToString("T");
}
}
}

Notice that this code is far more succinct than the code generated for a similar project by Visual Studio .NET would be. There are two main reasons for this. First, Visual Studio .NET creates some code for its own use, to support the Mobile Internet Designer and other Visual Studio .NET features. Because this code module won't be developed or debugged in Visual Studio .NET, the application doesn't need to include these superfluous methods. Second, Visual Studio .NET inserts using statements for the most common programming namespaces that you're likely to use, although not many are required for simple applications.

The code example consists of one class that contains just one method. Two statements we have yet to discuss appear before the class definition. The first statement follows:

using System;

This statement tells the runtime that this file uses types of the System namespace, which every .NET application must include as a minimum. These types include a wide variety of classes that contain the following programming elements:

Definitions of commonly used value types and reference types

Events and event handlers

Processing exceptions

Here's the second statement that appears outside the class boundaries:

namespace MSPress.MobWeb.TicToc

This statement defines a namespace named MSPress.MobWeb.TicToc within the code-behind module. A namespace enables you to organize your code and ensure that it has a globally unique name. Consequently, each class that you create doesn't stand in isolation; instead, it belongs to a given namespace. The following scenario might help you better understand the benefits of using namespaces.

Consider an application that uses methods declared in two different libraries, A and B. Both libraries define a class named C which your application needs to use. If both of these libraries use the same namespace, a naming clash will occur and it will be impossible to decide which class C the application should use. However, if both libraries define a different namespace, we can fully qualify the name of class C in each library. In this example, to create an instance of the class C in library A, the application would use the fully qualified type name of ANameSpace.C, while the class C in library B is defined by the fully qualified type name BNameSpace.C.

If you neglect to declare a namespace within a file, the file will still have a namespace. This namespace is a default that the .NET environment creates on your behalf. However, relying on default namespaces can easily result in confused, tangled, and unusable code. You should consider omitting namespace declarations only in the very simplest applications.

All the samples in this book that use a code-behind module explicitly declare the namespace that the class in the code-behind module belongs to. If no namespace is declared, ASP.NET compiles the classes into a default namespace that matches the name of the virtual directory where the application is installed—in other words, the application name. In your own applications, it's better to explicitly declare the namespace to avoid naming clashes between similar-named objects in different applications. Visual Studio .NET always generates C# code modules that include a namespace declaration. In Visual Basic .NET projects, the code-behind module generated by Visual Studio .NET does not include a namespace declaration (although you can add one if you want); the namespace used is defined in the project properties.

When you create a project in Visual Studio .NET, the namespace for your application is derived from the application name. For example, the code for the application at http://localhost/Time is created in the Time namespace. For most production applications, you'll want to use a more meaningful namespace, perhaps derived from your company name. For example, most of the samples in this book are in the MSPress.MobWeb.{sampleName} namespace.

To change the namespace of a Visual Studio .NET project, right-click on the project name in Solution Explorer and select Properties. Change the namespace in the Project properties to the required value. You could then edit the four file names in which the namespace is explicitly stated: MobileWebForm1.aspx, MobileWebForm1.aspx.cs, Global.asax, and Global.asax.cs. A quicker way is simply to use Solution Explorer to delete MobileWebForm1.aspx and Global.asax from the project and then right-click on the project name and choose Add New. Choose a new Mobile Web Form item and a new Global Application Class item from those offered. This re-creates the required files in the correct namespace.

The class definition, shown here, follows the two statements just described:

public class ClockGUI : System.Web.UI.MobileControls.MobilePage

The class definition declares a class named ClockGUI that has public visibility. The syntax indicates that this class is derived from System.Web.UI.MobileControls.MobilePage and therefore inherits its characteristics and behavior. All mobile Web Forms pages must inherit directly or indirectly from MobilePage.

The first line of the class declares a class member, as shown here:

protected System.Web.UI.MobileControls.Label Label1;

This declarations represents the mobile Label control.

The Page_Load method of the class reads:

protected void Page_Load(object sender, System.EventArgs e)
{
Label1.Text=DateTime.Now.ToString("T");
}

Whenever the browser on the remote mobile device posts 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. This code updates the Label to display the correct time. Note that even though this application does not contain a Command1_Click event handler, when the user clicks on the Command button, it still causes a post back to the server.

Building and Testing the Application

Now that you've written all the code for this application, you just need to build and test it. If this application consisted simply of an .aspx file, you could call it from a browser and it would compile at run time. In this instance, the application consists of an .aspx file and a code-behind module, which means that you can't simply call the application from a browser. Instead, you must compile the code-behind module and save it to the bin directory, which is a subdirectory of your application's directory.

To compile the code-behind module, follow these steps:

Set the path environment variable so that it references the directory containing csc.exe (the C# compiler).

Open a Command prompt, and change to your application's directory.

Create a new directory, and name it bin.

Type the following command, which compiles the code-behind module:

csc /t:library /reference:System.Web.Mobile.dll 
/out:bin/ClockGUI.dll ClockGUI.aspx.cs

That's it! You've compiled the code-behind module, and you can now call your application from a browser. But before you do that, let's look at the command you typed to compile the code-behind module. The command you called to invoke the C# compiler, csc, took three switches:

/t:libraryInstructs the compiler to output a library (DLL) rather than another type, such as an executable (EXE), which is the default operation.

/reference:System.Web.Mobile.dllInstructs the compiler to reference the System.Web.Mobile.dll. The compiler needs this reference so that it can compile code that uses the ASP.NET mobile controls.

/out:bin/ClockGUI.dllInstructs the compiler where to output the DLL. In this case, we create the ClockGUI.dll and place it in the bin directory.

To run the application, simply call ClockGUI.aspx from a browser. Every time the application loads, the Page_Load method of the code-behind module executes and the display updates to show the current time. Figure 3-12 shows the result.

Figure 3-12: The TicToc application, displaying the updated time