Within a mobile Web Forms page, you might have one or more mobile Form controls. The wizard creates a single Form control in your application, which you can see in the Design window when you create a new project. Figure 3-11 shows what this mobile control looks like.

Click to view graphic

Figure 3-11 The mobile Form control within a mobile Web Forms page

You can use the Form control to group other standard controls and contain them. A Form control is the outermost container for other controls in a mobile page. You can’t nest a mobile Form control within another Form control; however, a mobile Web Forms page can contain multiple Form controls.

Don’t make the mistake of thinking of a Form control as a single, rendered page on a target device. From the developer’s perspective, it’s more accurate to describe a Form control as a container for a named, logical grouping of controls. In fact, a single Form control can result in one or more display screens on the target device. The Form control can be set to paginate the output so that the data sent for each page doesn’t exceed the limitations of the receiving device. For example, if you’ve placed a large number of controls inside a Form control or a control that is capable of displaying a large amount of output, such as the TextView control, the output from those controls can end up being displayed on different display pages on smaller devices. You’ll learn more about pagination in Chapter 5.

Positioning Controls on Web Forms

Unlike standard ASP.NET Web Forms, which you use to build applications for desktop browsers, the Mobile Web Designer, used to lay out mobile Web Forms, doesn’t offer a grid for placing mobile controls. Instead, the Mobile Web Designer lets you position controls only from the top down. To illustrate this, this section shows you how to create a new project with a selection of controls.

If you still have Visual Studio .NET open to the MyFirstMobileApp solution, click the File menu. Click Close Solution to close your previous project, and save any changes if prompted.

Create a new mobile project the same way you did earlier, but name this one TestControls. The wizard creates the project at http://localhost/TestControls and opens the newly created mobile Web Forms page, MobileWebForm1.aspx, with the cursor positioned on the new Form control. Now click on the Toolbox tab to open it, and drag two Label controls and a Textbox control onto the Form control.

If you click any of the controls you’ve just placed on the Form control, or on the Form control’s title bar, some small squares will appear at the four corners and in the middle of each side. Those of you familiar with Visual Studio will recognize these squares; they indicate anchor points that you can click with the mouse and then drag to resize the control. However, this isn’t possible with mobile Web Forms controls. Remember that mobile controls are just design objects that enable you to create the functionality of an application. A mobile control’s actual appearance differs from one type of target device to another, and some of the more complex controls might differ in appearance substantially. In this context, resizing controls on a design palette has no relevance.

When designing a mobile Web Forms page, you can use the mouse to drag controls to a new location within the Form. If you want to move a control above an existing one, you must drop it immediately to the left of or above the existing control. To position a control below an existing one, you must drop it just to the right of or below the existing control.

Working with Multiple Mobile Web Forms

To introduce you to structuring your application into multiple Form controls, this discussion shows you how to build a simple application that uses three forms. To do so, execute the following steps:

1. Create a new mobile project, and name it MultipleForms.
2. As before, rename the mobile Web Forms file Default.aspx to enhance usability.
3. Within the Mobile Internet Designer, drag two additional Form controls from the Mobile Web Forms Toolbox to the mobile Web Forms page.
4. Drag a Label control onto each of the Form controls. Click the Label control on Form1 to access the properties in the Properties window. Set the Text property to This Is Form1, and select title from the options offered for the StyleReference property. This causes the application to render the text with emphasis. Repeat this operation with the Label controls on the other two forms, but set the Text property as appropriate for each form.
5. Drag two Link controls onto the first Form. The Link control is a simple navigation control, usually rendered as a hyperlink. You must set two key properties on a Link control: the Text property, which describes the purpose of the link to the user, and the NavigateUrl property, which indicates the target destination. Figure 3-12 shows how the Design window should now look.


Click to view graphic

6. Figure 3-12 The Design window in Visual Studio .NET
7. Click the first Link control, and set the Text property to Go To Form 2. Now scroll down the Properties window to locate the NavigateUrl property. Click a property name to select it. Then click the drop-down list for that property to see a list of possibilities, as Figure 3-13 shows.


Click to view graphic

8. Figure 3-13 The drop-down list of the NavigateUrl property
9. The Link control can navigate to any accessible URL, or it can navigate within the current application. To enter a URL, click the (Select URL) option in the list. To specify a destination within the current application, make sure the NavigateUrl property starts with a pound sign (#) followed by the ID of a Form control. The valid destinations are Form1, Form2, and Form3. Select #Form2 for this first Link control.
10. Click the second Link control, and set the Text property to Go To Form 3 and the NavigateUrl property to #Form3.

That’s it! Now click the Start button in the Visual Studio .NET toolbar to build and run your application in your chosen browser.

Backward and Forward Navigation in Mobile Web Applications

When it comes to mobile devices, however, experienced wireless developers know that backward navigation support isn’t built into all browsers. Pocket Internet Explorer displays a Back control at the foot of the page. Some mobile phone browsers (such as the Openwave WML browser) hardwire one of the soft keys under the phone screen so that the back function is always available. Other browsers (such as the Nokia WML browser) require you to program backward navigation support into the WML markup.

Fortunately, using the Mobile Internet Toolkit saves you from having to worry about such idiosyncrasies. The Mobile Internet Controls Runtime delivers the required markup to each of the supported client devices to ensure that backward navigation is always available. Application developers can concentrate on the functionality of the application, knowing that it will behave consistently on supported client devices.

You can enhance the usability of certain applications by employing Link controls to deliver more explicit backward navigation, rather than relying on the default implementation.

There’s one other consideration of standard navigation options you should be aware of: Internet Explorer and other major desktop browsers offer a Forward navigation button that enables the user to return to a page from which they just backed out. However, mobile browsers don’t offer this option. Small browsers can’t retain such a detailed record of a user’s navigation. Whenever a user leaves a page via backward navigation, the browser removes any references to that page from its history, keeping no record that the user ever visited the page. Consequently, a mobile user can’t undo a backward navigation by accessing a built-in forward function.

Device-Specific Rendering of Complex Controls

The following steps create an application that allows a user to enter the preferred date for an appointment:

1. Create a new mobile project, and name it Scheduler. You might want to rename the mobile Web Forms file to Default.aspx as you did earlier.
2. Drag a Label control and a Calendar control from the Toolbox to Form1.
3. Set the Title property of the Form1 control to Appointments, a suitable title for this page. Remember to keep such titles short?they have to fit on a single line of a mobile phone display.
4. Set the Text property of the label to Choose Preferred.
5. Click the Start button in the toolbar to run the application within Internet Explorer.

If you run this application with Internet Explorer, with Pocket Internet Explorer on a Pocket PC, or on a mobile phone, the difference in appearance will be quite striking. Figures 3-14 and 3-15 show this difference. Internet Explorer and Pocket Internet Explorer render this appointment application as a calendar grid. But on a mobile phone, the appearance is quite different. Clearly, a grid isn’t possible on such a small display; instead, the user either types in a date directly or steps through a number of selection options to choose the desired date.

Click to view graphic

Figure 3-14 The Calendar control in Internet Explorer and Pocket Internet Explorer

Click to view graphic

Figure 3-15 The Calendar control on a mobile phone

Despite the obvious differences in appearance, the Calendar control’s functionality?its ability to select a date?remains unchanged, regardless of the mobile device you use to access it. Sophisticated controls like this handle the details of delivering functionality to the user so that you don’t have to waste valuable time worrying about it. That’s not to say you can’t dictate the appearance of controls on different platforms. (You can, as you will see in Chapter 8.) However, you might find a control’s default rendering appropriate for many applications.

Getting Help in Visual Studio .NET

You can access the Visual Studio .NET Help documentation with the familiar Contents, Index, and Search options by clicking the Help menu. When searching the full Help library, you can apply filters so that only topics relating to your area of interest appear. For example, you can search within “Visual C++ and related,” “Visual Studio .NET,” or “.NET Framework.” By default, when you select any Help topic Visual Studio shows the Help description in the main IDE window. You can change this to a floating window by changing the Help configuration options. To do so, click Tools and then click Options. Open the Environment folder, and click Help. Then select the External Help option.

Visual Studio .NET also includes a number of other Help features that give you the information you need to program effectively?for example, Dynamic Help. By default, the Dynamic Help window appears in the same area of the screen as the Properties window. You can access the Dynamic Help window by clicking the Dynamic Help tab at the bottom of the Properties window. If the Dynamic Help tab isn’t visible, you can make it appear by selecting the Dynamic Help option on the Help menu.

The Dynamic Help window continuously tracks the actions you perform, the position of the cursor, and the object or objects that are currently in focus. Dynamic Help presents topics relevant to the actions you perform, as you perform them. For example, if you open a new project, the application creates a mobile Web Forms page for you containing a Form control, which comes into focus. One of the top entries the Dynamic Help window shows at this time is Introduction To The Form Control. If you click a Label control that you’ve placed onto the Form, the Dynamic Help window updates to display entries relating primarily to the Label control.

In addition to the Dynamic Help window, Visual Studio .NET offers many other Help features that are less obvious. For example, when entering code, the text editor uses a squiggly red underline or other language-specific highlighting to mark any syntax errors you enter. You can also position your editing cursor on any identifiable object?such as a class name, method, property, or language keyword?and press the F1 key. This causes the Help system to automatically display the appropriate Help topic.

Connecting Visual Studio .NET Projects with the SDK Samples

Let’s implement the “Hello World!” project that you created earlier in the chapter, in the section “Creating Your First Mobile Web Applications,” as a single file of ASP.NET code. To do so, use a text editor to write the following code:

<%@?Register?TagPrefix="mobile"?
?Namespace=”System.Web.UI.MobileControls”
?Assembly=”System.Web.Mobile”?%>
<%@?Page?Inherits="System.Web.UI.MobileControls.MobilePage"?Language="c#"?%>
?

?Hello?World!

Save the code as SimpleSolution.aspx, and place it into the root directory of IIS (in inetpubwwwroot). If you access the URL http://localhost/Simple-Solution.aspx from a browser, you’ll access an application giving the same result as MyFirstMobileApp (in which you first implemented the “Hello World!” project).

What’s the connection between this simple solution, and the Visual Studio .NET project? The connection becomes clearer if we take a closer look at the application created in Visual Studio .NET.

Design and HTML Views

Open the MyFirstMobileApp project that you created earlier and open the Default.aspx mobile Web Forms page. On the taskbar at the bottom of the design window, you’ll see two view options: Design and HTML. Select the HTML view (shown in Figure 3-16). You’ll now see text that resembles the single file solution shown just a moment ago.

Click to view graphic

Figure 3-16 The Default.aspx mobile Web Forms page in HTML view

The Design and HTML views offer alternate ways to see the same file. In the Design view, you position visual representations of the mobile controls onto a mobile Web Forms page. However, when you save the Default.aspx file, you’re actually saving a text file in ASP.NET syntax, which is the text shown when you select the HTML view. In fact, Source view might be a more appropriate name than HTML view. But Microsoft uses the latter because ASP.NET is a development of ASP and ASP developers are familiar working with the HTML view. Clearly, static HTML has no relevance for any applications that you build using the Mobile Internet Toolkit, since you must build Web pages solely with the mobile server controls to generate markup for clients that require HTML, cHTML, or WML markup.

If you examine the code shown in the HTML view, you’ll see the following syntax in the middle of the text:

?Hello?World!?

Apart from the addition of the id attributes, this syntax is virtually identical to the SimpleSolution.aspx code just shown. An Extensible Markup Language (XML) element represents each control that you place on a mobile Web Forms page. The opening tag for the mobile control is , and the closing tag is . You can see the text representing the Label control enclosed within the Web Forms tags. You write this textual representation of XML visual elements in something called ASP.NET server control syntax.

If you add controls to the Form control using the GUI designer, the designer will simply add lines of text in server control syntax within the Form tags. The properties of controls that you set through the Properties window can appear here as text positioned between a control’s opening and closing tags. For example, the Text property of the Label control, which you set to “Hello World!” would look like this:

Hello?World!

The other way to represent properties in server control syntax is as XML attributes, which assign values to identifiers within a control’s opening tags using the form property-name=value. For example, you can set a control’s ID property through an attribute:

id=Form1?runat=”server”>

The XML text, which represents the mobile controls, lies within the body of the document and is enclosed by the and tags. The three tags are additional metadata that Visual Studio .NET uses only at design time.

Note that the SimpleSolution.aspx file contains only the source code representing the mobile controls. This is sufficient. When your application runs, ASP.NET doesn’t require the tags.

The two lines of code at the top of the HTML view in Figure 3-16 deserve more explanation. These lines are ASP.NET page directives, which means they specify settings that ASP.NET compilers must use when processing the page.

The first line of the mobile Web Forms page that Visual Studio .NET generates reads

<%@?Register?TagPrefix="mobile"?
Namespace=”System.Web.UI.MobileControls”
?Assembly=”System.Web.Mobile”?%>

You can find the same code in SimpleSolution.aspx, although in that file it’s split among the first, second, and third lines for readability. This syntax simply tells the ASP.NET runtime that when it compiles the page for display, any server controls tags using the prefix mobile (such as and ) represent controls found in the System.Web.UI.MobileControls namespace, within the System.Web.Mobile assembly. (An assembly is the .NET name for a compiled file containing executable code, similar to an .exe or a .dll file. The System.Web.Mobile.dll assembly contains the Mobile Internet Controls Runtime and all the mobile Web Forms controls.)

The @ Page directive in SimpleSolution.aspx uses different attributes than the similar directive in the file that Visual Studio generates. The @ Page directive defines page-specific attributes that the ASP.NET page parser and compiler use. You can include many of these directives in your own code. Here are some of the more important ones and their meanings:

• language=”c#” This directive tells the ASP.NET runtime to compile any code included within the page as C#. For example, code included in the page might appear as inline rendering (code enclosed by <% %> or <%= %> tags) or as code-declaration blocks (code within tags).
• Codebehind=”Default.aspx.cs” As an alternative to inline code?or in addition to it?ASP.NET allows you to place the code logic into an alternative file, the code-behind file. The Codebehind=”Default.aspx.cs”declaration tells the runtime where to find this code. Visual Studio .NET always creates a code-behind module for a mobile Web Forms page. The SimpleSolution.aspx file contains no code and no code-behind module.
• Inherits=”MyFirstMobileApp.MobileWebForm1″ Although not a program module in the traditional sense, the source in a mobile Web Forms page actually defines a .NET class object, which inherits from a class defined in its code- behind module. Every mobile Web Forms page must inherit from the .NET MobilePage class or a class that derives from it. The MyFirstMobileApp.Mobile- WebForm1 class is such a class. The New Project Wizard creates this class in the code-behind module. In SimpleSolution.aspx, the code inherits directly from MobilePage without going through an intermediary class defined in a code- behind module.

Reproduced from Building .NET Applications for Mobile Devices by permission of Microsoft Press. ISBN 0735615322, copyright 2002. All rights reserved.