There has never been an operating system release more important to .NET developers than the release of Windows Mobile Version 5.0. With this release, Microsoft is poised to take your productivity in writing mobile applications higher than it has ever gone before. Rich multimedia capabilities, integrated messaging, and world-class telephony support are just a few of the benefits you will realize when you develop applications for the Windows Mobile 5.0 platform.
From the perspective of the .NET software developer, perhaps the most important piece of Windows Mobile 5.0 is its brand new Managed API. All of the code for this new API is found in the Microsoft.WindowsMobile namespace. You can access this API from Visual Studio by adding references to the following assemblies:
My most recent acquisition is a Windows Mobile 2003 Second Edition-based Smartphone. The Smartphone is an amazingly capable device that allows me to send and receive MSN Messenger messages, take pictures, and run software written using the .NET Compact Framework, in addition to the traditional telephony functions of placing and receiving telephone calls.
Before Windows Mobile 5.0, however, Windows Mobile Software for Pocket PC Phone Edition or Smartphone did not support direct access to telephony functionality via a managed API. So prior to Windows Mobile 5.0, if one wanted to create a .NET Compact Framework application that, for example, dialed a given telephone number, one would typically have had to access a native API for this purpose via .NET's p/Invoke functionality.
Windows Mobile 5.0 addresses this by providing a namespace called Microsoft.WindowsMobile.Telephony as a part of its base functionality. At the time of writing, this namespace consists of a single class called Phone, which exposes a single method, called Talk. Talk takes a String parameter representing the telephone number to be dialed, plus an optional Boolean parameter specifying whether or not the user should be prompted prior to dialing.
For example, the following line of C# code will dial the number for operator assistance in most major U.S. cities. Prior to dialing, however, a confirmation dialog will be displayed to the user.
new Phone().Talk("555-1212", true);
Prior to Windows Mobile 5.0, there was no managed interface for Outlook Mobile. To be sure, alternative approaches for accessing contacts under Windows Mobile have been developed. Developers could native code, p/Invoke, or - under Visual Studio 2005 - use COM Interop to tap into the rich messaging and contact management functionality provided by Outlook Mobile. Third-party vendors (see Resources at the end of this article) have also developed and sold Outlook Mobile access libraries for the .NET Compact Framework.
With the release of Windows Mobile 5.0, developers for the first time have a managed API baked directly into the operating system to facilitate all Personal Information Management (PIM) functionality available in the Windows Mobile operating system.
To briefly summarize the kinds of classes in as few words as possible, consider the path that a message will typically take from Outlook Mobile to a recipient aw well as its path in the opposite direction. The trip begins (or ends) with either an e-mail or an SMS account, because these are the two protocols supported by Outlook Mobile. For this reason, there are EmailAccount and SmsAccount classes in the PocketOutlook namespace.
To create an actual message, there are EmailMessage and SmsMessage classes, as well as classes for working with such messages' associated entities. For example, there are classes for things such as recipients and attachments. A brief example of sending an e-mail using some of these classes is shown in Listing 1.
Listing 1 begins by creating an Outlook Session. This is a central class in working with Outlook Mobile's managed API, and you will generally always instantiate this class whenever you work with Outlook Mobile.
We then instantiate an instance of EmailMessage to represent the message we wish to send, and an instance of Recipient to represent the person to whom we wish to send our message. We set the text of the message's body, associate the recipient with the message, then use the account named "PersonalAccount" (which we got from the Outlook Session) to send our e-mail.
Besides messages, Outlook Mobile also facilitates the tracking of appointments and tasks. There are classes for both of these things, as well as a host of supporting classes for details such as their recurrence schedules.
Finally, many of the classes described above also have collection classes for dealing with their instances as a group. TaskCollection, ContactCollection, and Appointment-Collection would be good examples of such classes.
The class that allows a developer to build this kind of functionality in Windows Mobile 5.0 is known as MessageInterceptor and lives in the Microsoft.WindowsMobile.PocketOutlook.MessageInterception namespace. This namespace is all about writing code that waits to receive a message, and then performing some kind of work.
The workflow to achieve this is fairly simple. First, one must instantiate a MessageInterceptor object. There are two main points of interest on this object. First, its MessageCondition property allows a developer to specify the kind of message to which such an object should respond. The interceptor can be set to respond to a message with a Body, Sender, or Subject that matches - or explicitly doesn't match - a given value.
The other interesting feature of this class is its EnableApplication-Launcher method. By calling this method, you can register your application to be launched when a specified message is received. This allows you to intercept messages without having to keep your applications running in the background.
To set the stage for this discussion, let's assume that you manage a group of volunteer authors while on the road traveling between your client's city and your home, and it's time to start planning the next issue of your magazine. (This should sound familiar to Derek!) You open up your application on your Windows Mobile 5.0-based device, go to the Start New Issue screen, and start entering data.
One of the enhancements that consumers will notice immediately with Window Mobile 5.0 is that of Outlook Mobile. With the managed interface to this functionality, developers will obviously build PIM and business applications that extend the notion of Contacts. Also, since this application stores the authors as Contacts, we'll use the ChooseContactDialog class to select the authors for this issue. The ChooseContactDialog class does several different things with Contacts, so we'll set up the properties to only select the Contact and then call ShowDialog to get the window started. (See Listing 2 and Figure 1.)
Later, the magazine editor might want to send the author's picture to the printing company. As you'll find out, Windows Mobile 5.0 has an application for selecting and viewing images - and we can use that too. The SelectPictureDialog class provides intuitive functionality like setting the directory to look in, controlling the folder navigation, the title to have on the selection screen, and the chosen image. (See Listing 3.)
Finally, let's say that the magazine editor is at a conference and recruits a new author. The editor knows that at some point that we'll need a headshot. Instead of having to ask later, the editor decides to take advantage of our application and use the integrated camera. By building a screen that calls the CameraCaptureDialog class the application will interact with the device's built-in camera and provides an image file of the author. This is a huge improvement over having to P/Invoke into the OEM's camera API DLL, if they provided one.
If SystemState.ActiveSyncStatus =
ActiveSyncStatus.Synchronizing Then
'Wait for new files
End If
Another way to interact with these properties is to have the SystemState class deliver a notification about a monitored property. For example:
Dim oStatus As New SystemState(System Property.PhoneGprsCoverage)
AddHandler(oStatus.Changed, addressof me.GprsCoverageChange)
The SystemState class also exposes an EnableApplicationLauncher method similar to that exposed by the MessageInterceptor class described above. The difference is, however, that the events that can trigger an application's launch using this method are much more diverse than simply the receipt of a given e-mail or SMS message. This is functionality that many desktop Windows developers would envy!
There are more topics for discussion in the Status namespace. However with these three options, I believe that the SystemState class will be of great interest to those of us who have already been working with the .NET Compact Framework.
For the many of you who will need to support Outlook Mobile integration prior to .NET Compact Framework 2.0, check out this product.
