No two ways around it, mobile development is hard. I've often referred to it as first trying to verbalize some complex topic such as the meaning of love, the definition of consciousness, or the reason people watch America's Most Wanted, and then deciding you want to do it in the form of a sonnet. Then, once you are nearly done, you realize you need to translate it into three different languages and half a dozen dialects.

Let's look at some of the specific challenges of mobile development.

The Form Factor Challenge. The biggest challenge of developing mobile applications centers around those dinky little screens. I can barely read a phone number on most of them, and somebody seriously thinks I can access my corporate ERP app on it. Well, you can�but you need to carefully consider usability when you are developing your application and remember that users may be able to see only a little bit of information at one time.

Displays on mobile devices range from two-line cell phones up to roomy (relatively speaking!) PDAs such as the Microsoft PocketPC. Because of all the different screen sizes, getting the pagination right for all the devices becomes a nightmare�what looks good on one device won't work well on another. Besides the variety of screen sizes, orientations vary: some are landscape, while others are portrait; some are even square. It gets really messy when you consider MP3 and WMA players with their painfully hip designs.

Capability Issues. Besides the issues involving screen real estate, each of these devices has different capabilities. First off, sticking with display issues, you need to support devices that can display images and color all the way down to those devices that can handle only black-and-white, plain text. Next, some devices can process forms and both send and receive data, while others only display messages. (Some devices are send-only such as barcode readers and the package tracking devices used by overnight delivery services, but I won't address them here because you can work them much the same way you currently process standard user input.)

Because they are battery powered, these devices have limited CPU cycles available and (except for PDAs) no local storage to speak of. However, the data processing capabilities of these mobile devices vary greatly. At one end of the spectrum are browsers that can do nothing but render markup. At the other end you have the Microsoft PocketPC that not only can run scripts and process XSLT but also has a local copy of Microsoft SQL Server� 2000 CE Edition that you can use for complex, client-side applications.

Finally, most devices contain inherent capabilities that you really must leverage. For example, if an end user is working with a phone to search for a coworker on the corporate directory, you should give him or her the ability to directly place a call rather than forcing the user to key in the number.

Bandwidth Issues. Related to a device's capabilities is the bandwidth available to it. There are really three separate issues (throughput, latency, and reliability) you need to be aware of here, but let's lump them together to keep things simple. While some geographies (notably Europe) have high-speed wireless networks, most devices rely on circuit-switched networks, so you are often limited to 9600 baud with latencies reaching into the seconds. The point here is you need to be very economical in what you send down to the browser even in a case in which the client is a rich device.

Worse still, as you know from your standard cell phone, wireless connections are not what one would call robust, so your application will need to gracefully recover from dropped connections. Because connections occasionally (okay, often) drop, mobile devices have pretty aggressive error correction and will drop into recovery mode quickly if your server-side logic takes too long, causing the device to think it is disconnected. What is the typical recovery mode of a device, you ask? Oh, simple: just resend the last request. D'oh! Now you have twice the load on your already slow page and need to make sure you don't process transactions twice.

Markup Challenges. In addition to all the physical challenges of working with mobile devices, you also have to contend with three different markup languages and protocols in widespread use.

First off, you have standard HTML over TCP/IP supported by the Microsoft PocketPC and some of the other rich devices. Second, you will need to support compact HTML (cHTML) used by NTT DoCoMo's i-mode service and its 25-million-plus subscribers. You can look at cHTML as a subset of standard HTML. It supports most of HTML 3.2 except for the tags required for frames, tables, style sheets, and fonts.

Third, you will have to contend with wireless market language (WML) defined by Nokia, Motorola, Ericsson, and Unwired Planet and used by wireless application protocol (WAP)-enabled cell phones. Unfortunately, WAP is, as you would expect from it's name, a protocol. It is similar to TCP/IP but is optimized for low bandwidth, and noisy and unreliable connections. It also has a number of phone-specific enhancements, such as processing voice calls in addition to data and the ability to understand and manipulate address books. Because it is a protocol, it presents yet another barrier to development�you can't just hook up any device with a TCP/IP stack (say, a PC with your development environment), test your app, and debug it using your standard set of tools.

State Management. State management is always hard for Web applications, but it poses a special challenge for mobile applications. Most mobile devices don't support cookies, which has been the traditional tool developers have used to maintain state. The role of state management is particularly important in mobile applications because of the possibility that the device will resubmit a post if it thinks it has been disconnected. Without access to state information (such as a unique ID buried in a cookie), it is difficult for the device to determine whether a given submission is a duplicate or not. Additionally, the lack of view state is often a frustration for users of mobile devices because data input is so difficult; having to triple key all the data on a form once is bad enough, but having to do it a second time because of a validation error or a dropped connection is downright frustrating.

Tough stuff, huh? Well, that's all the bad news. On to the good news.

I mentioned earlier in rather vague terms that the MMIT abstracts the user interface. Now that you know what the specific challenges around mobile development are, let's take a closer look at the architecture of MMIT and see what this means. There are two main components to the MMIT: controls and device adapters.

Controls. Controls are the elements that you, as a developer, interact with at design time. Just as you do with Web and Windows� forms, you use these controls to develop your application's logic, define properties and methods, and respond to events. A key feature of mobile controls is that they are totally device independent; you use the same controls for a list box or a calendar whether the client device is a WAP phone or a full-fledged HTML browser in a PDA. In my earlier desktop analogy, the controls are the productivity app.

Device adapters. The device adapters are responsible for taking the program logic and user interface you defined in the controls and rendering them using the markup language and protocol supported by the connecting device. Going back to the desktop example, the device adapters are analogous to printer drivers. As you can see in Figure 1, at runtime ASP.NET sniffs the client and figures out what type of browser the user is running. As ASP.NET processes each control on the page, it passes the control off to the adapter that matches the connecting device. The adapter then renders the markup and passes the rendered information back to Internet Information Server (IIS) for transmission to the client. The key point to remember is that all the device-specific information is in the adapter and all the program functionality is in the control.

Figure 1: A single mobile Web forms page can support multiple different devices.

What is really cool is that besides simply rendering the markup that the device supports (HTML, WML, cHTML), the device adapter also presents it in a form that is appropriate for the form factor. The calendar control shown in Figure 2 is a great example of this. If you connect to a page with a calendar control from a full HTML browser such as the one in the Microsoft PocketPC, it will display the full month, and let you pick the date you want. On the other hand, if you connect from a WAP phone with only a few display lines, the calendar control will guide you through first picking the month, then the week, and finally the specific date.

Figure 2: The Mobile Forms calendar control renders differently depending on the type of mobile device. In IE it displays an entire month at once, while on a WAP phone you need to drill down to get the date.

Here is the really cool part. This didn't take a single line of code; in fact, I created the entire �application� with nothing more than a mouse.

To create this application yourself, first make sure you have your environment set up properly. You will need IIS 5.0 or later and Microsoft Visual Studio .NET. Next, install the Microsoft Mobile Internet Toolkit and the Microsoft Mobile Internet Toolkit Hotfix. While you can run Mobile Web Applications in the desktop version of Microsoft Internet Explorer, you will probably want to download some emulators. Here is a list of the ones I used; notice that some of these pages may require registration, but they are all free.

• Pocket Internet Explore Emulator, which you can get as part of the Microsoft eMbedded Visual Tools 3.0.
• UP.Browser Simulator from the Openwave SDK.
• Nokia WAP Simulator from the Nokia Mobile Internet Toolkit Version 3.0

You can probably get by with just IE and the UP.Browser because that will cover the majority of the market but, because of the variability of the WAP implementations, I always try a couple of different WAP simulators.

Here are the four easy steps to your first mobile application:

1. Fire up Microsoft Visual Studio .NET.
2. Create a new Mobile Web Application project.
3. Drop the Calendar control on the Form1 on the design surface.
4. Start your application to see it run in Microsoft Internet Explorer.

In about thirty seconds, you will have your first Mobile Web Application. Granted, it doesn't do much of anything; you still need to implement the program logic (for example, to book an appointment on the date the user selected), but that is part of the point. Any logic you would create from here on out would be exactly the same regardless of whether you were targeting a Web Forms, Windows Forms, or Mobile Web Forms application. What I have demonstrated here is exactly how easy it is to build a UI that works on multiple devices. Just think how much code you would have written had you coded that by hand. That month, week, day drill-down alone is good for a couple of hundred lines when you consider all the looping logic and exception cases you would need to deal with. And that doesn't even include having to deal with all the markup language muck.

Now that you have an overview of Mobile development, you should be ready to dive in and start developing your own real applications (with functionality). I started off this article by describing some of the challenges with traditional mobile development such as variable form factors and limited bandwidth. Next I walked you through the Microsoft Mobile Internet Toolkit and showed you how it addresses these issues. Finally I created a Web page with calendar control and showed you how the MMIT takes care of rendering it on various types of devices.

For the best way to see exactly how easy developing mobile applications can be using Microsoft .NET, you should get a copy of Building .NET Applications for Mobile Devices by Andy Wigley and Peter Roxburgh.

Microsoft Press� provides in-depth documentation for these and all the other issues related to developing for .NET. For a complete list of .NET titles from Microsoft Press, see the Inside Information About Microsoft .NET page.

To learn more about object-oriented programming, you will want to check out Robin A. Reynolds-Haertle's OOP with Microsoft Visual Basic� .NET and Microsoft Visual C#� .NET Step by Step. In addition to a very clear explanation of OOP theory, Reynolds-Haertle includes some excellent, real-world examples and design tips on such complex issues as serialization and refactoring.

If you are new to Microsoft Visual Basic, you will probably be interested in Microsoft Visual Basic .NET Step by Step by Michael Halvorson. This is a great guide that quickly shows you how to build both Windows Forms and XML Web Service applications the right way. This book covers everything from upgrading from Microsoft Visual Basic 6.0 to optimization techniques to deploying your application.

Another great book for more experienced Visual Basic developers is Coding Techniques for Visual Basic .NET by John Connell. This book goes beyond simple examples designed to teach you the language; it focuses on demonstrating key techniques to help you ship professional-level code.

For book and information on Web Services, check out the Microsoft .NET XML Web Services page.

For more information on Microsoft Visual Studio .NET, see the Visual Studio Next Generation home page.