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

Working with the Mobile Internet Designer

The MyFirstMobileApp project you just created introduced you to the power Visual Studio .NET and the Mobile Internet Designer have to develop mobile Web applications. The Mobile Internet Designer allows you to graphically lay out your mobile Web Forms pages. However, the layout possibilities are more limited than those offered by a full WYSIWYG graphical Web page designer, such as a designer you'd use with ASP.NET Web Forms targeted at desktop clients. For example, the Mobile Internet Designer doesn't offer grid layout. As a result, you can't position controls at specific coordinates. Each control in a mobile Web Forms page displayed in the Mobile Internet Designer is shown positioned directly beneath the previous control, as though in a list; the controls aren't resizable.

These restrictions reflect the limited display capabilities of the target devices. Remember that you're working with an abstraction of the mobile device application. Your application is rendered differently for each target device. ASP.NET mobile controls allow you to concentrate on the functionality you want to deliver without worrying about the specific markup language a particular device requires. Mobile device capabilities differ substantially in characteristics such as color support or screen size. Consequently, the visual representation of the controls you place on a mobile Web Forms page signifies the intended functionality, not the exact appearance.

The Mobile Web Forms Page and Form Control

As you saw earlier, when you use the New Project dialog box to build a new mobile Web solution, you create a single file with an .aspx extension. This file defines a mobile Web Forms page. Simple applications typically contain a single Web Forms page, although there's nothing stopping you from building mobile Web applications that consist of many mobile Web Forms pages.

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

Figure 2-10: 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.

Usually, a Form control is rendered as a single screen on a target device, but the runtime might split the contents of a Form control across multiple screens if the Form control contains too much content to be displayed in one go on the particular client device that is making the call. From the developer's perspective, it's more accurate to describe a Form control as a container for a named, logical grouping of controls. 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 8.

Positioning Controls on Web Forms

Unlike standard ASP.NET Web Forms, which you use to build applications for desktop browsers, the Mobile Internet Designer, used to lay out mobile Web Forms, doesn't offer a grid for placing mobile controls. Instead, the Mobile Internet 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.

Using the MyFirstMobileApp solution that you created earlier, click on the Toolbox tab to open it, and drag two Label controls and a TextBox control onto the Form control. Notice that the Mobile Internet Designer does not allow you to position new controls alongside any existing ones and only allows you to place controls in a top down list. See the sidebar "Limited Layout Possibilities" for an explanation of this behavior.

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 .NET 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.

You can order mobile controls only in a top-down list, and you can't control the vertical spacing between them. This might seem a little strange, particularly to those developers who are used to graphical Web application designers. But remember that with the ASP.NET mobile controls, you're working with control objects that represent distinct pieces of user interface functionality—in other words, such an object is an abstraction of the user interface rather than a WYSIWYG representation of the finished result.

Mobile devices tend to have very small displays, and the scope for artistic expression on your user interface is unfortunately very small. The main purpose of the ASP.NET mobile controls is to make it easy to build applications that run on mobile devices using various client browsers. Developers of ASP.NET applications targeted at desktop browsers using full Web Forms work with the visual appearance of the form in mind. Mobile Web developers concentrate more on the functionality of the application and—with some exceptions, as you will see in Chapter 9 and Chapter 10—leave the presentation to the runtime and the target browser.

Many wireless developers are already familiar with this idea. In general, mobile phone displays don't have a screen size that allows complex layouts or a mouse-like navigation device.

When designing a mobile Web Forms page, you can use the mouse to drag controls to a new location within the Form control. 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 Form Controls

Very few mobile Web applications consist of a single transaction with a user. You could conceivably write a very simple service using a single Form control—for example, a mobile Web site that simply returns the number of cans remaining in the computerized vending machine on the first floor of your office. However, in practice, most applications consist of a number of discrete pieces of functionality, each of which you can logically represent with one or more Form controls containing the required mobile controls, which can all be contained within the same mobile Web Forms page.

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:

Create a new mobile project, and name it MultipleForms.

As before, rename the MobileWebForm1.aspx file default.aspx to enhance usability.

Within the Mobile Internet Designer, drag two additional Form controls from the Mobile Web Forms Toolbox to the mobile Web Forms page.

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 a 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.

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 2-11 shows how the Design window should now look.

Figure 2-11: The Design window in Visual Studio .NET

Click the first Link control, and set the Text property to Go To Form 2. Now select the NavigateUrl property and click the drop-down list to view a list of options, as shown in Figure 2-12.

Figure 2-12: The drop-down list of the NavigateUrl property

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, be sure that 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.

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.

In the MultipleForms example presented in the section "Working with Multiple Form Controls," you use the ID for each Form Visual Studio .NET supplied. Since the ID is a property like any other, you're free to change it. The only requirement is that each control must have a unique ID.

Every time you add a new control to a Web Forms page, Visual Studio .NET assigns it a name consisting of the control type followed by a numeric suffix, such as Form1 or Form2. Many developers prefer to change these IDs to names that are more meaningful and that indicate the control's function within the application. For example, you might name a Label control that displays a city name CityNameLabel. Think back to the two Link controls used in our MultipleForms sample application. Meaningful names for these two controls could be LinkToForm2 and LinkToForm3. Such a name immediately indicates the purpose of the control. In a real application, the Form controls would also have meaningful names describing their purpose.

As you'll see in Chapter 3, you'll frequently write code that will access the properties and methods of controls. If you use meaningful control names, your application code will be more precise, readable, and clear.

Backward and Forward Navigation in Mobile Web Applications

In the MultipleForms sample application you just built, two obvious, named links appear on the first Form control. These Link controls provide your applications with forward navigation. In a real application, you'd expect users to execute a specific part of the application and then exit or return to the entry screen to make further selections. In our sample application, you didn't place Link controls on the second and third Web Forms linking back to Form1. However, your application does have built-in backward navigation support: Internet Explorer achieves such backward navigation support by using the built-in Back button, and all the major desktop Web browsers offer this functionality.

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 ASP.NET mobile controls saves you from having to worry about such idiosyncrasies. The ASP.NET 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 Calendar control is one of the more complex ASP.NET mobile controls. This control illustrates how the user interface of a mobile control can differ from one mobile client to another. The following steps create an application that allows a user to enter the preferred date for an appointment:

Create a new mobile project, and name it Scheduler. You might want to rename the mobile Web Forms file default.aspx, as you did earlier.

Drag a Label control and a Calendar control from the Toolbox to Form1.

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.

Set the Text property of the label to Choose preferred:.

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 2-13 and 2-14 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.

Figure 2-13: The Calendar control in Internet Explorer and Pocket Internet Explorer

Figure 2-14: 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'll see in Chapter 9.) However, you might find a control's default rendering appropriate for many applications.