As the WCF Web API project is a bit of a moving target at the moment, it’s been hard to try and find a sensible way to handle NHibernate sessions for each resource. They key word there is resource.

If you’ve ever used NHibernate with WCF before, you’ve probably organised your session management around the per-request model. That starts to break down with WCF Web APIs. You see, you have to consider how OData is consumed. This is where you have a resource operation that returns an IQueryable<T> that is evaluated after the operation returns. This is a really cool thing, but it breaks if you use a per-request style management method, or if you manually open and close the session for each operation. For example:

[ServiceContract]
public class MyResource
{

    private ISessionManager _sessionManager;
    private IWidgetRepository _widgetRepository;

    // You always inject, right?...
    public MyResource(ISessionManager s, IWidgetRepository r)
    {
        _sessionManager = s;
        _widgetRepository = r;
    }

    [WebGet(UriTemplate = "dtos")
    public IQueryable<MyDTO> GetAllMyDTOs()
    {
        using(_sessionManager.GetSession())
        {
            return _widgetRepository.Query();
        }
    }
}

This is bad/wrong/silly. As the response from GetAllMyDTOs isn’t actually evaluated until after the operation returns, it will fail, as you’ve disposed the session it’s linked to.

The other, “worserer” way is to just wait until the garbage collector cleans up your session by itself. I shouldn’t have to explain why that’s a monumentally stupid thing to do.

So, I had a bit of a think about this problem. While there is the option of message handlers and operation handlers, they still don’t give you a way of executing some code before and after an operation (to open and close the session). On top of that, operation handlers are asynchronous, so if you’re being good and binding your session to a ThreadStatic variable, it won’t be bound to the same thread your operation will actually execute on.

If you’re using dependency injection to build your resources (which you should), then you’ve no doubt used the WebApiConfiguration class and created a method on your class to handle the CreateInstance delegate. This method would locate the requested type in your DI container and return the composed instance.

Well, there’s a corresponding delegate exposed by WebApiConfiguration called ReleaseInstance. It’s job is to take an instance and get rid of it.

Now we have two methods, fired at each end of a resource’s life-cycle. The only concern I had is if, somehow, the create/release methods ran on a different thread to the operation. So I stuck a little logging of the thread ID in there and did a couple of tests. Same thread ID all around! Not only that, each subsequent quasi-simultaneous (because I can’t think of a better way to describe it) resource request utilised a different thread. At least, that’s the anecdotal evidence I’ve… anecdoted. So each resource would have it’s own session, as each session is bound to a ThreadStatic variable!

So, at the moment, I have a naïve implementation of session management, scoped per resource, that looks like this:

public class MyWebApi : System.Web.HttpApplication
{
    public void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new HandleErrorAttribute());
    }

    public void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathinfo}");

        var config = new WebApiConfiguration
                            {
                                EnableTestClient = true,
                                CreateInstance = Create,
                                ReleaseInstance = Release
                            };
        routes.SetDefaultHttpConfiguration(config);

        routes.MapServiceRoute<MyResource>("myresourceuri");
    }

    private object Create(Type t, InstanceContext c, HttpRequestMessage r)
    {
        var sm = Injector.Default.Get<ISessionManager>();
        sm.OpenSession();
        return Injector.Default.Get<t>();
    }

    private void Release(InstanceContext c, object i)
    {
        var sm = Injector.Default.Get<ISessionManager>();
        sm.CloseSession();
    }
}

As I said, this is a very simplified chunk of code. I haven’t load tested it sufficiently (read: at all) to be able to say with any Jobsian sense of confidence that it’s flawless. But it gives me the result I want at the moment. Until I find something better…

It doesn’t happen when you’re in development mode using the VS web server, so I didn’t catch it when I was developing. When I went to put it on the test server, deletes would fail. Fiddler would report a 501 Not Implemented error was returned by the server. I initially thought I’d messed up the resource mappings, but it wound up being the server configuration.

Your first response might be to head over to the application configuration on the server and simply add the missing verbs to the existing mappings. But WCF web APIs don’t have a file type, so there’s no mapping for you to edit!

To fix it, you need to setup a wildcard mapping on the server. A wildcard mapping allows you to specify an ISAPI handler that is run after every other mapping is attempted. It’s a kind of catch-all; hence the name.

Here’s how to set up a wildcard mapping:

1. Open the IIS Manager snap-in.
2. Use the treeview to navigate to the web site or application hosting your API.
3. Right-click the application and select Properties.
4. On the Virtual Directory tab, click the Configuration button.
5. On the Mappings tab, click Insert next to the Wildcard application maps list.
6. In the Executable text box, enter the path to the aspnet_isapi.dll version that your API is built for.
7. Click OK to close the mapping dialog.
8. Click OK to close the Application Configuration dialog.
9. Click OK to close the properties dialog.
10. Go delete something!

It’s not hard to fix the problem, in the end.

In App.Core. I want to create the InjectorBase class that every injection implementation derives from. Then, for example, in the App.UI I want to create a UserInterfaceInjector that descends from InjectorBase, but I only want the subclass to supply configuration. Then in App.Services I can create a ServicesInjector that also descends from InjectorBase, and again, only supplies configuration.

The next trick to this is, I want the dependency injection to be through a singleton. Yes, yes, singletons are evil etc. In this case, it’s being used for what I consider a correct purpose (as a service locator), and not some sort of global variable hold-all. So, in some random piece of code in App.Services, I want to be able to do something like this:

public void SomeMethodThatDoesSomethingTo(Some variable)
{
    var aRepository = ServicesInjector.Default.Get<IARepository>();
    aRepository.Add(variable);
}

And, conversely, in the App.UI I want to be able to do this:

public void SomeMethodThatLocatesAServiceImplementation()
{
    var aService = UserInterfaceInjector.Default.Get<IAService>();
    aService.DoSomethingMostLikelyAsynchronously();
}

It all seems fairly straight forward, yes? Well, it winds up not being too difficult, but one of the first problems you’ll run into relates to inheritance and the static keyword. Basically, you can’t. Which actually makes sense if you care to try and understand it. Anything static is of the class, not of an instance of the class. If you create a subclass, it’s new class, so the static thing doesn’t follow you. Why do we need the static keyword? The singleton. Here’s an example (simple) singleton implementation.

public class MySingleton
{
    private static MySingleton _default;

    public static MySingleton Default
    {
        get { return _default ?? _default = new MySingleton(); }
    }

    public string SayHello()
    {
        return "Hello!";
    }
}

In order to supply a reference to an instance without maintaining that reference in another class, we have to use a static field (to hold the reference) and a static property (to get at the static field).

Where I wanted to take this that was a bit out of the ordinary, is I wanted the singleton in the base class so implementors didn’t have to think about all that plumbing. This means making the base class abstract (so it can’t be directly instantiated) and then providing an abstract method that returns a container configuration. Then all the subclasses have to do is inherit from the base class and then provide an implementation of the abstract method.

The next problem is, the configuration method is an abstract method of the base class, and not static, but the point of creation of the class is in a static property get method. How do you call an instance method of a class to obtain configuration you need at creation time without an instance of the class? Well, you can’t. Now, obviously I’ve solved this problem, otherwise we’d be at the end of this post.

The gist of it involves breaking a cardinal rule of C# object creation: Don’t call virtual methods in a constructor. The reasoning behind this is C# initialisers (initializers for the Americans amongst us) run in order of farthest child back up to the base class, but the constructors run from the base class to the farthest child. Here’s a bit more information. The trick to overcoming the actual problem was to use the Activator class. This involves a bit of genericism of the base class to ensure the child class is being instantiated, which then allows us to call the virtual method with abandon. So the base class now looks like this:

abstract class BaseClass<T> : IHello where T: IHello
{
    private static IHello _default;
    private readonly string _message = "Hello from the base class.";

    public static IHello Default
    {
        get { return _default ??
                    (_default = Activator.CreateInstance<T>()); }
    }

    protected BaseClass()
    {
        _message = GetMessage();
    }

    public void SayHello()
    {
        Console.WriteLine(_message);
    }

    public abstract string GetMessage();
}

Here’s IHello, in case you couldn’t figure it out:

interface IHello
{
    void SayHello();
}

Finally, here’s how the implementors of the base class look:

class ChildClass : BaseClass<ChildClass>;
{
    public sealed override string GetMessage()
    {
        return "Hello from the child class.";
    }
}

You can tie all this together in a console application with a bit of this magic:

class Program
{
    static void Main(string[] args)
    {
        ChildClass.Default.SayHello();
        Console.ReadKey(true);
    }
}

I’m about to roll this into the code. The spike seems to work without any problems (other than ReSharper warning me about my virtual method call in the constructor), but until I put it into the application code I won’t really know if it’s 100%. Let me know if you spot anything silly, won’t you?

Oh, here’s a link to the sample code if you want it.

The trick is to use the ToMethod method. ToMethod takes a lamda as a parameter. It’s defined as:

ToMethod(Func<IContext, IInstance> method)

This means ToMethod takes a function that accepts the injection context and returns an instance of the type being bound to. We can now use this to return our specific instance:

myKernel.Bind<IMyInstance>.To(context => anInstanceOfMyInstance);

The gotcha being that any Get of IMyInstance will result in a reference to the original anInstanceOfMyInstance. You have to be careful of lifetime, and therefore scope, and any changes to state.

I’m not convinced that this is actually a good idea, but it solves my immediate problem.

NInjectExistingInstanceTest

_{(And yes, this represents yet another return to blogging in some more regular form… I do intend to come through with the previously promised goods, just not in any specific order…)}

I’ve been using a combination of The Gimp and Inkscape to handle my artwork needs of recent. As I’m running them in OS X, they need to use the X11 environment. One of the annoyances I have been having with the Gimp is every window has needed an extra click just to focus it.

It turns out the fix is not difficult. I initially thought it might involve turning on the “focus follows mouse” option, but instead it was this:

So if you’re using an X11 application and find yourself dealing with weird focus issues, try turning on “Click-through Inactive Windows”. It did the trick for me.

There was an interesting argument I was a witness to a few days ago. The basic premise was, a developer was complaining about the lack of thought that went into a particular area of a particular piece of software.

He was right. The most basic amount of thought had been put into it, and the thought that had been put into it was wrong. It was causing him some distress (shall we say…) and the conversation was getting quite heated.

At this point in time, one of the company principles came out of his office, and in defense of the software said something along the lines of, and I’m paraphrasing, “Nobody ever gets it perfectly right the first time. I suppose you always get things right the first time, yes?”.

He was right as well. Nobody ever gets it right the first time. We all have to make decisions based on what we know at the time, and then we have to live with the consequences.

However, there’s not getting it perfectly right the first time, and there’s really not getting it right the first time. In considering this, I arrived at the following long-winded and possibly pointless analogy:

Lets say one day you decided to be a furniture mover. You decide, based on nothing other than the fact you like the colour, (and that it’s got an MP-3 CD player, built-in GPS, and self-parking) that you’ll use a Hyundai i30. When you get to your first job, things start out well enough. You’re able to pack a couple of boxes onto the back seat, you get a hatstand in the front passenger seat, and some clothes get shoved into the boot.

At this point, the home-owner comes out and asks how you plan on moving her 24-foot long, solid marble dining table. In a burst of inspiration, you hire a boilermaker and weld a bunch of steel tubing onto the car making a nice flat area on top. With a great deal of effort, you get the dining table onto the roof, and the car’s wheels bury themselves into the wheel arches.

With the car fully loaded, you decide to set off for the next house. Except you can’t open the drivers door. There’s a steel support strut welded to it now, holding up the dining table on the roof. No problem though, you just smash out the windscreen and climb in over the dash.

You buckle in, turn the engine over, put the automatic transmission into drive, depress the accelerator and… nothing. The engine is revving, you can hear the transmission straining, but the car doesn’t move. Not a problem, you decide. You climb back out the windscreen, jump in a cab and dash to the Hyundai service centre. “Three i30 engines, please!”, you ask confidently. (Let’s just imagine this is possible, for the sake of artistic license…) The smiling and helpful service manager drops three new engines into the back of your cab, and you head back to the house.

You stand back and admire yours and your boilermaker’s skill. You’ve removed the engine from under the bonnet, and bolted an engine to each wheel. Magically, (because this is an analogy – I think…) all the engines hook up to the cars controls perfectly. You climb back in over the dash and fire them all up. Delicately, you squeeze down on the accelerator and the car pulls away from the curb. At this point in time, the heavens open up and a storm like you’ve never seen pounds the car with water droplets the size of dachshunds.

You jam  on the breaks, praying that the dining table doesn’t slide off the front of the jury-rigged assembly holding it up. You reach into the boot and grab one of the shirts. Handing it to the boilermaker you say, “Every ten meters, wipe my face with this.”. At this point, the boilermaker turns to you and says “You didn’t put much thought into this, did you. You should’ve just got a truck with a pan…”. But he doesn’t get to finish the sentence as you cut him off with a tirade about how little he knows about the moving business, and how he should think twice before telling you anything about moving because you’re the moving expert. Etcetera.

Now, let’s do the alternate universe. You’ve decided to be a furniture mover. So, you sit down and thing, “What kind of vehicle will I need to help me carry around furniture?”. Logic dictates that you scribble down a list of things you think people might ask you to move for them – televisions, beds, lounges, fridges, dining tables, boxes, small dogs – and you decide that a medium sized truck with a 20-foot long pantech would be what you want.

You turn up for the first job and the owner mentions they’ve got a 24-foot long, solid marble dining table. Being a reasonable person, you realise you may have made a mistake with the size of the pantech. A quick call to the pantech supermart confirms that they have a 30-foot long one there that they can swap out with yours in about 30 minutes. You tell the owner that it’s not a problem and you’ll be back in an hour.

An hour later you return with your 30-foot long pantech, fit all the owner’s belongings – including the dining table – and are able to drive to the new house even though it’s bucketing down.

I’m sorry that this has been quite a long and seemingly senseless exposition, but my point is, while nobody ever gets it perfect the first time, you can come close with a little bit of thought.

In the software world, it’s impossible to think of every possible variable that will impact the development and operation of any software you’re going to write. You can, however, still take a reasoned and logical approach and consider a fairly significant proportion of the important things. Using that list, you’re then able to formulate an approach for what you have to do based on actual requirements and logic. Not to mention, with some idea of the scope of the problem, you can then consider applying best-practises and industry norms to help speed up the process.

Without making these considerations, you’ll wind up trying to move a 24-foot long dining table with a small Korean hatchback. Justifying your mistake by telling yourself that you made the best decision at the time based on nothing other than ego, or a desire for the shiny-new, or factory options, is ridiculous.

Making an informed decision based on reality and a pre-existing body of knowledge will always mean that, even if you get it wrong, it may be good enough for now, and it will be a lot easier to move it closer to what you really need later on. Don’t be afraid of your limitations, be open about what you know, and be willing to accept you’re wrong. Then fix it.

Wow. I mean, I realise the whole point of putting something in the app store is to get it into other people’s hands, but wow. After finally getting the contracts sorted out (still a GST issue, but that’s a simple thing), LiveTrax Pro went live.

To be perfectly honest, I didn’t think (and really, I still don’t think) that there’s any kind of huge market for LiveTrax Pro. The “back-of-a-napkin” math went something like this. X million iPads sold (let’s say 10 – I know it’s more, but humour me…). Number of performers who own iPads would be X percent of that (let’s say 5% – 500k…). X percent of those would consider using their iPad live (let’s say 5% again – 25k…). Standard conversion rates for app sales are somewhere around 1%, so that leaves 250 people who may buy my app. But that’s not why I wrote it.

It’s a niche app I designed to fill a need I personally had. It’s very focused in its design, and function has been put before form. All that aside, it has been bought buy a few awesome individuals. Perhaps surprisingly (or not, considering everything), a lot of the sales have come from non-English speaking countries.

When I set out to scratch this itch, one of the considerations of the design of the UI was that I wanted it to be simple and clear for everyone, not just the English speakers out there. Now, I only really speak one language. I know some colourful words in a smattering of others, and I learned how to say “Thank you”, “Passenger”, and “Seat” in when I went to Sabah (Borneo).

The easiest way to achieve that was through the use of symbology. I have worked hard on the design to remove any text from the UI. The buttons all use well known symbology that follows what you’d find on a tape transport control, and they all behave in a natural and expected way. The only notable exceptions being the set timer reset button, and the repurposing of the skip-to-end symbol as the symbol for the autoskip functionality.

I’m proud of the app as it stands, but I’ve still got more ideas for it and I’m going to keep improving it as much as I possibly can. To that end, I’m working on fixing the product website to help explain how the app works (it’s pretty simple, really), and I’m setting up some forums on the company website so that I can hopefully start a dialog with the people using the application. I want to provide simply awesome support because I’m grateful that someone has decided my app was worth their money and time. Stay tuned.

So, to those people; thanks.

It appears I have been granted access to that exclusive club, the App Store. Today I received the fantastic news that LiveTrax Pro has been approved for sale!

Unfortunately, right now you won’t be able view it as I am still waiting on an ABN number before my contract is complete. If you think waiting for app approval from Apple can take a long time, trying getting something out of the Australian government…

Anyway,  good news for now. Time to fix up the websites while I’m waiting for my mark of the beast…

In the interests of providing some impetus for myself, I thought I’d detail a few ideas of the posts I want to write. Some of them I’ve been wanting to write for a while, others are new ideas that have come about from my recent journey to the “other side” (read: Apple).

Writing like this is quite new for me, and I know that I’ll be more focused if I put myself under a little bit of pressure by detailing what I’m thinking about. As I write them, I’ll try and update the list to link to the specific articles.

Windows Communication Foundation

• Authentication architecture patterns and implementations.

Silverlight

• Automatic runtime configuration of WCF endpoints.
• Uploading files.
• A deep dive into MVVM.

iOS

• Working with XIB files and code.
• Populating grids.
• Custom drawing grid cells.
• Playing music from the iPod library.
• Memory management in iOS.
• Building applications with XCode 4.0.

Graphic Design for Developers

• Understanding the basic tenets of graphic design.
• Understanding colour.
• Laying out data entry forms.
• Adding some pizazz to your forms.
• Design inspiration.

That’s all I can think of off the top of my head. There are quite a few more. I’ve actually got some half-started posts lying about that will have to remain on hold until the NDA for XCode 4.0 is lifted. Hopefully this list will provide inspiration to get started.

After a little bit of mucking about, I’ve finally submitted my first application to the Apple App Store. (Hence the lack of posting for a few days…) I have to say, the process seems a little convoluted, but that’s most likely because of the need to grab a certificate to sign the code.

Now, in fairness to Apple, I did recently upgrade to XCode 4.0, which means that the instructions detailed in the iTunes Connect site weren’t aimed at me. It took me a little bit of mucking about to find some of the things that need to be found, and I’m pretty sure I’ve still not got the actual distribution build settings quite right. XCode 4.0 has some pretty cool features around build configuration that aren’t clear to me yet.

Anyway, now the long wait begins. They say their typical turn-around is about two weeks. All things considered, I’m expecting a fairly quick response and a rejection seeing as it’s my first submission. Let’s see how that pans out.