If you attended MDC or saw any of the agenda you'll know that we're working hard on providing some great managed classes in the next platform release of Pocket PC and Smartphone. Two big pieces of these are managed access to PIM data and managed access to SMS and e-mail. Right now we have a lovely object model that integrates all this Outlook data into one unified namespace.

Garrett, one of our messaging developers, has a native API that allows you to drive the messaging application via a simple set of APIs. This is handy if you're a developer and want to kick off the mail application's compose form with some pre-filled fields, or if you want to force an account to synchronize. Traditionally this has been accomplished with command-line arguments, which is clunky. Garrett's new native API is much, much nicer.

The problem currently on my plate is how to design a managed version of this API. My initial design was to simply build a new object in our Outlook namespace called “MessagingApplication” to allow for the automation of the messaging application. All of the methods in the class are static which makes calling them a breeze:

using Microsoft.WindowsMobile.PocketOutlook;
MessagingApplication.DisplayComposeForm(”ActiveSync”, “neile@online.microsoft.com", "Comments on your lame blog entry");

This will bring up a compose form for the ActiveSync transport with the to and subject lines filled in. There are, of course, many overloads for this to deal with things like attachments, body text, cc, and bcc fields.

When I sent the API out to a select group of people to review Robert gave me a ton of grief. Why, he wondered, didn't we just put all of these methods onto existing objects? So, for example, to display the compose form you'd do the following:

using Microsoft.WindowsMobile.PocketOutlook;
EmailMessage myMessage = new EMailMessage();
myMessage.To(new Recipient("neile@online.microsoft.com"));
myMessage.Subject("Comments on your lame blog entry");
myMessage.Display("ActiveSync", MessageForm.Compose);

Well, this prompted a spirited debate by e-mail and then in a meeting this morning. Here are the notes from the whiteboard. The first is a list of all the things we could dream of doing that fell into the class of "application automation". The second is what we came up with for pros and cons of each approach.

So, the question to all of you is: what do you think? Go with application objects? Go with adding them to our existing Managed Outlook objects? Or some blend the two? Comment away!

[Author: Neil Enns]