I didn't have a whole lot of time today to code on Project Resistance, so it didn't progress as far as I'd have liked, but I did get a few important things done.  First off I got the unit test project added to SCC after being admonished by Nick. 

I did a little bit of coding for the placement of the color bands on the resistor (though I'm not actually drawing them as anything but a rectangle right now).  This allowed me to code in "gestures" for them.  The idea is that you'll be able to put your finger/stylus on a band and swipe up or down to change the color (instead of popping up a menu or something).  Right now the gestures are plumbed all the way to the debug output.

I also started the process of becoming a registered developer for the Windows Marketplace for Mobile (seriously Microsoft, can you quit with these long names?  Notice how "App Store" is 2 syllables?).  Since I've pretty much ignored all of the info that's been pushed out to us on how this works, I'm actually a pretty good test case. 

I started the process with a Bing search for “windows mobile application certification” which apparently was a good choice since the first result led me where I wanted to be: the page on the “Application Certification Program”.

To be honest, this page is going to cause confusion.  I want to create and sell a WinMo app.  Why are there two separates paths to get there.  Please, Microsoft, let's streamline this.  Give me one path.  I understand that some people want just the "designed for WinMo" logo and not to put the app in the WMM (my lazy typing acronym), and that's fine. WMM certification should simply be an added step, not a completely separate process.

At any rate, I know we're after a WMM app, so I reviewed the “Prohibited Application Types” document.  Seems like a reasonable list, and as long as we stay away from resistor-ads and resistor-porn it seems we'll be fine.

Next I filled out the WINDOWS® MARKETPLACE FOR MOBILE REGISTRATION form.  Refreshingly short as far as forms go.  There was one oddity, though. When I entered my email address for the company email I got and error:

“The e-mail address provided for the corporate contact cannot be the same as the account holder's e-mail address. Please provide an alternate email address for the corporate contact.”

This seems a bit ridiculous. What about the single developer shop?  Why should they have to have 2 emails?  If someone wants to subvert this, using a distribution list would work so I see zero value in this this as a constraint.  Sure, it's a small bump in the process, but if Microsoft is after seamless and smooth these things add up.

I ponied up my $99 and I’m perfectly okay with that.  If I’m going to make my living off of software, then $99 is really nothing.  It's way less than we spend on tools, hardware or even coffee.

Now all I have to do is wait for GeoTrust to contact me “to complete the Identity Verification Process”.  No idea how long that might take, but I'll blog when it happens so you get a feel for how long this takes.

Today I did some of the preliminary work for Project Resistance (well I did it yesterday and today, but we'll call it Day 1).

As usual Smith, my go-to graphics guy for things like this, turned out images that were better than expected, so the app won't look like I did the graphics.  That's the first key to this project looking professional.

I did some preliminary inrastructure work for the application, setting up file layouts and the like.  I also did some quick work for drawing the blank resistor on a background as well:

As usual this was pretty painful - way more painful than it should be.  Trying to get alphablending/transparency working on Windows Mobile can be a huge chore.  It's even worse if you want a control (which is what the resistor is) to have a transparent background through which you can see the parent Form (which is where that green PCB image is drawn).

It involves calling back up to the parent and having it draw the clipping region under your control when the control paints itself.  Fortunately I'd run into this before and I had the code readily available.  Many thanks to Alex Feinman for figuring this out in the first place.

This is certainly something Microsoft needs to work on simplifying if they want the average developer to be able to achieve success.

So today OpenNETCF is embarking on a new project: Project Resistance.  Project Resistance is intended to be a fully transparent view into the process of conceiving, developing and selling an application for Windows Mobile. The idea here is that anyone will be able to look at how sausage gets made.

We're going to start by creating a production-quality application, following best practices for coding, etc. etc. All of the source code will be published, and we will blog about the process, the thoughts we have, and the hurdles we encounter. Bear in mind that we are already experienced WinMo/Win CE developers, so it's not going to be a beginner's How-to type of process. We're not here to teach you how to wire up an event.

The application is going to be very simple, but something that's actually functional. It will allow you to select color bands on a resistor and it will tell you the resistance. Alternately you will be able to give it a resistance and the application will tell you what the color bands will be. If you have no idea what any of that means, take a look at the Wikipedia entry on resistorsEssentially a resistor has stripes on it and the stripes correlate to numbers, which tell you the resistance in ohms.

Once we have the application completed, we're going to go through the process of getting it into the Windows Mobile Marketplace. We've never gone through that process, so it should be educational all around.

We're still undecided, but I think we'll probably put the application up as a "for pay" item (at maybe $0.99). We're not planning on making money off of this, but we really want to see how Marketplace works for taking payments, getting paid, reports, refunds and that entire process.

Once we have that done, we've got some more nebulous plans for maybe tracking downloads versus usage (to track "unauthorized" proliferation) as well as seeing just how "secure" our IP is.

Recently I got feedback from Nick Randolph, another device developer MVP, regarding the OpenNETCF.IoC framework and handling the lifecycle of IDisposable objects (well we taked about a few things, but this is the one I tackled first).  The problem is that if you add an IDisposable object to any DI container (be it OpenNETCF.IoC, Unity, Ninject or whatever) the container knows nothing about the object's Disposed state.  Unfortunately the IDisposable interface doesn't expose an IsDisposed property or OnDisposed event. 

SO what, exactly, is the problem?  Well, let's assume we create an IDisposable object and add it to the DI container.  AT some point later, we're done with the object, so we call Dispose.  Well that internally releases the object's native resources, but the object itself still has a root (the reference from the container) and so the GC will never actully collect the object and its managed resources.  On an embedded device this could be a problem.

The solution that we came up with is to create a wrapper for IDisposable objects and a new set of methods for the container for adding.  So now you can do something like this:

var instance = RootWorkItem.Items.AddNewDisposable<MyDisposableType>();

Now instead of this returning an instance of MyDisposableType, it returns a container object that holds it.  You access the MyDisposableType object itself via the Instance property of the container, which requires some small code work on the consumer's part, but the nice thing is that when you call Dispose on that container, it in turn calls Dispose on the contained instance *and* it removes the object from the DI container so the GC can do it's work on the object.

I've not rolled a new framework release with these changes because they really are just a proposed solution for now.  If you're interested, go ahead and pull the latest code from the source code page (change set 32718) on the project site and give it a try.  There are a load of new unit tests that show the general idea on usage.

Today I got a question from a customer, that essentially was "how can I detect when the network cable has been plugged in or unplugged from my CF application."  I knew I has solved this before, and after a little bit of digging with search engines I was reminded how obscrure finding the answer to this, even from native code, is.

So the general answer for how this is detected is that you have to call down into the NDIS driver via an IOCTL and tell it that you're interested in notifications.  This is done with the IOCTL_NDISUIO_REQUEST_NOTIFICATION value.  Of course receiving the notifications isn't so straightforward - you son't just get some nice callback.  Instead you have to spin up a point to point message queue and send that in to the IOCTL call, along with a mask of which specific notifications you want.  Then, when something changes (like the cable is pulled) you'll get an NDISUIO_DEVICE_NOTIFICATION structure on the queue, which you can then parse to find the adapter that had the event and what the exact event is.

From a managed code perspective, this is actually a lot of code to have to write - CreateFile to open NDIS, all of the queueing APIs, the structures for the notifications, etc.  Fortunately, I'd already been down this road and had added it to the Smart Device Framework already.  So if you're using the SDF, getting the notifications looks like this:

public partial class TestForm : Form
{
  public TestForm()
  {
    InitializeComponent();

    this.Disposed += new EventHandler(TestForm_Disposed);

    AdapterStatusMonitor.NDISMonitor.AdapterNotification += new AdapterNotificationEventHandler(NDISMonitor_AdapterNotification);
    AdapterStatusMonitor.NDISMonitor.StartStatusMonitoring();
  }

  void TestForm_Disposed(object sender, EventArgs e)
  {
    AdapterStatusMonitor.NDISMonitor.StopStatusMonitoring();
  }

  void NDISMonitor_AdapterNotification(object sender, AdapterNotificationArgs e)
  {
    string @event = string.Empty;

    switch (e.NotificationType)
    {
      case NdisNotificationType.NdisMediaConnect:
        @event = "Media Connected";
      break;
      case NdisNotificationType.NdisMediaDisconnect:
        @event = "Media Disconnected";
      break;
      case NdisNotificationType.NdisResetStart:
        @event = "Resetting";
      break;
      case NdisNotificationType.NdisResetEnd:
        @event = "Done resetting";
      break;
      case NdisNotificationType.NdisUnbind:
        @event = "Unbind";
      break;
      case NdisNotificationType.NdisBind:
        @event = "Bind";
      break;
      default:
        return;
    }

    if (this.InvokeRequired)
    {
      this.Invoke(new EventHandler(delegate
      {
        eventList.Items.Add(string.Format("Adapter '{0}' {1}", e.AdapterName, @event));
      }));
    }
    else
    {
      eventList.Items.Add(string.Format("Adapter '{0}' {1}", e.AdapterName, @event));
    }
  }
}

It's been a while since I did any check-ins to the OpenNETCF.IoC framework.  It's not due to lack of interest or lack of thought on my part.  I've just been very, very busy lately.  We've now using the IoC project in a few commercial applications with very good results, so there isn't a whole lot more to add (though I do want to add some sort of lifecycle management capabilities).

In the hope of getting a little more adoption of the framework, I've added an adapter to OpenNETCF.IoC for the Microsoft Patterns and Practices CommonServiceLocator (CSL).  You can use CSL code to extract object instances from the Items collection.  My hope is that this makes it easier for development teams using CSL to integrate OpenNETCF.IoC into their mobile and embedded projects.

If you have any other ideas or feature requests for OpenNETCF.IoC, by all means submit a request or start a discussion on the project site.  And if you're using it, I'm always interested to see how it's working out.