Question

In the near future, I will be adding some features to my WP7 app. As seen here, I will be making some changes to the database. Where and how would you handle updates like this in the code? I don’t think there is a way to add code anywhere than runs on an ‘update’. It’s hardwired into the apps code.

I’m thinking of having a flag that gets set in IsolatedStorage. Name it something like v1.2UpgradeFlag, and set it to false. In the App.xaml.cs, check that flag, and if it is false, meaning the upgrade hasn’t run, run some set of code, and update the flag.

The idea of having code sitting there like that, that may not be applicable to multiple versions ago kind of clunky.

Edit: I’m also curious how I would manage cumulative updates to the application. So in v1.2, I have some code that updates the database schema. What if someone buys the app while it is at v1.3? I don’t want them ‘getting’ v1.1, having the app run 1.2 upgrade code, to get to v1.3.

Answer 1

Since this is the first time you will have to run a database upgrade, I would be tempted to add an extra table to the schema that will hold the version information. If, when you attempt to retrieve the data, it gives a NotFound error, you know you will need to run the upgrade. That way, you can manage the process in subsequent versions without having to manage the extra file.

In order to do cumulative updates, you can use the same mechanism. You can maintain a method that will update the database from v1 to v1.2, another method to go from 1.2 to 1.3, etc. The method that maintains the upgrade process may look something like this pseudocode…

var currentDbVersion = GetDbVersion();
while(currentDbVersion < currentCodeVersion)
{
    switch(currentDbVersion)
    {
        case 1.2:
            RunUpgradeFrom12to13();
            break;
        case 1.3:
            RunUpgradeFrom12to13();
            break;
        default:
            break;
    }
    currentDbVersion = GetDbVersion();
}

That should allow you to upgrade from any previous version to the current without maintaining several code paths (since a 1.0 to 1.2 upgrade will never change, and you should have a known start position for each cumulative step)

There may well be far more sensible ideas out there, but this is the first thing I thought of.