DevLink 2011 was a fantastic conference. I met some well-known members of the development community. And I met some brilliant people. Occasionally, these were one-and-the-same!

I presented two sessions at DevLink. The first was on the CAP Theorem. I’ve posted the slides and demo for your perusal. The second was on Correspondence, the same session I gave at Dallas TechFest the week prior. Both sessions were well attended, though I did have problems with my live coding demo in the Correspondence session. Fortunately, the first demo had already gotten the point across.

Like I did for Dallas TechFest, I created a conference application using Correspondence. I pushed this app to the Marketplace for attendees to use. This time, I got 30 downloads out of about 650 attendees, and only one review. So the overall percentage was lower this time around, but still useful.

The one reviewer gave the app 4 out of 5 stars, with the following comment:

So far I really like it. It seems a little slow but I like the format a lot better than the eventboard program.

The EventBoard application that he references was the official app available on the Windows Phone and iPhone platforms. It’s really cool to be favorably compared with a professional app. I think the primary differentiator between the two is that, where EventBoard is all about the event, my app was all about the attendee. The first page of my app shows your schedule. The first page of EventBoard shows a list of events.

Performance enhacements

The reviewer noted that the application seems a little slow. This is because of performance problems in Correspondence. I made some improvements, but was unable to get them into the Marketplace in time. More performance enhancements are on the way.

The first enhancement was to reuse the IsolatedStorageFile object rather than recreating it. Every example of using isolated storage that I’ve seen follows the same pattern:

public class IsolatedStorageStorageStrategy : IStorageStrategy
{
    public static IsolatedStorageStorageStrategy Load()
    {
        var result = new IsolatedStorageStorageStrategy();

        using (IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication())
        {
            using (BinaryReader input = new BinaryReader(store.OpenFile(ClientGuidFileName, FileMode.Open)))
            {
                result._clientGuid = new Guid(input.ReadBytes(16));
            }
        }

        return result;
    }
}

Isolated storage is notoriously slow. It was easy to isolate the slowness to the creation of the IsolatedStorageFile object. So I just changed the pattern:

public class IsolatedStorageStorageStrategy : IStorageStrategy
{
    private IsolatedStorageFile _store;

    private IsolatedStorageStorageStrategy(IsolatedStorageFile store)
    {
        _store = store;
    }

    public static IsolatedStorageStorageStrategy Load()
    {
        IsolatedStorageFile store = IsolatedStorageFile.GetUserStoreForApplication();
        var result = new IsolatedStorageStorageStrategy(store);

        using (BinaryReader input = new BinaryReader(store.OpenFile(ClientGuidFileName, FileMode.Open)))
        {
            result._clientGuid = new Guid(input.ReadBytes(16));
        }

        return result;
    }
}

This was low-hanging fruit. Other performance enhancements that I have in the queue are:

• Pooling the Stream objects instead of opening and closing files.
• Switching from XML to binary serialization of facts for HTTP communications.
• Pulling more facts at a time from the server.
• Evaluating SQL CE as an alternate storage strategy.