Redirecting Navigation in Windows Phone 8

I am working on an app for Windows Phone 8 that uses some custom navigation. I made a class that inherits from UriMapperBase and set it into the RootFrame during application startup. In this mapper I can handle custom Protocols and redirect them to pages in my application.

I also use this mechanism to forward the user to a page to ask them to allow or deny the app rights to use the location services the first time its loaded up. This resulted in a strange case where I was actually redirecting the user to a page other than what they were actually navigating to. When I then attempted to navigate them to the correct page it ended up being a no-op since the current page was at the top of the navigation stack as the uri I was attempting to navigate to. In other platforms the NavigationService has a Refresh method you can call to resolve such problems but in Windows Phone 8 it is mysteriously missing. So after wasting a couple hours I managed to find a way to resolve this cunundrum.

Simply create a page in your application called Refresh.xaml and Navigate to this page. Something like this:

private void OnAllowClick(object sender, RoutedEventArgs e)
  LocationService.AllowLocationServices = true;
  this.NavigationService.Navigate(new Uri("/Views/Refresh.xaml", UriKind.Relative));

Then in Refresh.xaml you simply pop the last item off the navigation stack and navigate back to it:

public partial class Refresh : PhoneApplicationPage
  public Refresh()
  protected override void OnNavigatedTo(NavigationEventArgs e)
    var j = this.NavigationService.RemoveBackEntry();
    this.Dispatcher.BeginInvoke(() => App.RootFrame.Navigate(j.Source));
  protected override void OnNavigatedFrom(NavigationEventArgs e)

This will refresh to the current uri and preserve the navigation stack correctly.

Custom Visual Studio Extension Feeds

I found this difficult to figure out so I thought I would write something up real quick. I recently created a Visual Studio extension for the team I am currently working with. The extension isn’t generally useful but it is useful for my team, so I didn’t want to deploy it to the public extension gallery. One of the things I wanted to figure out was how to distribute the extension to the people on my team so that they just get automatic updates like every other extension.

It turns out all you have to do is to make the extension available via http then create an ATOM feed for your extensions. I just dropped a static atom.xml file onto a webserver on my backup dev machine and update it manually when I get a new build of the extension and presto! You just give your team the URL and they can configure VS to also look at that URL when searching for extensions.

Here is the structure of the atom XML you need to create in your feed to make it work:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="">
  <title type="text"></title>
    <title type="text">Example Extension</title>
    <summary type="text">An example of hosting a VS extension for my team.</summary>
    <content type="application/octet-stream" src="Example.vsix" />
    <Vsix xmlns:xsd="" xmlns:xsi="" xmlns="">
      <References>Visual Studio MPF 11.0\Microsoft.VisualStudio.MPF.11.0\[11.0,);</References>
      <Rating xsi:nil="true" />
      <RatingCount xsi:nil="true" />
      <DownloadCount xsi:nil="true" />

Test Budgeting

I ran across this concept in an internal discussion group a while back and thought it would be worth sharing. Arlo Belshee is the coiner of the phrase as far as I know. The idea is simply that you come up with a threshold of time that you find acceptable for your tests to run in. One which allows you to still maintain a TDD workflow. Below is Arlo’s recommended test budget.
Test Budget
  1. Up to 3 tests that take longer than 2 seconds.
  2. Up to 100 tests that take longer than .02 seconds.
  3. Infinite tests that take less than .02 seconds.
I also think that you should have a ratio of the three, #1 should not comprise more than 1% of your tests and #2 should not be more than 10% of your tests. The idea is that as you’re writing unit tests you need to design your code in such a way so that it is easily testable in order to meet your test budgets. If you’re writing slow tests early you end up hitting a wall and the friction caused by the tests degrades the value proposition of TDD.

This is WAT makes TypeScript good

By now I’m sure you have all seen the hilarious WAT video, but if not here it is for your viewing pleasure:

The very first question that the speaker Gary Bernhardt poses (after the Ruby parts) is that of what is expected when you execute the following javascript:

[ ] + [ ]

He says in that video that he would expect an empty array to result or he would also accept a Type error. But what you actually get when this is run is an empty string. Then we all WAT and laugh. He shows a few other examples of questionable things that javascript will do without any problems whatsoever.

So lets take this famous WAT-inducing example over to the TypeScript playground and lets see what happens…

Type error! So this is wat makes TypeScript good :)