Sometimes we tend to forget just how useful the Smart Device Framework really is.  There are tons of little gems in it that we put in there, some times years ago, and then we forget about it.  I have a general idea of what all is there, but by no means can I tell you everything, so when I need a feature in an app, I always go look to see if we've already done it.

Unfortunately we tend to lack concrete examples of how a lot of it can help you in your everyday work.  In an effort to rectify that, over the coming months all of us here at OpenNETCF will be blogging short snippets of cool, useful stuff you can do.  We also are taking requests.

So here's one.  

Problem
I have a device and we want to know when a storage device (USB, CF, PCMCIA, SD, etc.) is either inserted or removed.  What does the SDF do for me?

Solution

[Developed and tested on an OLDI 56SAM-400 800MHz x86 device running CE 5.0]

private DeviceStatusMonitor m_diskMonitor;

public MyClass()
{
    ...
    m_diskMonitor = new DeviceStatusMonitor(DeviceStatusMonitor.FATFS_MOUNT_GUID, false);
    m_diskMonitor.DeviceNotification += FATMounted;
    m_diskMonitor.StartStatusMonitoring();
    ...
}

~MyClass()
{
    m_diskMonitor.StopStatusMonitoring();
}

void FATMounted(object sender, DeviceNotificationArgs e)
{
    Trace2.WriteLine(string.Format("FAT device '{0}' {1}mounted", e.DeviceName, e.DeviceAttached ? "" : "un"));
}

The DeviceStatusMonitor ctor's first parameter can be a few things - I've chosen FAT file system (we can detect a CD too!).

The thing I don't understand is how the hell this class ended up in the OpenNETCF.Net namespace.  Expect that to change in 2.2.  I'll probably deprecate the existing classes with a warning and move them somewhere that it makes sense.  I may also streamline the usage as well.

Today someone asked how they might enumerate all files and folders on a device.  The concept is pretty simple, and implementing it with a recursive algorithm is straightforward.  To make it a bit more useful I'm adding the items to a TreeView and saving the full path to the display file/folder in the TreeNode's Tag property, so when a node is selected, you don't have to reassemble the path.

Code:

public void GetListOfAllFilesAndFolders(TreeView view)
{
    view.BeginUpdate();
    view.Nodes.Clear();
    TreeNode node = new TreeNode("My Device");

    AddFolderToTreeNode("\\", node);
    view.Nodes.Add(node);
    view.EndUpdate();
}

private void AddFolderToTreeNode(string rootPath, TreeNode rootNode)
{
    // add in all directories
    string[] dirList = Directory.GetDirectories(rootPath);

    foreach (string dir in dirList)
    {
        TreeNode node = new TreeNode(Path.GetFileName(dir));
        node.Tag = dir;
        AddFolderToTreeNode((string)node.Tag, node);
        rootNode.Nodes.Add(node);
    }

    // add all files
    string[] fileList = System.IO.Directory.GetFiles(rootPath);

    foreach (string file in fileList)
    {
        TreeNode node = new TreeNode(Path.GetFileName(file));
        node.Tag = file;
        rootNode.Nodes.Add(node);
    }
}

Usage:

GetListOfAllFilesAndFolders(treeView1);

Yes, It's that simple.

NOTE: I tested this on an OLDI 56SAM-400 800MHz x86 CE device running CE 5.0 so your mileage may vary.

If you've done much development on non-Windows Mobile CE devices I'm sure your painfully aware of the pain in the ass process of getting Visual Studio 2005 to actually attach to the device.  Lately I've been doing nothing but non-WM development and deviced to automate and solidify the process, plus document it while I was at it.

We've got a (native) tool called CEDbgSetup that you run on your device (x86 or ARMv4I supported) and then you set up Studio once and only once, then you can debug every time using wired Ethernet, 802.11, USB RNDIS (and likely any other transport that uses TCP/IP) and without ActiveSync.

The tool supports auto-launching from \Windows\Startup or by setting up an LaunchXX entry in HKLM\Init in the device registry, or just manual click.  It should work headless too, though I've not specifically tested it.

It works with native or managed apps.

The tool, along with full source can be downloaded here (607k zip).

A white paper on how to set up Visual Studio 2005 can be viewed here (144k PDF).

Feedback is appreciated, but keep in mind that its free and completely unsupported (read: don't ask me for support).

Another feature that missed the 2.1 cutoff - we've added a couple things to our existing EventWaitHandle:

A Set() overload:
public bool Set(int data)

A GetData method:
public int GetData()

For simple, fast, and really easy to implement IPC you can just do this:

Process A
EventWaitHandle wh = new EventWaitHandle(false, EventResetMode.AutoReset, "MY_EVENT_NAME");

int myData = 10;
wh.Set(myData);

Process B
EventWaitHandle wh = new EventWaitHandle(false, EventResetMode.AutoReset, "MY_EVENT_NAME");

I know, SDF 2.1 has only been out for a day, but we're always working on the code base.  I just wrapped up a namespace that didn't make the 2.1 cutoff: OpenNETCF.WindowsCE.Services.  It allows you to enumerate, start, stop, refresh, load, unload, set the debug mask and register for autostart any service on the device.

Moving forward we're trying to componentize the SDF, so this one is stand-alone with no additional dependencies (not even the core OpenNETCF.dll library)

Here's a screen shot of my test/sample harness:

SDF 2.1 Preview - Get LIT

Ever have a business scenario where you want your application to perform some task on a periodic basis but the period will be very long - maybe days, weeks or even months?  You want it to occur if the device is asleep or aware at the time?  Well we've got a new SDF class that's designed for this: the LargeIntervalTimer (or LIT).

Let's look at a simple scenario.  Let's say I'm writing a custom calendar.  I want to set up a recurring meeting.  Well let's say the first meeting will be tomorrow at the same time as it is now (for simplicity) and then every 7 days after that.  We want the device to do something on that period (presumably make a noise, vibrate or whatever. 

The LIT is specially designed for this type of scenario.  The code to do achieve that scenario would look like this:

// we want the first timer event o happen 1 day from now
m_lit.FirstEventTime = DateTime.Now.AddDays(1);

// after the first event, we want it to fire every 7 days
m_lit.Interval = new TimeSpan(7, 0, 0, 0);

// we want it to be recurring
m_lit.OneShot = false;

// wire up a handler
m_lit.Tick += new EventHandler(LIT_Tick);

// start the timer
m_lit.Enabled = true;

That's it.  No P/Invokes.  No ugly Notifications, threads, events or whatever.  We've swept all that ugliness under the rug for you so all you need to do it implement your app.