Master Key sent for approval

I’ve finally sent Master Key off to the App Hub for approval so I now have to wait and see if it passes and gets published.

Writing my first Windows Phone app has been an interesting process.  Like anything new it’s taken quite a long time to go from a blank sheet of paper through to the final solution and now that I’ve done it once I’m pretty confident that next time it will be much quicker.

Writing for the WP7 platform is great, especially as I’m very experienced with Visual Studio, c# and to a lesser extent Silverlight.  Microsoft have excelled themselves in producing such a great development environment.

I’ve now completed version 1.0 of the application and am already thinking of version 2.0; I would have continued to add features but really wanted to complete the first deployment and get onto the Marketplace.  As I follow a RAD process it can be quite hard to be disciplined and stop development as feedback testing suggests new features and better approaches to solving a problem.

Setting up my account on App Hub has been very time consuming.  As a UK based developer I have to jump through a bunch of US IRS hoops in order to get paid the full royalty amount without losing 30% in withholding taxes.  While this is not much of an issue currently as I’m not expecting any significant royalties it will hopefully be worthwhile in the future.

Along with putting the app up for approval I’ve finally deployed the MDL website.  It does not have a great deal of content currently but I have published the help for Master Key.  The web site is at:

http://www.metadev.co.uk

I used the new WebMatrix tool to create the site and am reasonably happy with the outcome.  I use Discount.ASP as my hosting service; I’ve used them for a few years now and am pretty pleased with their level of support and the functionality.

It took me a few goes to get the deployment to work properly but this was partly down to me using .NET4.0, having to configure IIS7 and modify one of the CSHTML pages so that it wasn’t attempting to connect to a database.

I tried to use FTP but it didn’t work very well and read the recommended method was to use Web Deploy. I used the ‘Import publish settings’ to get the correct info from Discount.ASP and all I had to do was enter my password.  You need to use ‘Validate Connection’ and ensure it passes before deploying.

Take a look at this support article on Discount.ASP site:

http://support.discountasp.net/KB/a891/how-to-deploy-an-application-using-web-deploy-feature.aspx

Configure IIS7 by checking the box to give your Discount.ASP login account access.

I added the following to the web.config – I am not convinced that this is necessary as I do not have a database.

    <connectionStrings>
        <add name="LocalSqlServer" connectionString="x" providerName="System.Data.SqlClient" />
    </connectionStrings>

I still had errors but this time they were more explicit and commenting out this line: 

//WebSecurity.InitializeDatabaseConnection("StarterSite", "UserProfile", "UserId", "Email", true);

in _AppStart.cshtml fixed it and my web site was deployed.

Advertisement

Starting an WP7 app with alternate start page

I have had to change the method for starting Master Key in order to fit in with the way that the WP7 page navigation works.  On the face of it the issue is pretty trivial and one that users would typically only hit once or twice during their use of the App.

WP7 uses a browser based metaphor for moving between pages in an application.  So you can move from page to page and the history is retained on a stack, pressing the back button returns to the previous page.  This can seem confusing, Page1 can invoke Page2 and this can in turn invoke Page1.  However it will NOT be the original Page1 but a new instance of it.  Pressing back on this last page will will return to Page2 and pressing back again will go to the first instance of Page1 (pressing back one more time will close the App).

Master Key requires the user to enter the master key password in order to access the secured information.  However when the user first starts Master Key the user has to enter the password that will be used on subsequent visits and I have a different UI for this.

I originally wrote the code so that the MainPage.xaml checked to see if the users vault (the list of passwords) already exists and if it does not then the page re-directs in the OnNavigatedTo event in MainPage.xaml to a password entry page called EnterPassword.xaml where the user enters the master key.

If the user enters a valid master key and presses ‘ok’ then the vault is set up and the app is ready to use.

However if the user hits the ‘back’ button before entering a valid password then the App is left in a state of limbo and will hit the same OnNavigatedTo event in the MainPage.xaml which will re-invoke the EnterPassword.xaml page again.

I could write code to trap this cycle but wanted to look at the alternatives; one of which is to have different start pages.  I.e. when the vault exists then the MainPage.xaml will be the start page, and if the vault does not exist then EnterPassword.xaml should be the start page.

This is best achieved using Uri remapping by adding the code to the App.xaml.cs Application_Launching event:

private void Application_Launching(object sender, LaunchingEventArgs e)
{
    DAL.LoadVault();

    UriMapper mapper = Resources["uriMapper"] as UriMapper;
    RootFrame.UriMapper = mapper;

    // Update the mapper as appropriate
    if (DAL.VaultExists)
        mapper.UriMappings[0].MappedUri =                   
          new Uri("/MainPage.xaml", UriKind.Relative);
    else
        mapper.UriMappings[0].MappedUri =                   
          new Uri("/EnterPassword.xaml?type=newvault", UriKind.Relative);
}

The App.xaml has to be modified to have a default UriMapper added to it (note the addition of the xmlns:navigation namespace).

<Application
    x:Class="WPVault.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"      
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:phone="clr-namespace:Microsoft.Phone.Controls;assembly=Microsoft.Phone"
    xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone"
    xmlns:navigation="clr-namespace:System.Windows.Navigation;assembly=Microsoft.Phone"
    >

    <!–Application Resources–>
    <Application.Resources>
        <navigation:UriMapper x:Name="uriMapper">
            <navigation:UriMapping Uri="/MainPage.xaml" />
        </navigation:UriMapper>
    </Application.Resources>

It works and I can see uses for it in other Apps; however it comes at a cost that ruled it out for me as the back button behaviour is to return to the page that was navigated from.  This means that once the user has entered the master key password and started to make entries then hitting the back button will return to the EnterPassword.xaml page again which is not a great UX.

I ended up combining the Open and New Vault pages into MainPage.xaml as there is a lot of overlap in their functionality – I then simply drive changes into the UI in the OnNavigatedTo event as appropriate to what the user is doing.  Thus the ‘new vault’ info is shown when the vault does not exist and then when the user returns back to this page again and the vault does exist the ‘open vault’ page is shown.

 

Build Version numbers

A quick note on Visual Studio Build Version numbers as there is some quite confusing notes around and it’s taken me a few hours to get this process working end to end.

Version numbers are vital when building software that is to be released to the outside world and automating at least part of the process ensures that you can pretty much keep track of what is out there.

The default process provides a build number like this: 1.3.4138.18913.

This number represents the following information: Major.Minor.Build.Revision

So the build is version 1.3 and the build number is 4138 and the revision number is 18913.

The build information is maintained in AssemblyInfo.cs

// 1.0 – Password Vault
// 1.1 – first version released to MSFT
// 1.2 – renamed to Master Key
// 1.3 – added remote save/load and refactor UX
[assembly: AssemblyVersion("1.3.*")]

The auto generation of the build/revision only occurs when you remove either AssemblyVersion or AssemblyFileVersion; I have only worked with the former.

I have to set the major/minor build numbers and I include a comment to track the changes.  I only change these when there is a big change to the app and will also set a minor version prior to each release.

I use VS TS Source Control and as part of the development process I label the each change to the Minor build when I have checked the updates in.  This allows me to quickly pull a version from source control when I have an issue reported to me.

Each time I build the solution the Build and Revision numbers will change. The Build is actually the number of days since 31/12/1999 and so only changes when the date changes.  The Revision is the number of seconds since midnight/2.

Getting this info into an About Box where it’s visible to the user is the next task.  There are a bunch of ways to do this but the simplest is the following:

System.Reflection.Assembly execAssembly = System.Reflection.Assembly.GetExecutingAssembly();

string[] version = execAssembly.FullName.Split(',');
textBlockVersion.Text = version[1];

The output looks like this: