The Windows 7 sensors platform exposes a standard way of communicating with hardware for determining location, light, magnetic north (compass), distance, movement, and much more.  Through the accelerometer, movement is measured as force (G's) in up to three dimensions.  The Freescale Badge board that I use for sensor development includes ambient light, touch, and a 3D accelerometer.

Working with the three axes of accelerometer data is incredibly easy.  Each sensor data report indicates the number of G's felt along each axis.  You can watch the values of movement in order to know more about the environment.

My first thought with this application was to create a seismometer to measure ground tremors, but I'm not so sure the one that I have would be nearly sensitive for that.  Then it occurred to me that the accelerometer would work great to detect a laptop being moved.  I see people leaving their laptop on a table and going up for a refill at a coffee shop.  When I do that I always feel pretty nervous.  Knowing that it could sound an alarm if someone moved it would make me feel more secure. 

For this application, you'll need a Windows 7 system, with a built-in or hardware add-on accelerometer.  Some hard drives have them, some Lenovo laptops have them, but you need to be able to access the sensor using standard Windows 7 Devices and Sensors drivers.

With hardware in place, download Visual Studio 2010 Express, the Windows API Code Pack, and the Sensors and Location API, then you're ready to get started!

Good Vibrations

The accelerometer is an interesting sensor.  You wiggle something physical around and get numbers that change.  The numbers represent how many G's are being experienced in up to three dimensions.  This makes it trivial to see when there is movement.  With some additional work you can figure out more fine-grained movement information, but we just need to know how much things are moving around.

Using the Windows 7 managed sensors API, we can instantiate the accelerometer and start reading values with only a small amount of work.  Even better, due to the design of the sensors API we can access it without locking it.  In other words, unlike reading data from a serial port or other hardware connection, applications can share devices.

In this application, I wanted a UI with a lots of the raw and calculated values showing.  This includes the G's for the individual axes, the net magnitude, and even a chart of data.  In a WPF application, you need public properties in order to participate in databinding.  You also need to be able to alert listeners when your values change.  Unfortunately, the X, Y, and Z values from the sensor report are not easily bindable due to their indexed nature.  They also have no way of alerting listeners (like the UI) that they have been updated.

The key to creating the right properties is using the INotifyPropertyChanged interface.  This interface has only a single member – the PropertyChanged event.  Whenever a property value changes, raise this event and any interested listeners will know to grab the new value.

Visual Basic

#Region "Magnitude Property"
    Private _magnitude As Double
    Public Property Magnitude() As Double
        Get
            Return _magnitude
        End Get
        Set(ByVal value As Double)
            _magnitude = value
            OnPropertyChanged("Magnitude")
        End Set
    End Property
#End Region

#Region "INotifyPropertyChanged Members"

    Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged

    Private Sub OnPropertyChanged(ByVal prop As String)
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(prop))
    End Sub
#End Region

Visual C#

#region Magnitude Property
private double _magnitude;
public double Magnitude
{
    get { return _magnitude; }
    set
    {
        _magnitude = value;
        OnPropertyChanged("Magnitude");
    }
}
#endregion
#region INotifyPropertyChanged Members

public event PropertyChangedEventHandler PropertyChanged;

private void OnPropertyChanged(string prop)
{
    if (PropertyChanged != null)
        PropertyChanged(this, new PropertyChangedEventArgs(prop));
}

#endregion

This pattern is found in every public property that you want to enable for databinding.  It's great because you can do it on a class for WPF or Silverlight, yet it's not creating a dependency on them.  You can subscribe to this event in some apps, and simply ignore the event in other applications.  Being able to reuse business objects this way is a big deal to me.

Now the UI can display new values as they change without the old Windows forms-style code (tbValue.Text = “value”).  The other part was to actually sound an alarm if the acceleration was more than a preset value.  This is a simple comparison.  This threshold value is called “sensitivity” and accepts a value from 0-3.  This is value is also a property in the view model.  If the measured magnitude value is higher than the threshold, then an alert displays and the system Exclamation sound plays:

Visual Basic

If Me.Magnitude > Me.Sensitivity Then
    Status = String.Format("Big movement! ({0} G's)", Magnitude)
    System.Media.SystemSounds.Exclamation.Play()
End If

if (this.Magnitude > this.Sensitivity)
{ 
    Status = string.Format("Big movement! ({0} G's)", Magnitude);
    System.Media.SystemSounds.Exclamation.Play();
}

In XAML, a Slider control is bound to the Sensitivity property in TwoWay mode. The slider is set with minimum and maximum values. Since sliders typically display their current value, you need to add a Label too.  It's not automatic.  The Label's content is actually bound to the Value property of the Slider control.  So, although it sounds complicated to require an extra field for the slider's label, the element databinding makes it simple.

XAML

<Label Content="Sensitivity (1-3):" FontWeight="bold"/>
<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width=".75*" />
        <ColumnDefinition Width=".25*" />
    </Grid.ColumnDefinitions>
    <Slider x:Name="slider" Margin="10,0,10,0" Value="{Binding Sensitivity, Mode=TwoWay}" Minimum="0" Maximum="3"  />
    <Label Content="{Binding Value, ElementName=slider}" FontWeight="bold" Grid.Column="1"/>
</Grid>

Getting the Data

Most sensors support the concept of auto-updating their data on a minimum interval.  I decided to do it on my own using a background thread.  This guaranteed a constant interval making it nicer for charting.  It wasn't really necessary, but what I found was no readings during no movement, and a flood of readings when things changed.

As long as the sensor is enabled, you can subscribe to the DataReportChanged event.  Then you can access the CurrentAcceleration property.  Individual axes are indexed rather than exposed as direct properties.  I suppose this is more flexible for far-future 11-dimensional accelerometers…

Visual Basic

Private Sub UpdateData()
    _optionsControl.Dispatcher.BeginInvoke(Sub() UpdateDataInvoked())
End Sub

Private Sub UpdateDataInvoked()
    If (_accelSensor Is Nothing) OrElse (_accelSensor.TryUpdateData() = False) Then
        Return
    End If

    Dim currentAccel = _accelSensor.CurrentAcceleration
    Dim sampleTime As DateTime = DateTime.Now

    Me.LastDataReportX = currentAccel(AccelerationAxis.X)
    Me.LastDataReportY = currentAccel(AccelerationAxis.Y)
    Me.LastDataReportZ = currentAccel(AccelerationAxis.Z)

    Me.Magnitude = Math.Sqrt(Math.Pow(Me.LastDataReportX, 2) + Math.Pow(Me.LastDataReportY, 2) + Math.Pow(Me.LastDataReportZ, 2))

    If _perfCounter IsNot Nothing Then
        _perfCounter.RawValue = Convert.ToInt64(Me.Magnitude * 10)
    End If

    ReadingsX.Add(New SensorReading() With { _
        .Reading = Me.LastDataReportX, _
        .Timestamp = sampleTime _
    })
    ReadingsY.Add(New SensorReading() With { _
        .Reading = Me.LastDataReportY, _
        .Timestamp = sampleTime _
    })
    ReadingsZ.Add(New SensorReading() With { _
        .Reading = Me.LastDataReportZ, _
        .Timestamp = sampleTime _
    })

    If ReadingsX.Count > 20 Then
        ReadingsX.RemoveAt(0)
    End If
    If ReadingsY.Count > 20 Then
        ReadingsY.RemoveAt(0)
    End If
    If ReadingsZ.Count > 20 Then
        ReadingsZ.RemoveAt(0)
    End If

    If Me.Magnitude > Me.Sensitivity Then
        Status = String.Format("Big movement! ({0} G's)", Magnitude)
        System.Media.SystemSounds.Exclamation.Play()
    End If
End Sub

Visual C#

void UpdateData()
{
    _optionsUI.Dispatcher.Invoke(new Action(
        delegate()
        {
            if ((_accelSensor == null) || (_accelSensor.TryUpdateData() == false)) return;
                    
            var currentAccel = _accelSensor.CurrentAcceleration;
            DateTime sampleTime = DateTime.Now;

            this.LastDataReportX = currentAccel[AccelerationAxis.X];
            this.LastDataReportY = currentAccel[AccelerationAxis.Y];
            this.LastDataReportZ = currentAccel[AccelerationAxis.Z];

            this.Magnitude =
                Math.Sqrt(Math.Pow(this.LastDataReportX, 2) + Math.Pow(this.LastDataReportY, 2) +
                            Math.Pow(this.LastDataReportZ, 2));

            if (_perfCounter != null) _perfCounter.RawValue = Convert.ToInt64(this.Magnitude * 10);

            ReadingsX.Add(new SensorReading { Reading = this.LastDataReportX, Timestamp = sampleTime });
            ReadingsY.Add(new SensorReading { Reading = this.LastDataReportY, Timestamp = sampleTime });
            ReadingsZ.Add(new SensorReading { Reading = this.LastDataReportZ, Timestamp = sampleTime });

            if (ReadingsX.Count > 20) ReadingsX.RemoveAt(0);
            if (ReadingsY.Count > 20) ReadingsY.RemoveAt(0);
            if (ReadingsZ.Count > 20) ReadingsZ.RemoveAt(0);

            if (this.Magnitude > this.Sensitivity)
            { 
                Status = string.Format("Big movement! ({0} G's)", Magnitude);
                System.Media.SystemSounds.Exclamation.Play();
            }
    }));
}

These ReadingsX/Y/Z collections contain the last 20 readings and are used in the next section…

Flooded with Data

With so much data flowing in, it can be hard to really visualize it.  This is why I decided that it made sense to chart it.  There are a few charting options out there that are free and a few that are commercial.  Some free options include Visifire, and Dynamic Data Display (D3).  I chose to use Visifire with a line graph and have a data series for each axis.  I'm not sure how useful this information is, but it looks nice!

Behind the scenes, I have three instances of ObservableCollection of type SensorReading.  SensorReading simply holds a data point and a point in time.  In XAML, I'm able to perform full data-binding from these collections to datasets in the graph.  Each time I add a value I check to see if I have over twenty items, and if so I remove the oldest one (element zero).  I'm sure I could graph more than that, but it seemed sufficient.

The other use for the data was to send it to the Windows Performance Monitor.  You've probably seen the charts of the CPU load, memory, disk write, and other low-level data, but you may not realize that you can track your own data this way as well.  Some companies add performance counters for number of simultaneous users, failed logins, cache misses, or whatever else is relevant to their application.  Adding counters for your own data is really easy.  You can choose to either have a number of items, or an increment/decrement counter to keep track of something.

Start by creating a category, then create the counter.  You can set names, descriptions, and data types.  For this project, I crated a category called “Sensors” and a counter called “Net force.”  This is of type NumberOfItems64 so I set the RawValue property with each new value.  The only caveat with performance counters, is that if you add the counter while Performance Monitor is running you won't see it until you restart it.

Visual Basic

Private Sub CreatePerfCounter()
    If (PerformanceCounterCategory.Exists(PerfCategoryName)) Then
        PerformanceCounterCategory.Delete(PerfCategoryName)
    End If

    ' Create a collection of type CounterCreationDataCollection.
    Dim CounterCreationData As New CounterCreationDataCollection()

    ' Create the counter, set properties, and add to collection
    Dim ccd As New CounterCreationData()
    With (ccd)
        .CounterName = PerfNetForceName
        .CounterHelp = "The net acceleration value (in G's)"
        .CounterType = PerformanceCounterType.NumberOfItems64
    End With

    CounterCreationData.Add(ccd)

    ' Create the category and pass the collection to it.
    _category = PerformanceCounterCategory.Create(PerfCategoryName, _
        "The Sensors performance object tracks the value of various sensors over time", _
        PerformanceCounterCategoryType.SingleInstance, CounterCreationData)

    _perfCounter = New PerformanceCounter(PerfCategoryName, PerfNetForceName, False)
End Sub

private void CreatePerfCounter()
{
    if (PerformanceCounterCategory.Exists(PerfCategoryName))
    {
        PerformanceCounterCategory.Delete(PerfCategoryName);
    }

    // Create a collection of type CounterCreationDataCollection.
    var counterCreationData = new CounterCreationDataCollection();

    // Create the counter, set properties, and add to collection
    counterCreationData.Add(new CounterCreationData
    {
        CounterName = PerfNetForceName,
        CounterHelp = "The net acceleration value (in G's)",
        CounterType = PerformanceCounterType.NumberOfItems64
    });

    // Create the category and pass the collection to it.
    _category =
        PerformanceCounterCategory.Create(
        PerfCategoryName,
        "The Sensors performance object tracks the value of various sensors over time",
        PerformanceCounterCategoryType.SingleInstance,
        counterCreationData);

    _perfCounter = new PerformanceCounter(PerfCategoryName, PerfNetForceName, false);
}

Utility Runner

This is not the first article to use my MEF-based Utility Runner application as the base.  As usual, you'll need to install that package (listed at the top in the prerequisites) in order for this to work.  You'll also need to go to your project's properties, to Debug, and tell it to use a specific executable for debugging.

If you use Utility Runner and want to add this is a plugin, go into the bin\debug\Addins folder and create a ZIP file from the contents of the MEFUtil-Seismo.util folder and rename it to MEFUtil-Seismo.util.  From the Addins tab in Utility Runner, click the Install Addin From File command from within Utility Runner.

Possible Enhancements

In addition to a sound, it might make sense to support other notifications like growl, Twitter, or email.  It might also make sense to respond to changes in a different sensor, for example ambient light.  If I turn off the light in my office, it could sound an alarm if the light went on and I didn't sign in within a certain amount of time.  That would require a change to monitor a different sensor (not difficult), and to check to see if the desktop is locked or not.

Conclusion

Sensors really change the nature of your code by allowing you to interact with the real world.  If your system isn't equipped with sensors (like mine, unfortunately), make do with an add-on/prototyping board so you can try things out.  These sensors are basically standard on smartphones these days, and will quickly become common on laptops as well.  Windows 7 included a great feature by providing common hardware and device support.  Take advantage of it today!

About Arian

Arian Kulp is a software developer living in Western Oregon.  He creates samples, screencasts, demos, labs, and articles; speaks at programming events about data, UI, Silverlight, and more; and enjoys spending time with his family.

Introduction

It's been a number of months since I released the first version of my Utility Runner application.  Utility Runner makes it possible to run system utilities with as little overhead as possible: Instead of lots of tray icons, numerous EXE's, and the associated memory and startup time overhead, this application manages multiple utilities from one place.

To open this solution, you'll need Visual Studio 2008 Express Edition (Visual C# or Visual Basic), at least.  If you don't have it yet, you should get it!

Working with MEF

Little has changed functionally from the last version of the application, beyond some refactoring that's taken place since the new version of MEF was released.  For one thing, the attribute for marking an export is no longer sealed, so you can now create a subclassed attribute that encompasses the export name and any other metadata included with it.  Consumers can simply use your new custom attribute for a stronger-typed experience.  In my case, I created a WpfServiceMetadata class.  Read on for more information.

Managing Addins

My big challenge was figuring out how to implement an addin manager to support multiple utility addins, like in Firefox.  MEF lets you easily mark what classes are addins and where they should fit into your overall code, but I wanted to take it further.  I decided that my goals were:

• The ability to load an addin through the UI
• The ability to disable/enable addins
• The ability to remove an addin 

There are a number of ways to achieve these goals.  Mine isn't the ideal way, but it works pretty well nonetheless.

Loading Addins

Loading addins is mostly handled by the MEF Framework itself, but there is some manual work involved as well.  I decided that instead of scanning a folder for DLL's like in the first version, I'd take things a step further:  I came up with a simple packaging format to contain the addin and its associated files.

The packaging format is simply a Zip file renamed with the .util extension.  The file contains at least the DLL of the addin itself, but might also include associated libraries, images, sounds, or other resources.  I toyed with creating a manifest file to help supply addin information that didn't require class loading, but I kept it simple for now.

Before loading DLL's with addins, the AddinManager class will scan the addins folder for .util files and unzip them to same-named folders.  Each of these folders gets added to the list of folders in which MEF searches.  The original file then gets deleted.

Adding an addin

An application that uses addins needs a way for users to add new ones.  The easiest method would be to have the user just drag new .util files into the Addins folder, but this isn't very user-friendly.  I wanted to make it easy for a user to click something in the application to install an addin.

If the user clicks the Add New Addin From File button, they use a file browse button to locate the file.  The application then copies that file to the Addins folder and notifies the user that it will be loaded on next startup.  It would be great to load the addin immediately, and MEF supports that, but I decided to skip dynamic addin control for simplicity.

Instead of going through the dialog when loading an addin, it would be nice to support double-clicking. To do this, an association needs to be made from the .util extension to the executable.  If you launch the executable with a file argument and it's the right format, it will automatically copy it to the Addins folder.  If an instance is already running, the new instance will just exit.  Similarly, if you launch the executable when another instance is running, the existing instance will show itself and the new instance will exit.

It's important to note that standard users don't have write access to the Program Files folder.  For this reason, addins need to be stored in the user's local profile folder.  System-level addins can be stored in the ProgramData folder.  Addins could be in the user's roaming profile folder, but I haven't thought through all of that yet.  (For example, if a user logs into different machines, an addin might not run on each system due to different hardware configurations.)

Disabling an addin

Disabling an addin should be a simple matter of renaming the addin folder.  You can't do this at runtime though, since the DLL's are locked and loaded.  As an alternative, I create a file (zero-length) with the same name and add the .disable extension to it.  I check for this upon startup and before loading, and can handle it properly.

Enabling and removing addins are handled similarly, using .enable and .delete extensions on the zero-length files.

Creating Addins

To create an addin, you need to 1) implement the IWpfService interface, and 2) add the WpfServiceMetadata attribute with a name for your addin.  From there, be sure to implement all the methods in the interface.  The Start method is called at initialization (you shouldn't take much time in the constructor), and Stop is called at the end, for cleanup.  Any time you want to update the Status, be sure to raise the StatusChanged event.

[WpfServiceMetadata("SampleAddin")]
public class SampleAddinImpl : IWpfService
{
}

The final thing you'll need to do is copy your addin DLL to a folder with your addin name, plus the .util extension (Yes, an extension on the folder name.  I do this in Visual Studio with a post-build event.  If you debug the application, it looks for an Addins folder under the current directory.  When started normally (such as when installed) it uses the local user profile.

When you're ready to distribute the addin, compress the DLL and any supporting files into the top-level of a ZIP file, then rename the .zip extension to .util.  You can load this from the Addins page of the app settings, or manually move it to the MefUtilRuner\Addins folder in your local profile folder (c:\users\{USERNAME}\AppData):

TimedQueue

Message boxes, balloon help, status bars—these are all great ways to display a message to the user, but they all only show one string at a time.  If you call it again before the reader has the chance to see it, it's just gone.  There are some nice message managers that make it easy to manage stacking alerts, but I decided to stick with the built-in balloon help provider, and just manage how often I send changes.  It's basically a buffered balloon provider that will only show messages every x number of seconds, regardless of how many attempts the application makes.  To use it, simply add items to the collection.  An event is raised whenever an item is available.  If an item has exceeded the maximum time-to-live threshold, the users of the collection never see it.

// Repeat while there are items (one pulse may occur with several items ready)
while (item != null)
{
    // If this is an old item, no event is raised.  This could happen if
    // a process goes into a loop and dumps a large number in a very short
    // amount of time.  
    if (DateTime.Now.Subtract(item.TimeStamp).TotalMilliseconds < _maxTTL)
    {
        RaiseEvent(item.Item);
        Thread.Sleep(_interval);
    }

    item = default(ItemWrapper<T>);

    lock (_lock)
    {
        if( _items.Count > 0 )
            item = _items.Dequeue();
    }
}

The main window creates an instance of the TimedQueue class.  Every time an addin wants to display a message, it's added to the collection.  When ItemAvailableEvent fires, it's dispatched to the UI thread to be displayed.  Dispatching prevents cross-threading issues between the background TimedQueue thread and the UI thread.

void statuses_ItemAvailableEvent(object sender,
    ItemAvailableEventArgs<StatusMessage> e)
{
    Dispatcher.BeginInvoke((ThreadStart)delegate() {
        StatusUpdatedHandler(e.Item); }
        , DispatcherPriority.Background);
}

Though this instance is being used for status messages, you can also use TimedQueue for other purposes, when you are willing to lose old messages.  One example would be to throttle user input, such as a game that doesn't want constant firing or jumping as fast as the user clicks a button.

Next Steps

There are a number of things that would be nice to have in this application.  It would be good to allow utilities to extend the context menu to enable or disable something, or at least to jump straight to their configuration page.

Using ClickOnce to deploy utilities would also be nice since it's so clean for the user, but there is a cost:  ClickOnce is very strict about how applications can interact with the system.  They are always per-user, and they live in “secret” folders.  Developers can't read or write to the hard drive except to protected storage (similar to the iPhone I suppose).  I'm not sure if they are restricted in other ways, but it could cause a hardship.

It would also be nice if addins could be added at runtime.  This is a fairly simple case, but I didn't get to it yet.  Furthermore, if you add, you might expect to enable/disable/remove at runtime too.  Unfortunately, disabling and removing aren't really possible.  Sure, I could call Stop on a utility and remove it from the UI (and not call Start on it next time), but that's not really disabled since it could still be running until the next restart.  I couldn't force it to die unless I used separate application domains, which I'm loath to do.

Finally, I'd really like to get an “app store” type of repository going.  I imagine being able to publish utilities like Sidebar Gadgets or Windows Live Writer Plugins so users can browse, read information, and click-and-install.  That could be a really great way to make the idea take off.

Conclusion

There are definitely some rough edges at this point, but it's getting there.  The source code is fully available and I'd be willing to give commit access to anyone interested in moving things forward.  Just drop me a line!

About Arian

Arian Kulp is a software developer living in Western Oregon.  He creates samples, screencasts, demos, labs, and articles; speaks at programming events; and enjoys spending time with his family.