Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Book Excerpt: Building .NET Applications for Mobile Devices : Page 2

This book demonstrates how to use the Microsoft .NET Framework and Visual Studio.Net to create applications for phones, Pocket PCs, and other portable devices. Focusing on ASP.NET and the .NET Mobile Web SDK, it shows how to deliver appropriately formatted content for diverse hand held clients from a single ASP.NET page, along with how to provide mobile email access with Microsoft Outlook Mobile Manager. Read all of Chapter 3, "Developing Mobile Web Applications."


advertisement
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. The Mobile Internet Toolkit allows 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 the 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 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
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

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:

  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.
  6. Click to view graphic
    Click to view graphic

  7. Figure 3-12 The Design window in Visual Studio .NET
  8. 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.
  9. Click to view graphic
    Click to view graphic

  10. Figure 3-13 The drop-down list of the NavigateUrl property
  11. 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.
  12. 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

In the sample application you just built, two obvious, named links appear on the first Form. 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 in-built 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 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 Calendar control is one of the more complex controls in the Mobile Internet Toolkit. 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:

  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
Click to view graphic

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

Click to view graphic
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

In this chapter, we've introduced only the basics of Visual Studio .NET. This development environment offers far more functionality than we can cover in just one chapter. For instance, Visual Studio .NET has an extensive Help system that can give you more information on the Visual Studio IDE, the mobile controls, and the .NET Framework classes.

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

The Mobile Internet Toolkit installs many sample applications, which you can find at http://localhost/mobilequickstart/samples. Similarly, the .NET Framework SDK installs a number of sample solutions, including ASP.NET samples that illustrate the usage of the .NET classes. (There's a link to these in the Microsoft .NET Framework SDK folder on the Start menu.) These samples consist solely of text files written in C#, Visual Basic .NET, or Visual C++ or written as .aspx files containing text in ASP.NET syntax.

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#" %>
 
<mobile:Form runat="server">
 <mobile:Label runat="server">Hello World!</mobile:Label>
</mobile:Form>

Save the code as SimpleSolution.aspx, and place it into the root directory of IIS (in \inetpub\wwwroot). 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

You might think that the ASP.NET source just shown bears little resemblance to the solution you constructed using the Mobile Internet Designer GUI editor earlier in the chapter. However, you'll now see that this isn't the case.

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
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:

<mobile:Form id=Form1 runat="server">
 <mobile:Label id=Label1 runat="server">Hello World! </mobile:Label>
</mobile:Form>

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 <mobile:Form >, and the closing tag is </ mobile:Form>. 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:

<mobile:Label id=Label1 runat="server">Hello World!</ mobile:Label>

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:

<mobile:Form id=Form1 runat="server">

The XML text, which represents the mobile controls, lies within the body of the document and is enclosed by the <body> and </body> tags. The three </meta> 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 </meta> 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 <mobile:Form> and <mobile:Label>) 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 <script> and </script> 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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date