Alex made some headway over the weekend on Project Resistance with the ResistorView and doing some drawing.  Now (on the WinMo classic emulator) it looks like this:

Notice the white border around the bands.  Nicely enough, Alex gave me a bug item for this, so I started looking at it this morning, thinking that maybe the images simply have some non-transparency problem along the edges.  Well, not so simple.  Here's a close up (using Paint.NET if you're curious) along the right edge of a Ring1 Yellow band (the one used for generating this view):

You can see that there's nothing wrong here.  What appears to be happening is that pixels with partial transparency (or partial opacity if you're a glass-half-empty kind of person) are getting incorrectly rendered as white.  So now we're off to chase down a redering problem instead of spending time developing logic for our actual business problem.  My off-the-cuff guess is that it's because we're storing the bands as a Bitmap class, which probably has no notion of an alpha channel, and therefore is just replacing these pixels with white.

It's worth noting that just getting this far with drawing has been heavily reliant on non-CF classes, and if my guess on the Bitmap being the problem is corrrect it means that even more of the drawing code will rely on objects not in the CF.  Again, this exemplifies the pain of creating WinMo apps that have the aethetics users have come to expect since iPhone came on the scene.

Well, last night I got an email from Microsoft:

Not too bad.  Less that 48 hours from when we applied we got accepted, and I'm not sure what "contact" I was supposed to get from GeoTrust.  I did get an email response immediately after the application (within a few minutes) to confirm my contact info, but that was it.  All in all, a completely painless process.

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.