If you want to extend your existing systems as well as your knowledge of .NET development while building solutions for smart devices, the upcoming .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 to your existing systems, and also show you how to 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 during the weekly reporting ­ late Sunday night ­ into 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 anyplace? 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 we can help those 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) becomes 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 a set of extensions to VS.NET that enable 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 tool set 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.

However, we think that all enterprise .NET developers will have to manage development in both C# and VB.NET. Various projects will be run using each, and we think that 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 that even Java developers converting to C# will have a less painful migration than Visual Basic 6 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 what 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 anyplace and at any time.

The opening screen of the sample application (see Figure 2) shows a list of times reported for different activities (usually projects), which you can manipulate with the Add, Edit, and Delete buttons. You use the Save button to save all times reported and exit the application.

When you tap the Add or Edit button, you're presented with a new screen (see Figure 3). Here you can report or update an activity with date, project, and hours spent. Obviously, you save with the OK button and abort with the Cancel button.

The sample application allows the user to work offline using XML files. The Project ComboBox (see Figure 3) is filled from an XML file (projects.xml) and the reported time is saved in (and retrieved on startup from) an XML file (timereport.xml).

Code Walkthrough
Let's have a look at the code for the sample application. As we've already stated, our choice of language for the sample is C#, and we hope that most VB.NET developers will be able to follow the logic anyway.

(Authors' Note: We built our sample application using prerelease versions of Visual Studio .NET, .NET Compact Framework, and Smart Device Extension, and therefore it may not be compatible with the final release versions.)

One of the core features of the .NET CF is native support for XML. The code to populate the Project ComboBox in Figure 3 is in Listing 1.

As the ADO.NET DataSet has native support for XML, we can use this to load an XML file (projects.xml) containing the current projects. Each row's Name field in the DataSet (XML file) is then added to the ComboBox (cboProject). And if something goes wrong (such as that we can't open the file), we add a dummy project name instead. Finally, we select the first project as the default value. The project.xml file looks like this:

<?xml version="1.0" standalone="yes"?>
<Recordset>
<Project>
<Name>SDE Sample</Name>
</Project>
<Project>
<Name>Learn .NET CF</Name>
</Project>
<Project>
<Name>Learn SDE</Name>
</Project>
</Recordset>

In a similar way, the reported time is saved in an XML file (timereport.xml) each time the application exits. The code for the closing event of the main form looks like this:

DataSet dsTime = new DataSet();
dsTime.ReadXml(@"\Windows\timere
portempty.xml");
dsTime.Clear();

// Get data from ListView
foreach (ListViewItem lit in
lvwItems.Items)
{
DataRow dr;
dr = dsTime.Tables[0].NewRow();
dsTime.Tables[0].Rows.Add(dr);
dr["Date"] = lit.Text;
dr["Project"] = lit.Sub
Items[1].Text;
dr["Hours"] = lit.Sub
Items[2].Text;
dsTime.AcceptChanges();
}

// Save to XML file dsTime.Write
Xml(@"\Windows\timereport
.xml");

Again, an XML file (timereportempty.xml) containing the structure of the data is used to create the DataSet. Then the DataSet is cleared and each of the rows in the ListView (lvwItems) is added to the DataSet. Finally, and most elegantly, the DataSet is saved to an XML file (timereport.xml). The timereportempty.xml file looks like this:

<?xml version="1.0" standalone="yes"?>
<Recordset>
<Time>
<Date/>
<Project/>
<Hours/>
</Time>
</Recordset>

This is a very simple way of creating the structure of a new DataSet. We could create the DataSet using code for adding a table with fields, but it would require much more typing than if we create the XML file.

The resulting timereport.xml file (with the data from Figure 2) looks like this:

<?xml version="1.0" standalone="yes"?>
<Recordset>
<Time>
<Date>02/17/02</Date>
<Project>SDE Sample</Project>
<Hours>1</Hours>
</Time>
<Time>
<Date>02/18/02</Date>
<Project>Learn .NET
CF</Project>
<Hours>2</Hours>
</Time>
<Time>
<Date>02/19/02</Date>
<Project>Learn SDE</Project>
<Hours>3</Hours>
</Time>
</Recordset>

(Authors' Note: The project.xml and timereportempty.xml files are required to be available on the device [emulator or physical] in the \Windows folder to make the sample application work. You have to download this file to the device before you run the sample. The timereport.xml file will be created on application exit, but you will get a message box telling you that it's missing on application start.)

The native support for XML makes working with data in XML files very efficient, and for some applications this is the only local storage you'll ever need. For more demanding scenarios, you'll need to handle local storage through a relational database like SQL Server for Windows CE.

Communicating Between Forms
Another interesting feature of .NET that we'd like to cover is the way you can communicate between forms. As a Visual Basic 6 developer, you had to build your own plumbing to make forms talk to each other, usually by implementing a custom public method for showing the form. Your pain is over! To demonstrate, let's have a look at the code behind the Edit button in Figure 2:

frmTimeReportItem frmItem = new
frmTimeReportItem();

frmItem.Date = lvwItems.Selected-
Items[0].Text;
frmItem.Project = lvwItems.Select-
edItems[0].SubItems[1].Text;
frmItem.Hours = lvwItems.Selected-
Items[0].SubItems[2].Text;

if (frmItem.ShowDialog() ==
DialogResult.OK)
{
lvwItems.SelectedItems[0].Text =
frmItem.Date;
lvwItems.SelectedItems[0].SubItems[
1].Text = frmItem.Project;
lvwItems.SelectedItems[0].SubItems[
2].Text = frmItem.Hours;
}

We start by creating the subform (frmTimeReportItem, shown in Figure 3) and setting the public properties Date, Project, and Hours from the currently selected row in the ListView. We then show the form with the ShowDialog method and if the return value of that call indicates that we tapped the OK button, the ListView is updated from the same properties. Here's the implementation of the Project property in the frmTimeReportItem form:

public string Project
{
get
{
return cboProject.Text;
}
set
{
cboProject.Text = value;
}
}

The property simply gets and sets the Text property of the Project ComboBox (cboProject). To make this work, we have to make sure that the ComboBox is loaded before we access the property. That's why the code to load the ComboBox is placed in the constructor of the form class.

To make the ShowDialog method return different values for different buttons, you simply set the AcceptButton and CancelButton properties of the form. This code comes from the InitializeCom-ponent method in the code generated by the forms designer:

this.AcceptButton = this.btnOK;
this.CancelButton = this.btn
Cancel;

For a complete example, you should download the sample code for this article from www.sys-con.com/dotnet/sourcec.cfm.

Lessons Learned
The really cool thing with this sample is that the code we've shown you so far is nearly all that you need write by hand. Most of the remaining code is generated by the project template and forms designer. The complete sample is less than 100 lines of code ­ including the lines with only a "{" or a "}".

The version of the SDE we've used (the tech preview released at Microsoft's Professional Developers Conference in November 2001) didn't include a forms designer. But interestingly this taught us something about how easy it is to migrate a desktop Windows application to a smart device like the Pocket PC. We started to build the sample as a native Windows application, then copied the forms into a smart device project and made some minor changes ­ and there we were with a working sample application! The minor changes in the .NET Framework and .NET CF Object Models were efficiently pointed out to us by the compiler and were easily corrected.

In the version of the .NET CF that we used there was no NumericUpDown control ­ it would've been nice for entering Hours (see Figure 3). On a mobile device like the Pocket PC, the goal is always to minimize user input, and tapping of up and down arrows ­ rather than entering numbers from the soft keyboard (or letter recognizer) ­ will speed data entry significantly. However, replacing the TextBox control when the NumericUpDown control becomes available is no more than a minor adjustment.

The device used to test the sample was a Compaq iPAQ 3650 upgraded to Pocket PC 2002. The sample worked fine in the emulator, too. It should run on a standard iPAQ (with Pocket PC 2000) as well.

Extending Existing Systems
The sample application assumes there's an XML file with all ongoing projects (projects.xml), and updates an XML file (timereport.xml) with the reported time. In a real-world enterprise scenario, these files would be synchronized with a central time-reporting system on a server. One requirement is that the central time-reporting system must be able to handle import and export of XML ­ are there any of those around today that can't?

Conclusion
If you want to extend your existing systems, as well as your existing knowledge of .NET development while building solutions for smart devices, the .NET CF and SDE are the way to go. All you have to do now is get started with extending your existing systems, and you'll be off building mobile enterprise .NET solutions!

Even if this is a great first step toward extending your time reporting to "anyplace," the next logical step would be to make the synchronization with the server in a standardized way. The way we're thinking of involves another core part of .NET Web services. However, it requires that the server system be able to handle Web services. If you have a server with Windows, this is most certainly doable, and might even make a great subject for a future column.