Excerpted from the Preview Issue of .NET Developer's Journal.

If you want to extend your existing systems, as well as your knowledge of .NET development, while building solutions for smart devices, the forthcoming .NET CF (Compact Framework) and SDE (Smart Device Extensions) are definitely the way to go.

In this article we provide an example of how to implement a mobile application that can work as an extension of your existing systems, and help you extend your knowledge of .NET development.

It's perhaps more true than ever that mobile solutions rarely stand alone. Most consumer-oriented applications are created to work in an offline or disconnected mode, but for enterprise solutions the increasing connectivity of new devices opens up enormous possibilities for online and "sometimes connected" applications as well.

When looking at real-world business scenarios and the capabilities of current mobile devices, it's obvious that the options are greater than just offline or online. Specific user requirements such as "how often?" and "at what bandwidth?" should determine where on the scale from offline to online we need to be (see Figure 1).

The more a mobile application is connected, the thinner it can be from an application logic and local storage perspective. The less it's connected, the higher the demand on the application logic and local storage. A typical online mobile application is a Web application targeted at smart device browsers like Internet Explorer for Pocket PC. With a Web application there are no deployment issues for the device, as the browser is already in place. However, most other connectivity options (from "auto-connected" all the way to "never connected") require you to have a custom application running on the device.

The need for connectivity also implies that we're most often talking about extending existing systems to anyplace. Many workers are currently tied to a desk with a PC on a wire. They would like to be free to go wherever they want, yet still be able to perform their duties. Is it asking too much to help those poor people out?

Consider Some Examples

Let's take a simple scenario like reporting time. Many mobile workers have to specify how they spend their time during their work hours. This is a common task in an enterprise environment, and many of us are familiar with the pain of "re-creating" the past week for the weekly report - late Sunday night - in our company's central time reporting system. Why? Because we have to wait until we find a PC that's wired to the company network. What if we could do it anywhere? And since we don't need to do the actual reporting more than weekly, it would fall into the category "seldom connected" (see Figure 1). What if we didn't actually have to be connected when we do it?

Another issue is how to help workers get the new tools of the trade. What if we could use the same knowledge that we already have in building our enterprise solutions? In the not too distant future, most of those solutions using Microsoft technology will be developed for .NET, and therefore it would be great if we could extend .NET and .NET development skills to build those solutions for mobile devices. As you may already know, you'll soon be able to do just that.

Build a Business Case

In defining how we can benefit from turning paper-based processes into mobile solutions, the keywords are speed and quality.

First of all, since time is money, we want to save time. By saving time we can get an instant payback on the investment in most mobile solutions. We can save time for the mobile worker, and most probably also for the back-office personnel who now enter submitted paper data into a system. Perhaps most importantly, we could also save the time between data entry and data usage. For example, if the time reported was submitted each day instead of each week, we could expedite invoices related to that time.

Second, we'll collect the data at the source, gaining speed in our business and improving data quality. Writing data on paper, then passing it to someone else to read and enter into a system is probably the most certain way to achieve poor-quality data. Higher quality most often translates to saved time, and also to improved relationships with customers, partners, and even employees.

What we're trying to say is that if you want to build a successful mobile solution, do your homework - document the business case behind the solution. Most often, if you just spend some time thinking it through, it's not very hard.

Technology Overview

So, what is enterprise .NET development for smart devices? If we look at the connectivity options for an application (see Figure 1), we sometimes want to build a thin browser-based Web application, in which case we would probably use a tool like Microsoft Mobile Internet Toolkit with ASP.NET. But for most other connectivity options, we need something that provides a solid development environment on the device. This is why the upcoming release of the .NET Compact Framework and Smart Device Extensions for Visual Studio .NET (VS.NET) is so interesting.

.NET CF is a subset of the full .NET Framework. Careful thought has been put into selecting the classes that make the most sense on a mobile device, taking into account the smaller footprint required on devices and the accompanying memory and performance restrictions. It includes a CLR targeted for smart devices.

SDE is an extension to VS.NET that enables you to build applications for the .NET CF. The extensions include profiles that customize VS.NET for smart device development. For example, when targeting the .NET CF, you get IntelliSense for the supported classes and only supported controls are available in the toolbox.

For enterprise developers, this means that we'll now get back to the state where there's a single toolset for building applications for PCs and smart devices like Pocket PC and the coming SmartPhone 2002.

C# or VB.NET?

There's been much discussion on the selection of a development language for VS.NET. As we've made a choice to implement our sample application in C#, we've stated our premium choice of language.

That said, we think that all enterprise .NET developers will still have to manage development in both C# and VB.NET. Various projects will be run using each, and we think the choice will most often be made in relation to historical issues rather than technical issues like performance or productivity, or even issues like speed of development and ease of maintenance.

Traditional Visual C++ developers and even Java developers will probably select C# as their premium choice, and we think even Java developers converting to C# will have a less painful migration than Visual Basic 6.0 developers will have converting to VB.NET.

The interesting part of .NET is not the languages, but the framework. Despite the excellent language interoperability in .NET, we don't recommend mixing languages in the same project if you can avoid it.

Time Reporting Example

To show you want we mean, we've put together a sample application to report the time you spend on different activities. With this simple tool, you can report your time anywhere and at any time.

This is an excerpt from the complete article featured in the printed Preview Issue of .NET Developer's Journal. To read the article in full, subscribe now. With your subscription confirmation, you'll get the online password to read this and other .NETDJ articles. You can also look for the special preview of the print edition of .NET Developer's Journal on newsstands and in bookstores. Both the print Preview Issue and the online archives are available now.