Book Excerpt: Building .NET Applications for Mobile Devices

Book Excerpt: Building .NET Applications for Mobile Devices

Chapter 3: Developing Mobile Web Applications

In this chapter, we’ll provide you with an overview of the mobile Web application development process. We’ll systematically guide you through some simple applications built using Microsoft Visual Studio .NET and the Mobile Internet Designer (the GUI editor for mobile Web applications), and we’ll introduce you to the features of Visual Studio .NET. We’ll also compare the development process of an application built using Visual Studio .NET with that of an application built using a text editor and compiled at the command line.

We’ll start the chapter by outlining the system requirements for development platforms and showing you how to create your first mobile Web applications. You’ll then discover how to test your application with Microsoft Internet Explorer as well as with a tool that emulates a mobile device. Finally, you’ll learn how to work with Visual Studio .NET Web projects.

Setting Up Your Development System

To develop applications using the Mobile Internet Toolkit, you’ll need access to a computer with the following configuration:

  • Microsoft Windows 2000 Service Pack 2, Microsoft Windows XP Professional, or Microsoft Windows 2000 Service Pack 2 Server Microsoft Windows XP is the newest version of the world’s favorite operating system. If you’re using Windows XP, you’ll need to develop on the Professional Edition, which includes Internet Information Services (IIS).
  • Microsoft Internet Information Services (IIS) 5.0 or later To install IIS in Windows 2000, click Start, point to Settings, and then click Control Panel. In Windows XP, click Start and then click Control Panel. Click Add/Remove Programs, and then click the Add/Remove Windows Components button. Select the Internet Information Services (IIS) check box to enable IIS on your system.
  • Microsoft .NET Framework You can find a copy of the .NET Framework on this book’s companion CD. Alternatively, you can download the .NET Framework from the MSDN Web site at If you install Visual Studio .NET, the .NET Framework is installed at the same time.
  • Visual Studio .NET Strictly speaking, Visual Studio .NET isn’t essential for developing mobile Web applications. You can create mobile Web Forms applications using a text editor and the command-line compilation tools on a computer with the .NET Framework and Mobile Internet Toolkit installed. However, an integrated development environment (IDE) such as Visual Studio .NET is indispensable for efficient development.
  • Mobile Internet Toolkit You can download the Mobile Internet Toolkit and updates from the MSDN Web site.

If you want to, you can run the Visual Studio .NET IDE on your development workstation and locate your applications on a different Web server. In this configuration, your development system must be running Microsoft Windows NT 4 Service Pack 6a, Windows 2000 Service Pack 2, or Windows XP and must have Visual Studio .NET and the Mobile Internet Toolkit installed. The Web server must be running Microsoft Windows 2000, Microsoft Windows .NET Server, or Microsoft Windows XP and must be running IIS version 5.0 or later. It must also have the .NET Framework and the Mobile Internet Toolkit installed. The easy way to configure a separate Web server is to install Visual Studio .NET, proceed through the Windows Component Update phase, and then clear all options apart from server components prior to the installation of Visual Studio .NET. In addition, you’ll need administrative access to the Web server.

By default, Visual Studio .NET expects to create Web projects on a Web server running on the development system, which you can access using URLs that begin with http://localhost. The examples we’ll give in this chapter assume this configuration.

The minimum computer specification recommended for Visual Studio .NET development is a Pentium II 450-MHz machine with 128 MB of RAM. However, we recommend a Pentium III 733-MHz machine with 256 MB of RAM. Like many IDEs, Visual Studio .NET provides a wealth of information, so for effective development we advise using at least a 17-inch monitor.

In addition, you’ll need either some mobile devices or software emulations of them to thoroughly test your applications. Visual Studio .NET integrates Internet Explorer for easy testing of Web applications, which is a useful tool for the early stages of mobile Web application development. The multiple browser support of ASP.NET with the Mobile Internet Toolkit means that Internet Explorer is just as valid a client browser as a Wireless Application Protocol (WAP) browser or Pocket Internet Explorer. However, you’ll also need to test your applications on the intended target devices. You’ll learn more about mobile device emulators and using them for testing later in this chapter, in the section “Testing with a Mobile Phone Emulator.”

Creating Your First Mobile Web Applications

Visual Studio .NET is a complete development environment for authors of .NET Framework applications. Its graphical designer enables you to select mobile Web Forms controls from the Toolbox and then drag and drop them into position on mobile Web Forms. You can use any .NET-compliant language to code program logic, and the integrated editing and compilation facilities make producing accurate code much easier. Visual Studio .NET also features an integrated Web browser for testing, end-to-end debugging facilities, and powerful project file management, making it an indispensable tool for the mobile Web application developer.

Using Visual Studio .NET

When you start Visual Studio .NET for the first time, the My Profile options within the Start Page appears, as shown in Figure 3-1.

Click to view graphic
Click to view graphic

Figure 3-1 The My Profile section of the Visual Studio .NET Start page

If you already have experience with Visual Studio 6.0, you can select a profile so that the layout of the screen and the key assignments used for functions such as debugging match the settings you’re accustomed to. Profiles are available to match the main Visual Studio 6.0 development environments?Microsoft Visual Basic, Microsoft Visual C++, Microsoft Visual InterDev, and Microsoft Visual FoxPro. If you’re new to Visual Studio, we suggest you select the default setting, the Visual Studio Developer profile.

Regardless of the profile you select and the language you choose to develop your application’s code, the development process essentially remains the same. First, you create a project, which is the collection of files that make up your application. Then you design your user interface by dragging mobile Web Forms controls onto the mobile Web Forms page, set properties on the mobile controls, and write code to implement the functionality behind the user interface. Finally, you build and test. And you perform all these activities within the Visual Studio .NET development environment.

Creating a Mobile Web Project

To create a project, you can click the Get Started option on the Start page and then click the New Project button. You can also create a project by clicking the File menu, pointing to New, and then clicking Project on the drop-down menu. The New Project dialog box appears, as shown in Figure 3-2.

Click to view graphic
Click to view graphic

Figure 3-2 The New Project dialog box

The left pane of the New Project dialog box allows you to select the project type. This pane offers one project type for each .NET language you’ve installed; the standard options are Visual Basic, Visual C#, and Visual C++. Once you select your preferred language, the templates displayed in the right-hand pane change to reflect that language. All the languages offer similar options and allow you to create Web applications, as well as options to create other standard solutions as Windows applications, class libraries, or Web services. Currently, Mobile Web Application templates are offered for the Visual Basic and Visual C# languages.

It doesnt matter which language you choose for your first project, since the application won’t require you to write code. Therefore, unless you have a preference, we suggest that you choose Visual C#. Click the Mobile Web Application option to highlight it, and then replace the suggested project name MobileWebApplication1 with the name MyFirstMobileApp. To do this, change the Location of the project from http://localhost/MobileWebApplication1 to http://localhost/MyFirstMobileApp. Visual Studio .NET updates the grayed out project name according to the location you enter.

Notice the text below the Location: input box. This informs you that Visual Studio .NET will create the project on the Web server at the location http://localhost/ MyFirstMobileApp on your development machine. When you click OK, the Create New Web dialog box appears, informing you that Visual Studio .NET is creating the new Web application at http://localhost/MyFirstMobileApp.

Visual Studio .NET now updates its various dialog boxes with information relevant to your project. The default layout will look like Figure 3-3.

Click to view graphic
Click to view graphic

Figure 3-3 Mobile project development environment

The main view is a tabbed view, which displays all the files that you’re currently working on, positioned one behind another. An asterisk next to the filename on the tab indicates that the file has been modified but hasn’t been saved to disk yet.

Whenever you create a mobile Web application, the New Project Wizard creates your project with the name you specified and creates mobile Web Forms that the MobileWebForm1.aspx file contains by default. This file is currently open and visible in the Mobile Internet Designer, which provides a graphical user interface (GUI) for designing mobile Web Forms.

Using Solution Explorer and the Properties Dialog Box

In Visual Studio, on the upper-right side of your screen, you’ll see Solution Explorer. This window lists all the files in your project. If you click the MobileWebForm1.aspx file listed there, the Properties dialog box on the lower-right side of your screen updates to reflect the properties of the currently selected object?that is, the MobileWebForm1.aspx file. This is a standard feature of Visual Studio .NET. Whenever you select an object, whether it’s a user interface control you’ve dragged onto the design area of your mobile Web Forms, a file in Solution Explorer, or any other object listed onscreen, the Properties dialog box updates so that you can easily change that object’s properties.

Although not essential, it’s a good idea to change the name of the mobile Web Forms file. When a browser accesses a Web application?mobile or otherwise?it does so by specifying that application’s URL. The URL of the application you’re creating is currently http://localhost/MyFirstMobileApp/MobileWeb-Form1.aspx.

You can also let users access the application by specifying the URL’s shorter form, http://localhost/MyFirstMobileApp, thus enhancing the application’s usability. To enable this functionality, you must change the name of the first file users will access to one of the standard default document names that IIS recognizes. By default, IIS sets the valid default names to one of the following: Default.htm, Default.asp, Iisstart.asp, or Default.aspx.

If IIS receives a request for a URL that doesnt specify a document, it will search the directory that stores Web site files for a file with a default document name. If IIS finds such a default document, it processes the document and returns the results to the caller; otherwise, it returns a Hypertext Transfer Protocol (HTTP) 404 (page not found) status code. Giving your entry form one of the default document names makes it easier for users to remember the shorter name for your Web site; that way, they no longer have to include a nonintuitive document name such as MobileWebForm1.aspx within a request.

Click MobileWebForm1.aspx in Solution Explorer to select it. In the Properties dialog box, locate the File Name entry and change it to Default.aspx. Figure 3-4 shows the result.

Click to view graphic
Click to view graphic

Figure 3-4 Setting file properties

Building the User Interface with the Toolbox

The project that Visual Studio .NET created will build and run. Of course, the application currently does nothing. You’ll now add a mobile control to the mobile Web Forms page so that your application displays a simple text message.

The Toolbox displays all the mobile Web Forms controls that you can use when designing your Web Forms. You can access the Toolbox by placing the mouse cursor over the Toolbox tab on the left margin of the screen. By default, this window is set to Auto Hide?it stays hidden until needed, rather than taking up valuable screen space. If you right-click on the Toolbox when it is visible, you can set or clear the List View option. When set to List View, the controls are presented in a list showing their full name; when List View is disabled, only an icon is displayed for each control. As you move your mouse over each control, the ToolTip displays the control name. The Toolbox is divided into a number of tabs, each containing related controls, as shown in Figure 3-5.

Click to view graphic
Click to view graphic

Figure 3-5 The mobile Web Forms Toolbox

Select the compartment called Mobile Web Forms, which contains the standard mobile controls, such as the Label, TextBox, Command, Image, and the validation controls. You’ll learn about these controls in more detail in Chapter 5.

An A icon denotes the Label control. You can click and drag this control onto the mobile Web Forms page. Notice that the Properties window now shows the properties of the Label control, which has an ID value of Label1 and a Text property value of Label.

In the Properties window, change the Text property to something more meaningful, such as the venerable, “Hello World!” Doing so updates the text displayed on the Label control shown in the Design view accordingly.

Building and Running Your Application

Visual Studio .NET offers many ways to build an application. Over time, you’ll probably develop a preference or find yourself using certain methods at certain junctures. You can use one of the following methods to build your project:

  • Go to Solution Explorer, right-click the solution name, and click Build on the pop-up menu.
  • Right-click the MyFirstMobileApp project line immediately below the solution name, and then click Build.
  • Click the Build menu, and then click Build.
  • Simply choose to run the application in Debug mode by clicking the Start button in Visual Studio, which automatically initiates a build before running it.

The project will then compile and you’ll see the build output display at the bottom of the screen, including details of any compilation errors.

To test your application, you can click the Debug menu. Then select Start, or click the Start button marked on the standard toolbar. Internet Explorer starts up and calls the IIS server to access your application, just as an external Web client would. Figure 3-6 depicts this process.

Click to view graphic
Click to view graphic

Figure 3-6 Testing the application with Internet Explorer

While Internet Explorer is active, Visual Studio is running in Debug mode. Therefore, after you view the output from the application, close Internet Explorer to return Visual Studio to Design mode.

Testing with a Mobile Phone Emulator

You’ll find Internet Explorer an adequate development tool for performing the initial testing of an application’s functionality. However, one of the most powerful features of the Mobile Internet Toolkit is that it can render your application on different client browsers, each with its own capabilities and possibly even requiring a completely different markup language.

You should test your application on devices that are likely to access it in the real world. You use the mobile Web Forms controls in your applications to carry out some function on a mobile device, however the actual physical appearance might differ from device to device. Furthermore, the Mobile Internet Toolkit allows you to customize your application to introduce device-specific behavior. For example, when you use the mobile Image control, you should supply images appropriate to each browser. In other words, you should supply GIF files for HTML browsers, color JPG or PNG files for advanced WAP browsers, and monochrome WBMP format graphics for older WAP devices. Clearly, it is crucial that you test your application on the different devices that are likely to access it.

Purchasing the actual mobile devices so that you can test your application with mobile clients can be an expensive undertaking. Fortunately, a cheaper option exists: installing software emulators (sometimes called simulators) on your development system. Because the Mobile Internet Toolkit doesnt install any device emulators, you’ll need to do this yourself. In Chapter 13, we look at how you get and use emulators in more detail, but to get you started, we’ll show you how to set up the Openwave simulator in this section.

Setting Up the Openwave Simulator

Openwave is the company formed from the merger of and was itself formerly known as Unwired Planet, which was responsible for devising the HDML markup language for mobile devices, a predecessor of WAP. Today, Openwave claims that 70 percent of the world’s Internet-enabled phones use their mobile browser software. The Mobile Internet Toolkit version 1.0 release includes support for devices from Alcatel, Motorola, Samsung, Sanyo, Siemens, Panasonic, Casio, Denso, Hitachi, Kyocera, LG, and many others, all of which use the Openwave browser?or its predecessor, the UP.Browser. Openwave has always been a good friend to developers, and many have cut their teeth with WAP development using the Openwave Software Development Kit (SDK). This kit includes a phone simulator, which you can use to test Mobile Internet Toolkit applications.

You can download the Openwave SDK free of charge from At the time of this writing, Openwave had recently released the SDK WAP Edition 5.0, which is targeted at developers building applications for devices with WML 1.3 browsers (with Openwave extensions), few of which are yet available, and will soon release V5.1, aimed at WAP 2.0 devices. However, we recommend that you download SDK 4.1, which includes a simulator with the UP.Browser V4.1, a WML 1.1 browser included with many devices in current use. The Mobile Internet Toolkit fully supports this browser.

After you install the SDK, click the UP.SDK 4.1UP.Simulator shortcut in the Programs or All Programs menu and you’ll see a phone image similar to the one shown in Figure 3-7.

Click to view graphic
Click to view graphic

Figure 3-7 The Openwave simulator

The phone image allows you to test mobile applications on a simulated mobile phone that accepts WML 1.1 markup. You can use this instead of or in addition to the integrated Internet Explorer browser.

Using the Simulator for Testing

During development, you can view a mobile Web Forms page in the Openwave simulator by entering the URL of the start page into the Go drop-down box, as shown in Figure 3-8. Figure 3-9 shows the functions of the Openwave simulator buttons.

Click to view graphic
Click to view graphic

Figure 3-8 Testing a mobile Web application with the Openwave simulator

Actual WAP devices always connect to the Internet via a special proxy, called a WAP gateway. This gateway acts as an important bridge between the wireless WAP protocols used by the phone and the HTTP over TCP/IP used by the wired Web. When you test with a real device, you must configure it to connect via a WAP gateway, operated by your wireless service provider, or in some cases, your company. Fortunately, the Openwave simulator includes gateway functionality within it, so you don’t have to worry about this when testing on your own workstation. The default configuration for the simulator is to connect directly to a server using HTTP protocols over the wired Web. To check that your simulator is configured like this, click the Settings menu of the Openwave simulator and then click UP.Link Settings. Check the HTTP Direct check box, as shown in Figure 3-10.

Click to view graphic
Click to view graphic

Figure 3-9 Openwave simulator button functions

Click to view graphic
Click to view graphic

Figure 3-10 Configure the Openwave simulator for direct HTTP access to your development server

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:



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

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:


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:


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:


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


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.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist