REST web services are pretty straightforward and really, really common (you used one to read this blog page).  As software gets implemented as services, it's getting more and more common for us as developers to have to make REST calls programmatically.  Lately I've been implementing a lot of services using Padarn on both the device and the PC and then implementing client libraries to access those services.  In doing so, it only made sense to create some infrastructure to make my life a little easier, and so the RestConnector (and DigestRestConnector) was born.

For a simple GET, such as to get the response for this page, the code is trivial:

var connector = new RestConnector("blog.opennetcf.com");
var response = connector.Get("/ctacke");

Other verbs like POST and PUT are nearly as simple.

var response = connector.Post("/upload", myData);

For services that require authentication, there's the DigestRestConnector that behaves the same, except the ctor takes in a UID/PWD pair as well. The classes support the four common verbs I use: GET, PUT, POST and DELETE. Of course since it's open-source, feel free to extend them as you wish.

The OpenNETCF Extensions library is a collection of extension methods and helper classes that I find useful in a lot of different projects. It's compatible with the Compact Framework, Tirethe full framework and Windows Phone.

Transferring data between processes in Windows CE is not difficult, and you can avoid using passing data through the message pump using WM_COPYDATA (which I've never considered a good idea, BTW).  Sockets and point to point queues are pretty straightforward and well documented for IPC. 

One mechanism that isn't well covered, and that works well for sharing larger blobs of data, is a memory-mapped file.  The SDF contains a MemoryMappedFile class (in the OpenNETCF.IO namespace) that allows you to use a shared memory region (in ram or on disk - your choice) and to access it just like you would any other stream with Write, Read and Seek.  Here's a simple example. Yes I realize my synchronization mechanism here isn't the cleanest, but it conveys the idea with the least code.

using System;
using System.Text;
using OpenNETCF.IO;
using OpenNETCF.Threading;
using System.Diagnostics;
using System.Reflection;
using System.IO;

namespace MMFPeer
{
    class Program
    {
        public const string SharedMapName = "MMF_PEER_NAME";
        public const long MaxMapSize = 1024;
        public const string SharedMutexName = "MMF_PEER_MUTEX";
        public const string DataReadyEventName = "MMF_PEER_DATA_READY";

        private MemoryMappedFile m_mmf;
        private NamedMutex m_mutex;
        private EventWaitHandle m_dataReady;

        private bool Sending { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }

        public void Run()
        {
            var processName = Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().CodeBase);

            // create the MMF
            m_mmf = MemoryMappedFile.CreateInMemoryMap(SharedMapName, MaxMapSize);

            // create a shared mutex
            m_mutex = new NamedMutex(false, SharedMutexName);

            // create a data-ready event
            m_dataReady = new EventWaitHandle(false, EventResetMode.ManualReset, DataReadyEventName);

            // fire up a "listener"
            new System.Threading.Thread(ReadProc)
            {
                IsBackground = true,
                Name = "MMF Peer Reader"
            }
            .Start();

            Console.WriteLine("Memory Mapped File Created.  Enter text to send to peer(s)");

            // wait for user input
            while (true)
            {
                var input = Console.ReadLine();

                if (input == null)
                {
                    Thread2.Sleep(5000);
                    input = GetMockInput();
                    Debug.WriteLine(string.Format("Platform does not have a Console installed. Sending mock data '{0}'", input));
                }

                if (input == "exit") break;

                // prefix our process name so we can tell who sent the data
                input = processName + ":" + input;

                // grab the mutex
                if (!m_mutex.WaitOne(5000, false))
                {
                    Console.WriteLine("Unable to acquire mutex.  Send Abandoned");
                    Debug.WriteLine("Unable to acquire mutex.  Send Abandoned");
                    continue;
                }

                // mark as "sending" so the listener will ignore what we send
                Sending = true;

                // create a "packet" (length + data)
                var packet = new byte[4 + input.Length];
                Buffer.BlockCopy(BitConverter.GetBytes(input.Length), 0, packet, 0, 4);
                Buffer.BlockCopy(Encoding.ASCII.GetBytes(input), 0, packet, 4, input.Length);

                // write the packet at the start
                m_mmf.Seek(0, System.IO.SeekOrigin.Begin);
                m_mmf.Write(packet, 0, packet.Length);

                // notify all clients that data is ready (manual reset events will release all waiting clients)
                m_dataReady.Set();

                // yield to allow the receiver to unblock and check the "Sending" flag
                Thread2.Sleep(1);

                // reset the event
                m_dataReady.Reset();

                // unmark "sending" 
                Sending = false;

                // release the mutex
                m_mutex.ReleaseMutex();
            }            
        }

        private int m_inputIndex = -1;
        private string[] m_inputs = new string[]
            {
                "Hello",
                "World"
            };

        private string GetMockInput()
        {
            if (++m_inputIndex >= m_inputs.Length) m_inputIndex = 0;
            return m_inputs[m_inputIndex];
        }

        private void ReadProc()
        {
            var lengthBuffer = new byte[4];
            var dataBuffer = new byte[m_mmf.Length - 4];

            while (true)
            {
                // use a timeout so if the app ends, this thread can exit
                if(!m_dataReady.WaitOne(1000, false)) continue;

                // avoid receiving our own data
                if (Sending)
                {
                    // wait long enough for the sender to reset the m_dataReady flag
                    Thread2.Sleep(5);
                    continue;
                }

                // grab the mutex to prevent concurrency issues
                m_mutex.WaitOne(1000, false);

                // read from the start
                m_mmf.Seek(0, System.IO.SeekOrigin.Begin);

                // get the length
                m_mmf.Read(lengthBuffer, 0, 4);
                var length = BitConverter.ToInt32(lengthBuffer, 0);

                // get the data
                m_mmf.Read(dataBuffer, 0, length);

                // release the mutex so any other clients can receive
                m_mutex.ReleaseMutex();

                // convert to a string
                var received = Encoding.ASCII.GetString(dataBuffer, 0, length);

                Console.WriteLine("Received: " + received);
                Debug.WriteLine("Received: " + received);
            }
        }
    }
}

There has been rampant speculation for some time that Windows CE was dead and that Microsoft was abandoning it.  The announcement that Windows 8 will run on ARM only added fuel to it, despite the fact that Win8 is undoubtedly going to have a large, desktop-style footprint and no capability for real-time operation.  Well, Microsoft finally decided to tell us what many of us suspected for some time.  Windows Embedded Compact (i.e. Windows CE) is still on their product roadmap.  It will have a v Next, and it will be supported in newer versions of Visual Studio (well native development will be anyway).  Read the full press release here.

With the upcoming MTConnect conference next week, we've been extremely busy getting things ready for our talks as well as our booth on the show floor.  I think we got feature complete (at least as far as we want for the show) today, so I'm merged all of the latest changes into the public trees for both the MTConnect Managed SDK as well as the OpenNETCF Virtual Agent.  I have an updated Machine Simulator that we'll be using for the show, but it's not quite ready for public consumption, so the release of that will have to wait until after we get back from Cincinnati.

Marshaling UI access to the proper thread is a very common task in app development, yet it still tends to be a pain in the ass.  You have to check if InvokeRequired is true (well you probably don’t *have* to, but not doing it feels dirty to me) and even using an anonymous delegate tends to be verbose.  And then there are also the simple bugs that are not always easy to spot.

So, like any good developer, I stole someone else’s idea and put it into the OpenNETCF Extensions.  Now, instead of doing this:

void MyMethod()
{
    if (this.InvokeRequired)
    {
        this.Invoke(new EventHandler(delegate
            {
                MyMethod();
            }));
        return;
    }

    // do stuff with the UI
}

You do this:

void MyMethod()
{
    Invoker.InvokeIfRequired(i =>
    {
        // do stuff with the UI
    });
}

Less code.  Less potential for error.  More readable.  What’s not to like?

The OpenNETCF Extensions library is a collection of extension methods and helper classes that I find useful in a lot of different projects. It's compatible with the Compact Framework, Tirethe full framework and Windows Phone.

This post is part of my "Software Development" series. The TOC for the entire series can be found here.

In this post, we’re going to look, at a higher level, at the reasons for and benefits of using a framework for Inversion of Control (IoC), Dependency Injection (DI) and Service Location. I’m not going to spend a large amount of time in this blog series describing the intimate details of what IoC, DI and Service Locators are.  Martin Fowler did a fantastic job of it and there’s no point in me just regurgitating his work.

Instead, I’ll give my vision of what they are and how they are relevant to how I architect and develop solutions.  It’s important to note that I’m starting out this series with high-level thoughts about architecture and design.  I’m not just laying down some code, leaving the decisions about how things will interact to some arbitrary, organic process.  This is how software development gets done. 

You’ve got to think about not just the next step, but visualize the end point several months, or even years out and try to connect the dots back to where you are today.  If I implement something in a certain way today, is it going to screw me 3 months down the road?  Spending an extra day now thinking about architecture is going to turn into saving weeks of the customer breathing down your neck and you pull out your hair and work late night trying to hammer a square peg into a round hole.

So let’s look at IoC, DI and Service Location and how they’re going to help us build better software.  Inversion of Control as a concept is something that’s really broad.  It’s really anything that turns the older procedural way of developing upside down (i.e. inverts program control, hence the name).  Moving from a console app to a windowed, event-driven app is technically inversion of control, so you’ve already been using IoC. 

To talk about IoC as a useful concept that’s actually going to be of use, we’ll be using some smaller units/principals of IoC.  The two we’re going to look at are Dependency Injection, or DI, and Service Location.  Neither one is complex or arcane, and you probably already use them to some degree.

Let’s assume we have two arbitrary classes, A and B, and that A uses an instance of B internally.  There are, essentially, 3 ways that A can get the instance of B. 

First, it can directly create it by calling new B().  While this is simple, it’s the least preferred, and generally worst, way to do it.  By directly creating B, A is now tightly coupled to B’s implementation.  B can’t be easily changed out to something else.  If B is in another assembly, A has to have a reference to it.  It’s also difficult to test A by itself. 

The second way that A can get B is that whoever created the instance of A could pass into it an instance of B.  Maybe through a constructor

var b = new B();
var a = new A(b);

or through a property

var b = new B(); 
var a = new A(); 
a.B = b;

This is called Dependency Injection. The former is constructor injection, the latter is property injection – not so complex, eh?  This is useful because, if B is an interface, it’s really easy to swap out the implementation passed to A and the assembly containing A doesn’t necessarily have to have a reference to the assembly holding the implementation of B – it only needs a reference to the interface.  This is really nice when we want to do mocking.

The third way that A can get B is to go get it from some central repository or “factory”.

B B { get; set; }

public A() 
{ 
   this.B = MyClassFactory.GetB(); 
}

This is service location.  A doesn’t really know what B is, it lets the service locator (MyClassFactory) resolve that.  This is really helpful for plug-in architectures as well as for lazy loading objects.

Generally speaking, your code should only be doing #2 (DI) and #3 (service location) for objects of any complexity.  This is not to say that you shouldn’t ever call the new operator in your code.  There’s obviously a grey line out there below which it would be pretty stupid to not just use new for.  If you need to use a simple entity class or structure, then creating one makes sense.  If you need access to the DAL and I see you creating a DAL object in your View, you’re fired.

There are plenty of framework out there that provide DI and service location -  Ninject, Unity, CastleWindsor, StructureMap, Autofac – the list goes on and on.  Instead of using one of them, however, I chose to roll my own.  Normally I wouldn’t recommend such a drastic action – after all reinventing the wheel isn’t usually wise – but in my case it was essentially required, so I’ll give you the short back story.

My team and I had been working on a large desktop application.  We had designed it from the start using Microsoft’s SCSF/CAB framework, which provide DI, service location and a load of other stuff.  It turned out that we were using maybe 10% of the framework, and that the framework’s Studio plug-ins were causing fits with some installations of Studio.  Spending time screwing with Studio plug-ins and trying to get things to compile is a terrible waste of manpower, so we were already getting close to jettisoning it when we decided that we wanted the core of our app logic to be Compact Framework compatible.

Well Microsoft’s “port” of the SCSF to the Compact Framework, called the MCSF, turns out to be a bloated, unbelievably slow, steaming pile of dog crap.  Side note: just because something compiles under the Compact Framework does not mean it should be used in the Compact Framework.  Well, I didn’t want to refactor everything we’d done to some other IoC framework, plus I couldn’t find one at the time that actually worked for the Compact Framework, so I decided to create one. 

I took the tack that I’d create it for the CF first, with a high emphasis on small footprint, minimal resource usage and speed and I simply matched the SCSF object model where our code base interfaced with it and where it made sense – in some places I didn’t like how the SCSF had done things, so I “fixed” their mistakes.  The end result was the OpenNETCF.IoC framework, which turns out to stack up quite well against the other frameworks.  It also has the huge benefit of working on the Full Framework, Windows Phone 7 and MonoTouch (probably MonoDroid as well, though I’ve not tested that). We’ll be looking at OpenNETCF.IoC in a lot more depth in this series.

Below is a handy table of contents for my “Software Development” series of blog posts

1. On Software Development (10/31/11) 
2. Inversion of Control, Dependency Injection and Service Locators oh my! (11/1/11)
3. An Intro to ORMs (11/21/11)