Dotnet by Example

Windows Phone 8 navigation part 4–updating the tests, fixing the final issues

noreply@blogger.com (Joost van Schaik) — Mon, 13 May 2013 09:01:00 PDT

Last time: so close, yet so far:

This series appears to have become a trilogy in four parts – at the end of the last episode everything worked, save for tombstoning, although we explicitly wrote test code for that. The the app tombstoned, partially - two things were apparently missing:

The route
The locations to and from the route should run.

Making the tests fail

An important step when you have a bug in an app that passes all tests, is to make a test that fails because of the bug. In that case, you have reproduced the problem, and can start on fixing the bug. Logically, the bug is fixed when the test no longer fails – and should anyone start to mess around with your code an re-introduce the bug, the test will fail again, indicating something has gone wrong before you even ship. Your tests have become a smoke detector ;-)

Anyway, we observe there is no selected location, nor routes or waypoints after tombstoning. When we look at the comprehensive test for RoutingViewModel written in the 2nd post of this series, we see the following Assert statement with regard to the retrieved viewmodel:

Assert.IsTrue(vm.RouteCoordinates.Any());
Assert.IsTrue(vm.Maneuvers.Any());
Assert.IsTrue(retrievedVm.RouteCoordinates.Count == vm.RouteCoordinates.Count);
Assert.IsTrue(retrievedVm.FromViewModel.SearchText == "Springerstraat Amersfoort Netherlands");
Assert.IsTrue(retrievedVm.Maneuvers.Count == vm.Maneuvers.Count);

Shockingly, we learn two things:

We indeed don’t test the presence of either SelectedLocation or either FromViewModel and ToViewModel.
We do test the presence of both RouteCoordinates and Maneuvers. So our viewmodel works in that respect – so the error must have to do something with data binding.

First, we add test code for SelectedLocation

Assert.IsNotNull(retrievedVm.FromViewModel.SelectedLocation);
Assert.IsNotNull(retrievedVm.ToViewModel.SelectedLocation);

And sure enough:

Annoyingly, this does only say which test failed, but not what exactly failed in this test. You can of course follow the purist route and write a separate test method for every assert, or just be lazy like me and use the overload every Assert method has:

Assert.IsNotNull(retrievedVm.FromViewModel.SelectedLocation, 
  "No FromViewModel.SelectedLocation tombstoned");
Assert.IsNotNull(retrievedVm.ToViewModel.SelectedLocation, 
 "No ToViewModel.SelectedLocation tombstoned");

And there we are. A clear error message. There is no SelectedLocation after tombstoning

Fixing the SelectedLocation bug aka serialization under the hood

Let me introduce you to the wonderful world of serialization. Much as we move into the world of asynchronous and parallel programming, serialization is essentially a sequential process. First property A is written, then property B. When something is deserialized, things are also read from storage in a particular order, i.e. the order they are written.

Let’s get back to the RoutingViewModel. I’ve abbreviated the property implementation a bit, apart from the Model. There we see the following code:

public ManeuverViewModel SelectedManeuver

public GeocodeViewModel ToViewModel

public GeocodeViewModel FromViewModel

public ObservableCollection<RouteGeometryViewModel> RouteCoordinates { get; set; }

public ObservableCollection<ManeuverViewModel> Maneuvers { get; set; }

private NavigationModel model;
public NavigationModel Model
{
  get { return model; }
  set
  {
    model = value;
    if (model != null)
    {
      ToViewModel = new GeocodeViewModel(model.To) { Name = "To" };
      FromViewModel = new GeocodeViewModel(model.From) { Name = "From" };
    }
  }
}

Now let’s assume, for a moment, serialization simply reflects all public properties with both getter and setter, and writes them one by one to storage – and reads them in the same order. In no particular order – if this were a database that most probably means the order the in which records were put in. Could it be reflection works the same way? But then, deserializing would mean that first the SelectedManeuver would be deserialized, then ToViewModel and FromViewModeland, then the RouteCoordinates, then the Maneuvers, and finally the model. But smart Mr Me has implemented this clever method of initializing FromViewModel and ToViewModel upon calling of the setter. So whatever was deserialized into FromViewModel and ToViewModel gets overwritten after Model is deserialized!

So let’s make the Model property the very first property of the viewmodel, right after the constructors, run the test and see what happens…

You can imagine with this kind of arcane stuff going on behind the curtains, (unit) test code can be a really great tool to track and fix this kind of obscure errors – and make sure they never, ever occur suddenly again, just because someone changed the order in the way things are implemented!

Fixing the MapShapeDrawBehavior bug

This is a bit of odd one – apparently the developer that made the MapShapeDrawBehavior – a knucklehead who names himself “LocalJoost” ;-) - has made an error implementing data binding – while he implemented listening to all the collection events correctly, he never apparently anticipated the initial collection should could have some values before data binding ensued. The advantage of open source is that we actually can see this. So, we either have to copy MapShapeDrawBehavior ‘s code and make a manual fix to make sure some event occurs that makes it go draw the stuff – or implement a band-aid that does not interfere with the existing code.

I pulled out the band, aid, and made the following class:

using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Collections.Specialized;

namespace Wp7nl.Utilities
{
  public class ResettableObservableCollection<T> : ObservableCollection<T>
  {
    public ResettableObservableCollection()
    {
    }

    public ResettableObservableCollection(List<T> list)
      : base(list)
    {
    }

    public ResettableObservableCollection(IEnumerable<T> list)
      : base(list)
    {
    }

    public void ForceReset()
    {
      OnCollectionChanged(
       new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));
    }
  }
}

I changed both RouteCoordinates and Maneuvers in RoutingViewmodel into ResettableObservableCollection, added the following command to RoutingViewmodel:

[DoNotSerialize]
public ICommand MapLoadedCommand
{
  get
  {
    return new RelayCommand( ()=>
        {
          RouteCoordinates.ForceReset();
          Maneuvers.ForceReset();
        });
  }
}

and finally, the following piece of XAML to the map:

<i:Interaction.Triggers>
  <i:EventTrigger  EventName="Loaded">
    <Command:EventToCommand Command="{Binding MapLoadedCommand}"/>
  </i:EventTrigger>
</i:Interaction.Triggers

This will fire the command directly after the map has loaded. Data binding has already occurred then. And sure enough, even after restarting the app, everything is reloaded from storage. The behavior is tricked into believing it should draw it’s stuff. Now I only need to publish my app, and inform this LocalJoost character that his library contains bugs and if he can fix them ASAP, thank you very much.

Concluding remarks

This series did not only show you the basics of Windows Phone 8 navigation, but also how to develop geo-applications on Windows Phone 8 using unit/integration test to explore and test functionality, as well as using test as a way to hunt down and fix bugs. It also showed that if your test are incomplete, you might get bitten. And finally it showed you that, in the end, you still need to test manually to catch bugs that are caused by dunderheads making errors in their published code ;-)

The final solution can be found here,

Windows Phone 8 navigation part 3–assembling the MVVMLight app

noreply@blogger.com (Joost van Schaik) — Fri, 10 May 2013 04:34:00 PDT

Last time on, on Dotnetbyexample…

In the first post I described how to write the business logic to find a location by searching for an address by text, and in the second post I described how to do some actual routing – still, only business logic and viewmodels. And we kept in mind all the results should be tombstonable, and how to make sure this all worked by using simple unit/integration tests.

Today, it’s time for the actual app. Bear in mind this post will actually refer to a lot of earlier other posts – from even outside this series. In this post I am also going to show you that working with you designer sometimes means you need to make little tweaks to your viewmodels to make it work the way you want, or make life easier on the designer. Remember, you are the technician, the person who needs to make it finally work.

GUI and interaction design

So, after conferring with the designer we have agreed the app should work like this:

Windows Phone 8 navigate by MVVMLight

The route is displayed as a line, every maneuver as a star, and when you tap that star it should show a panel showing the maneuver description. For interested parties – this is a car route I could take to my home to my work at Vicrea ;-)

Well – the moving panels are easy to solve with some View States and DataTriggers – I’ve been down that road before. Showing a line and points on a map from the view model – been there done that, wrote behaviors for that and those are snugly in the wp7nl library which is, not quite coincidental, part of this solution already.

So, we need to do the following:

Define the app user interface, that is:

Two panels enabling the user to input text and select a route, e.g. a user interface for both the GeocodeViewModels in RoutingViewmodel. We’ll make a user control from that
A panel with From/To info making showing the address from an to, and making it possible to let the From and To panel into view. This will be a user control as well
A button firing off the RoutingViewmodel’s DoRoutingCommand
A panel that’s shown as the user taps a maneuver. This, too, will be a user control.
A Map

A MainViewModel that’s acting as a kind of locator and a serialization root point, like I always do.
Something to handle the view state.

Adding ViewState management

Just like I did before in this post, I added a DisplayState enumeration in de NavigationDemo.Logic project, like this:

namespace NavigationDemo.Logic.States
{
  public enum DisplayState
  {
    Normal = 0,
    SearchFrom = 1,
    SearchTo = 2,
    ShowManeuver = 3
  }
}

one state for every panel, and a “Normal” state for every other panel. And then I decided to take the easy way out and add the state control to the RoutingViewmodel, basically to make data binding easier. Of course I could have made a separate view model for this, but what the heck, it’s only a few lines of code anyway:

[DoNotSerialize]
public ICommand DisplayPopupCommand
{
  get
  {
    return new RelayCommand<string>(
        p =>
        {
          DisplayState = (DisplayState)Enum.Parse(typeof(DisplayState), p);
        });
  }
}

private DisplayState displayState;
public DisplayState DisplayState
{
  get { return displayState; }
  set
  {
    if (displayState != value)
    {
      displayState = value;
      RaisePropertyChanged(() => DisplayState);
    }
  }
}

It makes life easier on the designer, he does not have mess around with data context so much. The property is the actual storage for the DisplayState, and the command sets the display state to it's parameter. All described before. The final piece is a little adaption in the SelectedManeuver property, there we need to add in the setter:

DisplayState = SelectedManeuver != null ? DisplayState.ShowManeuver : DisplayState.Normal;

directly behind the RaisePropertyChanged. This will have the panel showed automatically when a non-null value is detected after the setter has been accessed.

GeocodeViewModel ui

I tend to put user controls into a separate folder UserControls (never been one for original naming conventions anyway). The design of the GeocodeControl looks like this:

And I’ve put it in XAML like this:

<UserControl.Resources>
  <DataTemplate x:Key="AddressTemplate">
    <Grid>
      <TextBlock HorizontalAlignment="Left" TextWrapping="Wrap" Text="{Binding Address}"
       VerticalAlignment="Top"/>
    </Grid>
  </DataTemplate>
</UserControl.Resources>

<Grid x:Name="LayoutRoot" Background="{StaticResource PhoneChromeBrush}">
  <Grid Margin="12,0" >
    <!-- Definitions omitted -->

    <Button Grid.Column="2"  Style="{StaticResource RoundButton}" 
        Command="{Binding SearchLocationCommand, Mode=OneWay}"
        VerticalAlignment="Bottom" HorizontalAlignment="Left" Height="72" Width="72"
        Margin="0,0,-5,0" >
      <Rectangle Fill="{StaticResource PhoneForegroundBrush}" Width="44" Height="44" >
        <Rectangle.OpacityMask>
          <ImageBrush ImageSource="/images/feature.search.png" Stretch="Fill"/>
        </Rectangle.OpacityMask>
      </Rectangle>
    </Button>
    <TextBlock TextWrapping="Wrap" Text="Search" VerticalAlignment="Center" 
               Height="27" Margin="0,23,0,22" />
    <TextBlock TextWrapping="Wrap" Text="Found" Grid.Row="1" 
       VerticalAlignment="Center" Height="27"/>
    <TextBox Grid.Column="1" TextWrapping="NoWrap" 
        Text="{Binding SearchText, Mode=TwoWay}">
      <i:Interaction.Behaviors>
        <Behaviors:TextBoxChangeModelUpdateBehavior/>
      </i:Interaction.Behaviors>
    </TextBox>
    <ListBox Grid.Column="1" Grid.Row="1" Margin="12" ItemsSource="{Binding MapLocations}" 
      SelectedItem="{Binding SelectedLocation,Mode=TwoWay}" 
      ItemTemplate="{StaticResource AddressTemplate}"/>
    <Button Content="Done" Grid.Row="2" Grid.Column="1" VerticalAlignment="Center" 
       Margin="0,23,0,22" Height="71" Command="{Binding DoneCommand}"/>     
  </Grid>
</Grid>

There will be two instances of this user control – one to determine the “From” address, and one for the “”To” address.

There are some things to note here, all underlined in red:

I am using a RoundButton style to get a round button, to show an standard image feature_search.png. I pulled this ages ago from this post by Alex Yakhnin if I am not mistaken.
There is no data context set, therefore, the data context – a GeocodeViewModel – should be set in the parent element. No problem. But the DoneCommand, which should dismiss the panel, is therefore also in the GeocodeViewModel, and there is no code for that. Worse, the actual state control logic is in a totally different view model – in this case the RoutingViewmodel. Two view models, having no real knowledge of each other, yet needing to get some data across – that spells m-e-s-s-e-n-g-e-r.

Adding some Messenger magic

We define a simple message “DoneMessage” that, when received by the RoutingViewmodel (that also keeps the view state) will dismiss all popups. It’s pretty easy to implement:

namespace NavigationDemo.Logic.Messages
{
  public class DoneMessage{ }
}

And in the RoutingViewmodel, in the constructor, just one line:

Messenger.Default.Register<DoneMessage>(this, 
    msg => DisplayState = DisplayState.Normal);

Well, okay, one line split in two ;). But anyway, this allows to add a DoneCommand in GeocodeViewModel simply like this:

[DoNotSerialize]
public ICommand DoneCommand
{
  get
  {
    return new RelayCommand(() => Messenger.Default.Send(new DoneMessage()));
  }
}

And boom – executing the DoneCommand in RoutingViewmodel will reset the DisplayState to Normal, dismissing all popups. That is, as soon as we have implemented the DataTriggers and the ViewStates ;-)

LocationPanel

This is the thing used to scroll the GeocodeControls into view, looking like this

<Grid Height="144" VerticalAlignment="Top" Background="#7F000000">
  <Grid Margin="12,0">
    <Grid >
      <!-- Definitions omitted -->
      <TextBlock TextWrapping="Wrap" Text="From" VerticalAlignment="Top"
         Margin="0,12,0,0" Height="27"  />
      <TextBlock TextWrapping="Wrap" Text="To" Grid.Row="1" VerticalAlignment="Top"
         Margin="0,12,0,0" Height="27"/>
      
      <TextBlock TextWrapping="Wrap" Text="{Binding FromViewModel.SelectedLocation.Address, 
        Mode=TwoWay}" Grid.Column="1" VerticalAlignment="Top" Margin="0,12,0,0" />
      <TextBlock  TextWrapping="Wrap" Text="{Binding ToViewModel.SelectedLocation.Address, 
        Mode=TwoWay}" Grid.Row="1" Grid.Column="1" VerticalAlignment="Top" Margin="0,12,0,0"  />
        
      <Button Grid.Column="2"  Style="{StaticResource RoundButton}" 
          Command="{Binding DisplayPopupCommand, Mode=OneWay}" CommandParameter="SearchFrom"
          VerticalAlignment="Center" HorizontalAlignment="Left" Height="72" 
          Width="72" Margin="0,0,-10,0" >
        <!-- Rounded button stuff omitted -->
      </Button>
      <Button Grid.Column="2"  Grid.Row="1" Style="{StaticResource RoundButton}" 
          Command="{Binding DisplayPopupCommand, Mode=OneWay}" CommandParameter="SearchTo"
          VerticalAlignment="Center" HorizontalAlignment="Left" Height="72" Width="72"
           Margin="0,0,-10,0">
        <!-- Rounded button stuff omitted -->
      </Button>
    </Grid>
  </Grid>
</Grid>

for the sake of brevity I cut some things out of the XAML. Most interesting to note here, once again red and underlined:

The 3nd and the 4th TextBlock show the Address of the Selected location of the From and the To GeocodeViewModel
The buttons both call the same command, but with a parameter – this will determine which popup appears. Or actually, the viewstate which will be selected, but that amounts to the same

ManeuverPopup

This is the popup that appears from the side, as the user has tapped on a start.

It’s a pretty simple piece, both how it looks and in XAML:

<Grid x:Name="LayoutRoot" Background="{StaticResource PhoneChromeBrush}" Opacity="0.9">
  <Grid Margin="12,0" >
    <Grid.RowDefinitions>
      <RowDefinition Height="*"/>
      <RowDefinition Height="76"/>
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
    </Grid.ColumnDefinitions>
    <TextBlock Grid.Row="0" TextWrapping="Wrap" Text="{Binding Description}" 
      HorizontalAlignment="Center"/>
    <Button Content="Close" Grid.Row="1" VerticalAlignment="Center"     
      Height="71" Width="313" Command="{Binding DoneCommand}" />
  </Grid>
</Grid>

With only one thing really to note – this popup needs to be able to be dismissed to – so we can implement the exact same DoneCommand as in GeocodeViewModel and put it into ManeuverViewModel. Copy – paste – done. Of course you can also make a base class for both viewmodels and making both GeocodeViewModel ManeuverViewModel child classes of it. This won’t save you much code in this case though.

MainViewModel

This is kinda not very interesting – see for an explanation on usage this post, that’s quite old already. MainViewModel is the root for all view model, used as a starting point for data binding and tomb stoning But this is what we are going to use a binding root. How the initialization and tombstoning from App.xaml.cs is working is described in the same post, some I am not going to repeat that. This particular MainViewModel looks like this:

using GalaSoft.MvvmLight;
using NavigationDemo.Logic.Models;

namespace NavigationDemo.Logic.ViewModels
{
  public class MainViewModel : ViewModelBase
  {
    public NavigationModel Model { get; set; }

    public MainViewModel()
    {
    }

    public MainViewModel(NavigationModel model)
    {
      Model = model;
    }

    private RoutingViewmodel routingViewModel;
    public RoutingViewmodel RoutingViewModel
    {
      get
      {
        if (routingViewModel == null)
        {
          routingViewModel = new RoutingViewmodel(Model);
        }
        return routingViewModel;
      }
      set
      {
        if (routingViewModel != value)
        {
          routingViewModel = value;
          RaisePropertyChanged(() => RoutingViewModel);
        }
      }
    }

    private static MainViewModel instance;
    public static MainViewModel Instance
    {
      get
      {
        return instance;
      }
      set { instance = value; }
    }

    public static MainViewModel CreateNew()
    {
      if (instance == null)
      {
        instance = new MainViewModel(new NavigationModel());
      }
      return instance;
    }
  }
}

We define it as a data source in App.Xaml

<ViewModels:MainViewModel x:Key="MainViewModelDataSource"/>

Which requires the following definition in your App.xaml header:

xmlns:ViewModels="clr-namespace:NavigationDemo.Logic.ViewModels;assembly=NavigationDemo.Logic"

MainPage.xaml – the main gui

Initially, this has four major parts:

The header
The Map
The three routing panels (2x GeocodeControl + 1x LocationPanel)
The ManeuverPopup
The search button.

Now the header is simple enough:

<Grid x:Name="LayoutRoot" Background="Transparent" 
  DataContext="{Binding Instance, Source={StaticResource MainViewModelDataSource}}">
  <Grid.RowDefinitions>
    <RowDefinition Height="Auto"/>
    <RowDefinition Height="*"/>
  </Grid.RowDefinitions>

  <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
    <TextBlock Text="NAVIGATE BY MVVMLIGHT" 
      Style="{StaticResource PhoneTextNormalStyle}" Margin="12,0"/>
  </StackPanel>

The only more or less interesting part is the data binding. Then comes the map. This uses my MapShapeDrawBehavior to bind the shapes to map:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0" 
   DataContext="{Binding RoutingViewModel}">
  <maps:Map Wp8nl_MapBinding:MapBindingHelpers.MapArea="{Binding ViewArea}"
              Center="{Binding MapCenter, Mode=TwoWay}"
              ZoomLevel="{Binding ZoomLevel, Mode=TwoWay}">
    <i:Interaction.Behaviors>
      <MapBinding:MapShapeDrawBehavior LayerName="Route" ItemsSource="{Binding RouteCoordinates}" 
        PathPropertyName="Geometry">
        <MapBinding:MapShapeDrawBehavior.ShapeDrawer>
          <MapBinding:MapPolylineDrawer Color="Green" Width="10"/>
        </MapBinding:MapShapeDrawBehavior.ShapeDrawer>
      </MapBinding:MapShapeDrawBehavior>
      <MapBinding:MapShapeDrawBehavior LayerName="Maneuvers" ItemsSource="{Binding Maneuvers}" 
        PathPropertyName="Location">
        <MapBinding:MapShapeDrawBehavior.ShapeDrawer>
          <MapBinding:MapStarDrawer Color="Red" Arms="8" InnerRadius="25" OuterRadius="50"/>
        </MapBinding:MapShapeDrawBehavior.ShapeDrawer>
        <MapBinding:MapShapeDrawBehavior.EventToCommandMappers>
          <MapBinding:EventToCommandMapper EventName="Tap" CommandName="SelectCommand"/>
        </MapBinding:MapShapeDrawBehavior.EventToCommandMappers>
      </MapBinding:MapShapeDrawBehavior>
  </maps:Map>

Things of notice here:

The grid where the map is in (and incidentally, almost the whole user interface, has the RoutingViewModel as it’s data context.
Map view area is not bindable so that’s bound using a simple attached dependency property, I will include this in the coming version for the wp7nl library on codeplex but skip it for now. Center and ZoomLevel are simple direct property bindings
The actual route is a green line, bound to RouteCoordinates. TheMapShapeDrawBehavior actually expects a list of objects, so we gave it a list, remember from the previous post?
The Maneuvers are display as red stars, by binding a MapShapeDrawBehavior to the Maneuvers list. If one is tapped, the SelectCommand on the ManeuverViewModel is fired, causing the the selected maneuver to be sent over the Messenger

Next, are the three panels:

<UserControls:LocationsPanel VerticalAlignment="Top"/>
<UserControls:GeocodeControl x:Name="GeocodeFrom" VerticalAlignment="Top" 
        RenderTransformOrigin="0.5,0.5" 
        DataContext="{Binding FromViewModel}">
  <UserControls:GeocodeControl.RenderTransform>
    <CompositeTransform TranslateY="-326"/>
  </UserControls:GeocodeControl.RenderTransform>
</UserControls:GeocodeControl>
<UserControls:GeocodeControl x:Name="GeocodeTo" VerticalAlignment="Top" 
       RenderTransformOrigin="0.5,0.5"
       DataContext="{Binding ToViewModel}">
  <UserControls:GeocodeControl.RenderTransform>
    <CompositeTransform TranslateY="-326"/>
  </UserControls:GeocodeControl.RenderTransform>
</UserControls:GeocodeControl>
<UserControls:ManeuverPopup x:Name="maneuverPopup" VerticalAlignment="Bottom" 
     Height="151" RenderTransformOrigin="0.5,0.5" Margin="0,0,0,72"
     DataContext="{Binding SelectedManeuver}">
  <UserControls:ManeuverPopup.RenderTransform>
    <CompositeTransform TranslateX="470"/>
  </UserControls:ManeuverPopup.RenderTransform>
</UserControls:ManeuverPopup>

Actually rather straightforward. From panel binds to FromViewModel, To panel to ToViewModel, and the maneuverPopup to SelectedManeuver.

The last part ain’t rocket sciece: just a simple BindableApplicationBar with one button executing the actual routing command:

<phone7Fx:BindableApplicationBar BarOpacity="0.9" >
  <phone7Fx:BindableApplicationBarIconButton Command="{Binding RoutingViewModel.DoRoutingCommand}"
                                             IconUri="/images/feature.search.png"
                                             Text="Route" />
</phone7Fx:BindableApplicationBar>

The only thing to notice is that since it’s sitting outside the content panel, in the main grid, it’s data content is het MainViewModel to I have to prepend the RoutingViewModel again.

DataTrigger Animation Magic

I am going to keep this simple: if you want to know how to create this, I suggest you read my article on ViewModel driven multi-state animations using DataTriggers and Blend on Windows Phone. I have created the following visual states:

<VisualStateManager.CustomVisualStateManager>
  <ei:ExtendedVisualStateManager/>
</VisualStateManager.CustomVisualStateManager>
<VisualStateManager.VisualStateGroups>
  <VisualState x:Name="Normal"/>
  <VisualStateGroup x:Name="Search">
    <VisualStateGroup.Transitions>
      <VisualTransition GeneratedDuration="0:0:0.5"/>
    </VisualStateGroup.Transitions>
    <VisualState x:Name="SearchFrom">
      <Storyboard>
        <DoubleAnimation To="0" 
          Storyboard.TargetProperty="(UIElement.RenderTransform).(CompositeTransform.TranslateY)" 
          Storyboard.TargetName="GeocodeFrom"/>
      </Storyboard>
    </VisualState>
    <VisualState x:Name="SearchTo">
      <Storyboard>
        <DoubleAnimation To="0" 
          Storyboard.TargetProperty="(UIElement.RenderTransform).(CompositeTransform.TranslateY)" 
          Storyboard.TargetName="GeocodeTo"/>
      </Storyboard>
    </VisualState>
     <VisualState x:Name="ShowManeuver">
      <Storyboard>
        <DoubleAnimation Duration="0" To="0" 
          Storyboard.TargetProperty="(UIElement.RenderTransform).(CompositeTransform.TranslateX)" 
          Storyboard.TargetName="maneuverPopup" />
      </Storyboard>
    </VisualState>
  </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

You can see “Search” moves “GeocodeFrom” into view, “SearchTo” moves GeocodeTo into view, and “ShowManeuver” shows the maneuverPopup. And Normal is the base state, basically moving everything back to it’s base place, i.e. out of the screen. I also created these data triggers.

 <i:Interaction.Triggers>
  <ei:DataTrigger Binding="{Binding DisplayState}" Value="0">
    <ei:GoToStateAction StateName="Normal" />
  </ei:DataTrigger>
  <ei:DataTrigger Binding="{Binding DisplayState}" Value="1">
    <ei:GoToStateAction StateName="SearchFrom" />
  </ei:DataTrigger>
  <ei:DataTrigger Binding="{Binding DisplayState}" Value="2">
    <ei:GoToStateAction StateName="SearchTo" />
  </ei:DataTrigger>
  <ei:DataTrigger Binding="{Binding DisplayState}" Value="3">
    <ei:GoToStateAction StateName="ShowManeuver" />
  </ei:DataTrigger>
</i:Interaction.Triggers>

These are all sitting inside the contentpanel, right above the map.

And finally… well… not really

If you run the app now – or download the sample solution, lo and behold – the app works as designed. That is … until you press the start button and start the app anew. You will notice the fact that although the right location is displayed, the route is not, the LocationPanel is empty again, but the search text is not. How the hell is this possible? We have written test till the cows came home!

Well, I can tell you we have run in some very subtle serialization bugs. Fixing those bugs is what we are going to do in the next and last episode. Like I said in the previous episode, no amount of unit and/or integration testing is going to free you from manually testing your app – is just a tool to increase, maintain and guarantee the quality of some parts of your app.

Anyway – the solution so far can be downloaded here.

Windows Phone 8 navigation part 2–routing, route details,tombstoning–and testing

noreply@blogger.com (Joost van Schaik) — Tue, 30 Apr 2013 16:50:00 PDT

What happened last time on this show

In the previous post I described to how to write the business logic to find a location by searching for an address by text, how to be able to tombstone the results, and how to make sure this all worked by using simple tests. Fine, but the purpose was routing, that is, actually making the app finding instructions to get from A to B. As a GIS buff, being used to complex algorithms and stuff, this is almost embarrassingly easy in Windows Phone 8. You basically need an object of type RouteQuery, plonk in any number of waypoints (at least two, of course, being the start and the end) and a method of transport (drive or walk). And that’s basically it.

But we still have to honor the other two requirements – in needs to be testable and serializable so we can support tombstoning

Find the route, ~~Luke~~ phone

So in the solution I created last time I add another business class that does the actual finding of the route:

using System.Collections.Generic;
using System.Device.Location;
using System.Threading.Tasks;
using Microsoft.Phone.Maps.Services;
using Wp7nl.Utilities;

namespace NavigationDemo.Logic.Models
{
  public class NavigationModel
  {
    public NavigationModel()
    {
      From = new GeocodeModel();
      To = new GeocodeModel();
    }

    public async Task DoRouting()
    {
      await DoRouting(From.SelectedLocation.GeoCoordinate, 
                      To.SelectedLocation.GeoCoordinate);
    }

    public async Task DoRouting(GeoCoordinate from, GeoCoordinate to)
    {
      var wayPoints = new List<GeoCoordinate>(new[] { from, to });
      var routeQuery = new RouteQuery 
        { TravelMode = TravelMode.Driving, Waypoints = wayPoints };
      FoundRoute = await routeQuery.GetRouteAsync();
    }

    public Route FoundRoute { get; set; }   

    public GeocodeModel From { get; set; }

    public GeocodeModel To { get; set; }
  }
}

This comes in the NavigationDemo.Logic project, in the Models folder, next to GeocodeModel. Here you can see what I just mentioned – the actual navigation logic is very simple. This whole model comes down to three lines (red, bold and underlined). But, does this work?

Testing the routing

In the unit test app I added a NavigationModelTest class. To ease testing, I created public overload method where I can directly supply the waypoints. We already know the GeocodeModel works. We have tested that before.

using System;
using System.Device.Location;
using System.Linq;
using System.Threading;
using System.Windows;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
using NavigationDemo.Logic.Models;

using Wp7nl.Utilities;

namespace NavigationDemo.Logic.Test
{
  [TestClass]
  public class NavigationModelTest
  {
    [TestMethod]
    public void TestPointRouting()
    {
      var m = new NavigationModel();

      var waitHandle = new AutoResetEvent(false);

      Deployment.Current.Dispatcher.BeginInvoke(async () =>
      {
        await m.DoRouting(
            new GeoCoordinate(52.182679977268, 5.39752000942826),
            new GeoCoordinate(52.1061999723315, 5.03457002341747));
        waitHandle.Set();
      });

      waitHandle.WaitOne(TimeSpan.FromSeconds(25));

      Assert.IsTrue(m.FoundRoute.Geometry.Any());
    }
  }
}

Route finding is async as well and needs to run on the UI thread, hence the hoopla with the AutoResetEvent and the Dispatcher. Basically I ask the the RouteQuery to find some route from one place to another in the Netherlands. For those interested: it’s a road I drove for many a hackathon – from my street to the street where our former Dutch DPE Matthijs Hoekstra used to live before he decided to go upstream to Seattle to join the Windows Phone team. I actually seem to recall I wrote this very code in his house at the last ‘kitchen table’ hackathon :-)

There are two things to wonder at at this point:

Will this serialize to support tombstoning? (remember from the previous post the MapLocation that came back from GeocodeQuery did not)
What the hell is it that we find?

Does this serialize?

I added a second test to NavigationModelTest which is basically an extended version of the first.

[TestMethod]
public void TestStoreNavigationModel()
{
  var m = new NavigationModel();

  var waitHandle = new AutoResetEvent(false);

  Deployment.Current.Dispatcher.BeginInvoke(async () =>
  {
    await m.DoRouting(
        new GeoCoordinate(52.182679977268, 5.39752000942826),
        new GeoCoordinate(52.1061999723315, 5.03457002341747));
    waitHandle.Set();
  });

  waitHandle.WaitOne(TimeSpan.FromSeconds(25));

  var h = new IsolatedStorageHelper<NavigationModel>();
  if (h.ExistsInStorage())
  {
    h.DeletedFromStorage();
  }
  h.SaveToStorage(m);

  var retrieved = h.RetrieveFromStorage();

  Assert.IsTrue(retrieved.FoundRoute.Geometry.Any());
}

And here we go again: the test fails with SilverlightSerializer complaining that “Could not construct an object of type 'Microsoft.Phone.Maps.Services.Route', it must be creatable in this scope and have a default parameterless constructor”. So we basically have the same problem we had in the previous post. The way to make this test work is to adorn FoundRoute in NavigationModel

[DoNotSerialize]
public Route FoundRoute { get; set; }

and change the last line of test a little

Assert.IsNotNull(retrieved);

The test now succeeds, but the route you found is now of course still not serialized. You can wonder (or gripe on twitter) why Microsoft have implemented it this way, but that won’t get your app any closer to shipping. It simply means we have to defer tombstoning of the found route to the viewmodel again, just like in the previous post.

What DO we get back?

Actually, quite a lot. The routing information is very detailed. The main Route class has the following properties and methods:

public class Route : IRoutePath
{
  public LocationRectangle BoundingBox { get; internal set; }
  public TimeSpan EstimatedDuration { get; internal set; }
  public ReadOnlyCollection<Device.Location.GeoCoordinate> Geometry 
         { get; internal set; }
  public ReadOnlyCollection<RouteLeg> Legs { get; internal set; }
  public int LengthInMeters { get; internal set; }
}

A route can exist out of multiple RouteLeg objects (if you give the RouteQuery more than two waypoints. RouteLeg is defined as follows:

public class RouteLeg : IRoutePath
{
  public LocationRectangle BoundingBox { get; internal set; }
  public TimeSpan EstimatedDuration { get; internal set; }
  public ReadOnlyCollection<Device.Location.GeoCoordinate> Geometry 
        { get; internal set; }
  public int LengthInMeters { get; internal set; }
  public ReadOnlyCollection<RouteManeuver> Maneuvers 
       { get; internal set; }
}

Which makes me feel that a RouteLeg and a Route are nearly the same object and there might have been some code re-use possibilities, but I digress. A RouteLeg consists, apart from a geometry, out of various RouteManeuvers, which look like this:

public class RouteManeuver
{
  public RouteManeuverInstructionKind InstructionKind { get; internal set; }
  public string InstructionText { get; internal set; }
  public int LengthInMeters { get; internal set; }
  public GeoCoordinate StartGeoCoordinate { get; internal set; }
}

The InstructionText literally contains stuff like “Turn left on xyz street” and a location where this should happen. RouteManeuverInstructionKind is an enum describing the kind of instruction and really is so comprehensive it’s actually a bit hilarious, so go and have a look on it. But you can very much use this to depict what you the driver needs to do, and I am pretty sure this is what Nokia’s “Here Drive” uses under the hood. So here we have a full fledged routing API under the hood – but there’s no way in Hades we are ever going to serialize that will all those internal sets, as we already ascertained.

In real life, at this point you really need to confer with the stakeholder and the designer – what is it what we are going to show and how we are going to show it? Since I am both and developer at this point, I decided I want to show the route on the map as a line, the maneuvers (being the point where you actually need to do something) as symbols you can tap on, and having a window with the InstructionText to pop up as you do. Basically we’ll end up with a simple routing system in stead of a full fledged navigation app, but we have to start somewhere. And being the lazy *** I am, I am going to re-use the map binding behavior I wrote last year for Windows 8 and Windows Phone 8. But that’s later. First the view models.

Enter the viewmodels – again

The first, and most simple viewmodel is for handling the maneuver we are going to show in the popup

using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using GalaSoft.MvvmLight.Messaging;
using Microsoft.Phone.Maps.Controls;
using Wp7nl.Utilities;

namespace NavigationDemo.Logic.ViewModels
{
  public class ManeuverViewModel: ViewModelBase
  {
    private GeoCoordinateCollection location;
    public GeoCoordinateCollection Location
    {
      get { return location; }
      set
      {
        if (location != value)
        {
          location = value;
          RaisePropertyChanged(() => Location);
        }
      }
    }

    private string description;
    public string Description
    {
      get { return description; }
      set
      {
        if (description != value)
        {
          description = value;
          RaisePropertyChanged(() => Description);
        }
      }
    }

    [DoNotSerialize]
    public ICommand SelectCommand
    {
      get
      {
        return new RelayCommand(
            () => Messenger.Default.Send(this),
            () => true);
      }
    }
  }
}

The command firing of the object itself over the Messenger is a time-tested and tried method I use – if a user selects an object from a list, let a viewmodel that has the actual list of these objects as a property – I call that the ‘parent’ - handle the select. This prevents a whole lot who messing around with data contexts. Be nice to your designer ;-). Also note the geometry in this class is a GeoCoordinateCollection – although the maneuver is a point, my MapShapeDrawBehavior needs a GeoCoordinateCollection, because it does not know in advance if it needs to draw a point or a shape.

The next one is a bit awkward and also direct result of the way my MapShapeDrawBehavior behavior works – it needs a list of objects with a property that’s a GeoCoordinateCollection – this being the geometry. But the RouteLeg gives me a ReadOnlyCollection<GeoCoordinate> and we have only one object – one route. So I write a simple wrapper viewmodel to make sure that it has:

using System.Collections.Generic;
using System.Device.Location;
using GalaSoft.MvvmLight;
using Microsoft.Phone.Maps.Controls;
using Wp7nl.Utilities;

namespace NavigationDemo.Logic.ViewModels
{
  public class RouteGeometryViewModel : ViewModelBase
  {
    public RouteGeometryViewModel()
    {
    }

    public RouteGeometryViewModel(IEnumerable<GeoCoordinate> coordinates)
    {
      Geometry = new GeoCoordinateCollection();
      Geometry.AddRange(coordinates);
    }

    private GeoCoordinateCollection geometry;
    public GeoCoordinateCollection Geometry
    {
      get { return geometry; }
      set
      {
        if (geometry != value)
        {
          geometry = value;
          RaisePropertyChanged(() => Geometry);
        }
      }
    }
  }
}

… and make sure the viewmodel holding this object has a list of these.

And finally, the RoutingViewModel itself, that starts like this:

using System.Collections.ObjectModel;
using System.Device.Location;
using System.Linq;
using System.Threading.Tasks;
using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using GalaSoft.MvvmLight.Messaging;
using Microsoft.Phone.Maps.Controls;
using NavigationDemo.Logic.Models;
using Wp7nl.Utilities;

namespace NavigationDemo.Logic.ViewModels
{
  public class RoutingViewmodel : ViewModelBase
  {
    public RoutingViewmodel()
    {
      Maneuvers = new ObservableCollection<ManeuverViewModel>();
      RouteCoordinates = new ObservableCollection<RouteGeometryViewModel>();

      Messenger.Default.Register<ManeuverViewModel>(this, 
                                                    p => SelectedManeuver = p);
    }

    public RoutingViewmodel(NavigationModel model)
      : this()
    {
      Model = model;
    }

    private ManeuverViewModel selectedManeuver;
    public ManeuverViewModel SelectedManeuver
    {
      get { return selectedManeuver; }
      set
      {
        selectedManeuver = value;
        RaisePropertyChanged(() => SelectedManeuver);
      }
    }

    public ObservableCollection<RouteGeometryViewModel> RouteCoordinates 
                                                        { get; set; }

    public ObservableCollection<ManeuverViewModel> Maneuvers { get; set; }
  }
}

In the default constructor sits the standard initialization of the ObservableCollection types, as well as the setup for ManeuverViewModel select interception. Further below another constructor to make initialization from code easier, and the SelectedManeuver property. Nothing special here yet. We add two viewmodels for both to and from searching:

private GeocodeViewModel toViewModel;
public GeocodeViewModel ToViewModel
{
  get { return toViewModel; }
  set
  {
    if (toViewModel != value)
    {
      toViewModel = value;
      RaisePropertyChanged(() => ToViewModel);
    }
  }
}

private GeocodeViewModel fromViewModel;
public GeocodeViewModel FromViewModel
{
  get { return fromViewModel; }
  set
  {
    if (fromViewModel != value)
    {
      fromViewModel = value;
      RaisePropertyChanged(() => FromViewModel);
    }
  }
}

And then the public model property as well, with some clever skullduggery here:

private NavigationModel model;
public NavigationModel Model
{
  get { return model; }
  set
  {
    model = value;
    if (model != null)
    {
      ToViewModel = new GeocodeViewModel(model.To) { Name = "To" };
      FromViewModel = new GeocodeViewModel(model.From) { Name = "From" };
    }
  }
}

The “Name” property has no function whatsoever in the code, but I assure you – if you have two identical viewmodels in your app, having them easily distinguishable by a simple property that you can see in a breakpoint helps a ton!

Finally, the piece that does the actual routing:

public async Task DoRouting()
{
  await DoRouting(
   FromViewModel.SelectedLocation.Location,
   ToViewModel.SelectedLocation.Location);
}

public async Task DoRouting(GeoCoordinate from, GeoCoordinate to)
{
  RouteCoordinates.Clear();
  Maneuvers.Clear();
  await Model.DoRouting(from, to);
  RouteCoordinates.Add(new RouteGeometryViewModel(Model.FoundRoute.Geometry));
  ViewArea = Model.FoundRoute.BoundingBox;
  Model.FoundRoute.Legs.ForEach(r =>
  Maneuvers.AddRange(
    r.Maneuvers.Select(
      p => new ManeuverViewModel { 
            Description = p.InstructionText, 
            Location = 
               new GeoCoordinateCollection { p.StartGeoCoordinate }})));
}

[DoNotSerialize]
public ICommand DoRoutingCommand
{
  get
  {
    return new RelayCommand(
        async () =>
        {
          await DoRouting();
        });
  }
}

Once again I have a public overload with just coordinates to make testing easier. The line with all the Lambdas basically iterates over all legs of the route, gets all maneuvers per leg, and creates ManeuverViewModel types of every maneuver, using the StartGeoCoordinate of said maneuver to create location. Also note I put the route’s bounding box into a ViewArea property of the RoutingViewModel (code omitted) to enable the designer to let the map zoom to the extent of the new-found route. In the RoutingViewModel are two more properties I omitted – ZoomLevel and MapCenter, they are with ViewArea taken from the map binding sample I wrote last year.

Well… that’s quite some code. And now the proof of the pudding…

Testing the RoutingViewModel

I added a class RoutingViewModelTest and a simple test method to see if coordinates and maneuvers are duly filled when I call the DoRouting method with coordinates

using System;
using System.Device.Location;
using System.Linq;
using System.Threading;
using System.Windows;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
using NavigationDemo.Logic.Models;
using NavigationDemo.Logic.ViewModels;
using Wp7nl.Utilities;


namespace NavigationDemo.Logic.Test
{
  [TestClass]
  public class RoutingViewModelTest
  {
    [TestMethod]
    public void TestSimpleRoutingViewModel()
    {
      var vm = new RoutingViewmodel(new NavigationModel());

      var waitHandle = new AutoResetEvent(false);

      Deployment.Current.Dispatcher.BeginInvoke(async () =>
      {
        await vm.DoRouting(
            new GeoCoordinate(52.182679977268, 5.39752000942826),
            new GeoCoordinate(52.1061999723315, 5.03457002341747));
        waitHandle.Set();
      });

      waitHandle.WaitOne(TimeSpan.FromSeconds(25));

      Assert.IsTrue(vm.RouteCoordinates.Any());
      Assert.IsTrue(vm.Maneuvers.Any());
    }
  }
}

Which, not entirely surprising, is the case. Now if you follow the TDD pattern correctly, you should add all kinds of mocks and interfaces between these classes and also test every method separately. I decided to go more for the integration test like route – so I made a big test which basically emulates a complete routing request, tombstones it and checks the result.

[TestMethod]
public void TestSearchRoutingViewModelAndTombstoning()
{
  var waitHandle = new AutoResetEvent(false);

  var vm = new RoutingViewmodel(new NavigationModel());
  vm.FromViewModel.SearchText = "Springerstraat Amersfoort Netherlands";
  vm.ToViewModel.SearchText = "Heinrich Bertestraat Utrecht";
  Deployment.Current.Dispatcher.BeginInvoke(async () =>
  {
    await vm.FromViewModel.SearchLocations();
    await vm.ToViewModel.SearchLocations();
    waitHandle.Set();
  });
  waitHandle.WaitOne(TimeSpan.FromSeconds(5));

  Assert.IsTrue(vm.FromViewModel.MapLocations.Any());
  Assert.IsTrue(vm.ToViewModel.MapLocations.Any());

  vm.FromViewModel.SelectedLocation = vm.FromViewModel.MapLocations[0];
  vm.ToViewModel.SelectedLocation = vm.ToViewModel.MapLocations[0];
  Deployment.Current.Dispatcher.BeginInvoke(async () =>
  {
    await vm.DoRouting();
    waitHandle.Set();
  });

  waitHandle.WaitOne(TimeSpan.FromSeconds(5));

  var h = new IsolatedStorageHelper();
  if (h.ExistsInStorage())
  {
    h.DeletedFromStorage();
  }
  h.SaveToStorage(vm);

  var retrievedVm = h.RetrieveFromStorage();

  Assert.IsTrue(vm.RouteCoordinates.Any());
  Assert.IsTrue(vm.Maneuvers.Any());
  Assert.IsTrue(retrievedVm.RouteCoordinates.Count == vm.RouteCoordinates.Count);
  Assert.IsTrue(retrievedVm.FromViewModel.SearchText == 
    "Springerstraat Amersfoort Netherlands");
  Assert.IsTrue(retrievedVm.Maneuvers.Count == vm.Maneuvers.Count);
}

So, I first setup a complete new RoutingViewModel with NavigationModel, simulate the user input two streets and let them search locations. Then I test if there are any locations found at all. I can safely assume they are, since the previous tests worked as well, but still. Then I actually let the app perform routing, ‘tombstone’ the whole viewmodel and retrieve it again.

And then I do a number of tests to check if anything is found at all, and if whatever comes back from storage matches what went into it. It will not surprise you – it does. This test is far from comprehensive – you could test all the properties one by one, but at least you now can have a reasonable confidence in the basic workings of your app. What’s more – if you start changing things and test start failing, you know your app will probably fail too somewhere down the line.

Conclusion (so far)

By using unit/integration testing we have been able to make and test a working model of the app, finding out how stuff work and tackling serialization problems head on before we actually made a user interface at all – therefore eliminating potential double work by both you and your designer. Next time we will actually start assembling the app, and we will learn that no amount of unit testing will eliminate you from the fact that you still need to test your app manually ;-)

Once again, before I get flamed: technically I showed you how to do integration tests, not unit tests, because I tested multiple classes interacting with each other, in stead of single methods and/or properties

As always, a finished solution (if you can call this finished) is available for download here.

Windows Phone 8 navigation part 1–geocoding, tombstoning–and testing

noreply@blogger.com (Joost van Schaik) — Fri, 19 Apr 2013 03:45:00 PDT

After my post about reverse geocoding I set out to make a little app to demonstrate routing in Windows Phone 8. The demo app went quite out of hand, so I decided to split the post up in a few smaller posts. In the course of it I am going to build a basic navigation app that enables the user to determine two locations, find a route between those locations, and display them on a map – all using MVVMLight, of course.

And now the 2012.2 update to Visual Studio is released, we can finally build Windows Phone MVVM apps the way things are intended to be: by writing some unit test first, getting the basic functions right, before creating an all-out app. This makes it especially handy to test one important requirement that go for all my apps – all the models and viewmodels must be serializabe, so I can tombstone using SilverlightSerializer like I have been doing for over two years now.

At this point I am not really sure how much blog posts this will take me, but I guess at least three, maybe four.

What is unit testing and why should I do that?

Professional software developers are usually all in on this. What you basically do is write code that asserts that pieces of your code are behaving the way you expect them to do. I am sure everyone has had the episode that you change one little thing that should be inconsequential and suddenly, at some seemingly totally unrelated place, things start going South. Unit tests call little pieces of of your code and test if the result of calling a method, setting a property or whatever gives the result you expect. If you write unit tests, and then change something, and test start failing in unrelated places – it’s like a smoke detector going off. Your code starts detecting bugs for you. Nice, eh? I also gives you the a way to mess around with all kinds of APIs getting things right before you start wasting time on a complex GUI that you can’t get to work because the underlying code cannot work the way you want.

What is geocoding?

Geocoding is what we GIS buffs say when we mean ‘finding a location on earth by it’s name”. If I put “Boston USA” in a geocoder I expect to get a coordinate that puts me somewhere on the east coast of the United States, if I enter “Springerstraat 36 Netherlands” I expect a coordinate that shows me my own house, or somewhere nearby. Some geocoders can take info that’s not tied to an address, but things like, like ‘town hall Little Rock USA”. In general – in goes a descriptive text, out come one or more matches with coordinates.

Enough introduction. Let’s code.

Setting the stage

I started out doing the following:

Create a new Windows Phone App “NavigationDemo”. Target framework 8.0
Add a Windows Phone Class Library “NavigationDemo.Logic”
Add a Windows Phone Unit Test app “NavigationDemo.Logic.Test”
In NavigationDemo, create a reference to NavigationDemo.Logic
In NavigationDemo.Logic.Test, make a reference to NavigationDemo.Logic as well.
In both NavigationDemo and NavigationDemo.Logic.Test, select WMAppManifest.xml in Properties and enable the “ID_CAP_MAP” capbility

Now, because I am a lazy ******* and like to re-use I did things before, bring in the following nuget packages:

wp7nl (this will pull in MVVMLight Libraries-only version and the Windows Phone toolkit as well)
Microsoft.Bcl.Async

wp7nl also has a Windows Phone 8 version (it’s name is retained for historic reasons). Install both packages in all three projects.

GeocodeModel – take one

In “NavigationDemo.Logic”, add a folder “GeocodeModel” and put the following class in there:

using System;
using System.Collections.Generic;
using System.Device.Location;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.Phone.Maps.Services;
using Wp7nl.Utilities;

namespace NavigationDemo.Logic.Models
{
  public class GeocodeModel
  {
    public GeocodeModel()
    {
      MapLocations = new List<MapLocation>();
      SearchLocation = new GeoCoordinate();
    }
    public string SearchText { get; set; }

    public GeoCoordinate SearchLocation { get; set; }

    public MapLocation SelectedLocation { get; set; }

    public List<MapLocation> MapLocations { get; set; }

    public async Task SearchLocations()
    {
      MapLocations.Clear();
      SelectedLocation = null;
      var geoCoder = new GeocodeQuery
      {
        SearchTerm = SearchText,
        GeoCoordinate = SearchLocation
      };
      MapLocations.AddRange(await geoCoder.GetMapLocationsAsync());
      SelectedLocation = MapLocations.FirstOrDefault();
    }
  }
}

To perform geocoding, we need the GeocodeQuery class. So we embed that into a class with a method to perform the actual geocoding, a search string to holds the user input, a list of MapLocation (the output of GeocodeQuery) and SelectedLocation to the user’s selection.

Note there is also a SearchLocation property of type GeoCoordinate. That’s because the GeocodeQuery also needs a location to start searching from. If the programmer using my model doesn’t set it, I choose a default value. But you can imagine this being useful if someone just enters ‘Amersfoort’ for SearchText and a coordinate somewhere in the Netherlands – that way the GeocodeQuery knows that you want to have Amersfoort in the Netherlands, and not the Amersfoort in South Africa. Anyway, it’s now time for

Writing the search test

Add a new class GeocodeModelTest to NavigationDemo.Logic.Test and let’s write our first test:

using System;
using System.Threading;
using System.Windows;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
using NavigationDemo.Logic.Models;

namespace NavigationDemo.Logic.Test
{
  [TestClass]
  public class GeocodeModelTest
  {
    [TestMethod]
    public void TestFindBoston()
    {
      var m = new GeocodeModel { SearchText = "Boston USA" };
      var waitHandle = new AutoResetEvent(false);

      Deployment.Current.Dispatcher.BeginInvoke(async () =>
      {
        await m.SearchLocations();
        waitHandle.Set();
       });
      waitHandle.WaitOne(TimeSpan.FromSeconds(5));

      Assert.AreEqual(m.SelectedLocation.GeoCoordinate.Latitude, 42, 1);
      Assert.AreEqual(m.SelectedLocation.GeoCoordinate.Longitude, -71, 1);
      Assert.AreEqual(m.SelectedLocation.Information.Address.City, 
         "Boston");
      Assert.AreEqual(m.SelectedLocation.Information.Address.State,
        "Massachusetts");
      Assert.AreEqual(m.SelectedLocation.Information.Address.Country, 
        "United States of America");
    }
  }
}

The GeocodeQuery runs async and needs to run on the UI thread as well. If you have no idea what I am fooling around here with the Dispatcher and the AutoResetEvent, please read this article first. Anyway, this test works. Boston is indeed on the east coast of the United States and still in Massachusetts. Most reassuring. Now let’s see if SilverlightSerializer will indeed serialize this.

Writing the serialization test – take one

The first part is basically a repeat of the first test – writing unit test sometimes involves a lot of boring copy & paste work – but the last part is different:

 [TestMethod]
 public void TestStoreAndRetrieveBoston()
 {
   var m = new GeocodeModel { SearchText = "Boston USA" };
   var waitHandle = new AutoResetEvent(false);

   Deployment.Current.Dispatcher.BeginInvoke(async () =>
   {
     await m.SearchLocations();
     waitHandle.Set();
   });
   waitHandle.WaitOne(TimeSpan.FromSeconds(5));
   Assert.IsNotNull(m.SelectedLocation);

   // Actual test
   var h = new IsolatedStorageHelper<GeocodeModel>();
   if (h.ExistsInStorage())
   {
     h.DeletedFromStorage();
   }
   h.SaveToStorage(m);

   var retrievedModel = h.RetrieveFromStorage();
   Assert.AreEqual(retrievedModel.SelectedLocation.Information.Address.City,
	"Boston");
 }
}

Adding this test to GeocodeModelTest will reveal a major bummer – a couple of the classes that are returned by GeocodeQuery – starting with MapLocation - have private constructors and cannot be serialized. Our model cannot be serialized. The usual approach to this kind of problem is to write a kind of wrapper class that can be serialized. But… using MVVMLight you are most of the time making wrapper classes anyway – that’s what a ViewModel is, after all, so let’s use that.

Writing the serialization test - take two

First, adorn the stuff that cannot be serialized in the GeocodeModel with the [DoNotSerialize] attribute, like this:

[DoNotSerialize]
public MapLocation SelectedLocation { get; set; }

[DoNotSerialize]
public List MapLocations { get; set; }

and the test is reduced to this:

[TestMethod]
public void TestStoreAndRetrieveBoston()
{
  var m = new GeocodeModel { SearchText = "Boston USA" };
  // Actual test
  var h = new IsolatedStorageHelper();
  if (h.ExistsInStorage())
  {
    h.DeletedFromStorage();
  }
  h.SaveToStorage(m);

  var retrievedModel = h.RetrieveFromStorage();
  Assert.AreEqual(retrievedModel.SearchText, "Boston USA");
}

Hurray, this works, but the model’s results are now no longer storing stuff. MapLocations is empty, so is SelectedLocation, if they are deserialized. Bascially we are now only testing if indeed the search test is retained after storage and retrieval. Well, it is.

Enter the viewmodels

So far I mainly showed what does not work. Now it’s time to show what does. First, we make a viewmodel around MapLocation:

using System.Device.Location;
using GalaSoft.MvvmLight;
using Microsoft.Phone.Maps.Services;

namespace NavigationDemo.Logic.ViewModels
{
  public class MapLocationViewModel : ViewModelBase
  {
    public MapLocationViewModel()
    {
    }

    public MapLocationViewModel(MapLocation model)
    {
      var a = model.Information.Address;

      Address = string.Format("{0} {1} {2} {3} {4}", 
            a.Street, a.HouseNumber, a.PostalCode,
            a.City,a.Country).Trim();
      Location = model.GeoCoordinate;
    }

    private string address;
    public string Address
    {
      get { return address; }
      set
      {
        if (address != value)
        {
          address = value;
          RaisePropertyChanged(() => Address);
        }
      }
    }

    private GeoCoordinate location;
    public GeoCoordinate Location
    {
      get { return location; }
      set
      {
        if (location != value)
        {
          location = value;
          RaisePropertyChanged(() => Location);
        }
      }
    }
  }
}

That takes care of the MapLocation not being serializable. Once it is initialized, it does no longer need the model anymore. Which is a good thing, since it cannot be serialized ;-). Next is the GeocodeViewModel itself:

using System.Collections.ObjectModel;
using System.Threading.Tasks;
using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using NavigationDemo.Logic.Models;
using Wp7nl.Utilities;
using System.Linq;

namespace NavigationDemo.Logic.ViewModels
{
  public class GeocodeViewModel : ViewModelBase
  {
    public GeocodeViewModel()
    {
      MapLocations = new ObservableCollection<MapLocationViewModel>();
    }

    public string Name { get; set; }

    public GeocodeViewModel( GeocodeModel model) : this()
    {
      Model = model;
    }

    public GeocodeModel Model{get;set;}

    public ObservableCollection<MapLocationViewModel> MapLocations { get; set; }

    [DoNotSerialize]
    public string SearchText
    {
      get { return Model.SearchText; }
      set
      {
        if (Model.SearchText != value)
        {
          Model.SearchText = value;
          RaisePropertyChanged(() => SearchText);
        }
      }
    }

    private MapLocationViewModel selectedLocation;
    public MapLocationViewModel SelectedLocation
    {
      get { return selectedLocation; }
      set
      {
        if (selectedLocation != value)
        {
          selectedLocation = value;
          RaisePropertyChanged(() => SelectedLocation);
        }
      }
    }
    
    public async Task SearchLocations()
    {
      MapLocations.Clear();
      SelectedLocation = null;
      await Model.SearchLocations();
      MapLocations.AddRange(Model.MapLocations.Select( 
        p=> new MapLocationViewModel(p)));
      SelectedLocation = MapLocations.FirstOrDefault();
    }
    
    [DoNotSerialize]
    public ICommand SearchLocationCommand
    {
      get
      {
        return new RelayCommand(async () => await SearchLocation());
      }
    }
  }
}

Notice that the only attribute that is serialized by the model, is now marked [DoNotSerialize]. This is really important – since the model may not be around yet when deserializing takes place, it would result in a null reference. If you pass things to the model, let the model serialize it. If you don’t let the viewmodel take care of it.

Writing the search test for the viewmodel

So since we are now no longer testing the model but the viewmodel, I added a new class “GeocodeViewModeTest” to, well, test the viewmodel.

using System;
using System.Threading;
using System.Windows;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
using NavigationDemo.Logic.Models;
using NavigationDemo.Logic.ViewModels;
using Wp7nl.Utilities;

namespace NavigationDemo.Logic.Test
{
  [TestClass]
  public class GeocodeViewModelTest
  {
    [TestMethod]
    public void TestFindBostonWithViewModel()
    {
      var vm = new GeocodeViewModel(
        new GeocodeModel { SearchText = "Boston USA" });
      var waitHandle = new AutoResetEvent(false);

      Deployment.Current.Dispatcher.BeginInvoke(async () =>
        {
          await vm.SearchLocations();
          waitHandle.Set();
      });
      waitHandle.WaitOne(TimeSpan.FromSeconds(5));
      Assert.AreEqual(vm.SelectedLocation.Address, 
         "Boston United States of America");
      Assert.AreEqual(vm.SelectedLocation.Location.Latitude, 42, 1);
      Assert.AreEqual(vm.SelectedLocation.Location.Longitude, -71, 1);
    }
  }
}

Lo and behold, this test succeeds as well. Now the second test is actually a lot more interesting:

[TestMethod]
public void TestStoreAndRetrieveBostonWithViewModel()
{
  var vm = new GeocodeViewModel(
    new GeocodeModel { SearchText = "Boston USA" });
  var waitHandle = new AutoResetEvent(false);

  Deployment.Current.Dispatcher.BeginInvoke(async () =>
  {
    await vm.SearchLocations();
    waitHandle.Set();
  });
  waitHandle.WaitOne(TimeSpan.FromSeconds(5));
  Assert.IsNotNull(vm.SelectedLocation);

  var h = new IsolatedStorageHelper<GeocodeViewModel>();
  if (h.ExistsInStorage())
  {
    h.DeletedFromStorage();
  }
  h.SaveToStorage(vm);

  var retrievedViewModel = h.RetrieveFromStorage();
  Assert.AreEqual(retrievedViewModel.SelectedLocation.Address,
    "Boston United States of America");
  Assert.AreEqual(
    retrievedViewModel.SelectedLocation.Location.Latitude, 42, 1);
  Assert.AreEqual(
    retrievedViewModel.SelectedLocation.Location.Longitude, -71, 1);
}

And indeed, after retrieving the viewmodel from storage, the same asserts are fired and the test passes. Success: we can now find location and tombstone

Conclusion

I showed you some basic geocoding – how to find a location using a text input. I hope I have showed you also that unit tests are not only a way to assure some basic code quality and behavior, but are also a way to determine ahead if things are going to work the way you envisioned. Unit test make scaffolding and proof-of-concept approach of development a lot easier – you need a lot less starting up an app, clicking the right things and then finding breakpoint-by-breakpoint what goes wrong. Quite early in my development stage I ran into the fact that some things were not serializable. Imagine finding that out when the whole app was already mostly done, and then somewhere deep down something goes wrong with the tombstoning. Not fun.

Complete code – that is, complete for such an incomplete app – can be found here. Next time, we will do some actual navigation.

To prevent flames from Test Driven Design (TDD) purists: a variant of unit tests are integration test. Technically a unit test tests only tiny things that have no relation to another, like one object, method or property. Integration tests test the workings of larger pieces of code. So technically I am mostly writing integration tests. There, I’ve said it.

ViewModel driven multi-state animations using DataTriggers and Blend on Windows Phone

noreply@blogger.com (Joost van Schaik) — Tue, 09 Apr 2013 23:32:00 PDT

Long long time ago I wrote how to drive animations from your ViewModel using DataStateBehavior, and I explicitly stated this was the only way to do it, since (quoting myself), “Windows Phone 7 does not support DataTriggers”. That was then, and this is now. The drawback of DataStateBehavior is that you basically can only do on/off animations, which makes more complex multi-state animations impossible. There was another behavior that could do that, but I could not find that anymore and I could not quite remember the name. And then I suddenly stumbled upon the Microsoft.Expression.Interactions assembly – and in its Microsoft.Expression.Interactions.Core namespace there is indeed a DataTrigger. And that seems to have been present in the 7.1 framework as well. *Cough*.

So in this blog post I am going to demonstrate how to animate a few ‘popup windows’ via a single Visual State block and a ViewModel, using DataTriggers. I am going to show this using Visual Studio 2012, MVVMLight and mostly Blend. It’s time to give this unsung hero some love again, so I am going to follow the tutorial-style again.

Setting the stage

Open Visual Studio, create a “Windows Phone app”, and target 8.0 (it should work in 7.1 as well BTW)
Click Tools/Library Package Manager/Manage NuGet Packages for Solution.
Search for MvvmLightLibs, select “MVVM Light Libraries only”
Click “Install”, “Ok” and “I Accept”

Building the ViewModel

The ViewModel actually consist out of two files – an enumeration describing the states and the actual ViewModel itself. First, create a folder “ViewModel” in your solution, and the create the enumeration like this:

namespace DataTriggerAnimation.ViewModel
{
  public enum DisplayState
  {
    Normal = 0,
    ShowPopupHello = 1,
    ShowPopupBye = 2,
  }
}

And then the ViewModel like this:

using System;
using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;

namespace DataTriggerAnimation.ViewModel
{
  public class DisplayViewModel : ViewModelBase
  {
    private DisplayState displayState;
    public DisplayState DisplayState
    {
      get { return displayState; }
      set
      {
        if (displayState != value)
        {
          displayState = value;
          RaisePropertyChanged(() => DisplayState);
        }
      }
    }

    public ICommand DisplayPopupCommand
    {
      get
      {
        return new RelayCommand<string>(
            (p) =>
              {
                DisplayState = (DisplayState)Enum.Parse(typeof(DisplayState), p);
              });
      }
    }

    public ICommand CloseCommand
    {
      get
      {
        return new RelayCommand(() 
           => DisplayState = DisplayState.Normal);
      }
    }
  }
}

The important thing to note is that the command “DisplayPopupCommand” requires a parameter to determine the popup that must be displayed. The CloseCommand is equivalent to a DisplayPopupCommand with parameter “Normal”, and is just there for making the designer’s life easier.

… and that’s all the coding we are going to do. Build your application and close Visual Studio. The rest, just like my last animation post is done in Blend! All of it.

Creating the first panel

Drag a grid on the empty rectangle “ContentPanel”. Like all GUI objects, these can be found on the Assets tab on the left top.
Click on the “Grid” in the “Objects on Timeline” pane left, and rename it to “Panel1”
Right-click on the “Panel1” grid, hit ‘Reset Layout/All”
Go to the right-hand pane, select “Properties” and expand the “Layout” pane if it’s collapsed.
Then click “Top” for Vertical Alignment.
Then enter “150” for height

Then proceed to add a text:

Drag a TextBlock on the “Panel1” grid. You can do this by either dragging it on the design surface on top of “Panel1”, or on the “Objects and Timeline” pane (also on top of “Panel1”)
Change the text from “TextBlock” to “Hello this is popup one”
Do Reset Layout/All on this text as well
In the Layout Pane, select Horizontal Alignment “Center” and Vertical Alignment “Top”

And finally add a button:

Drag a button on Panel1
Do Reset Layout/All on this button as well
Change the caption to “Done”
In the Layout Pane, select Horizontal Alignment “Center” and Vertical Alignment “Bottom”

And then finally do something that seems like pretty bonkers, but trust me: it will all become clear in the end:

Select Panel1 in the Objects and Timeline panel.
Go to the Properties pane on the right hand side, and find the “Transform” pane. It’s usually collapsed. Expand it first.
Select Center Point tab - the 2nd tab from the right under “Rendertransform” (with the dot on in)
For both X and Y type “0.5”. This sets the transformation point dead in the middle of the panel
Then also select the Global offset tab – that’s the 2nd tab from the right under “Projection” (with the up and left pointing arrow on it)
Enter “500” for X.

Your design surface now should look like showed on the right. The panel is sitting well right of the phone. Bonkers, I said it. ;-).

Creating the second panel

Going to be a bit lazy here. I don’t want to to the whole sequence again

Select Panel 1 in “Objects and Timeline”
Hit CTRL-C, CTRL-V. This will result in a Panel1_Copy below Panel 1
Rename that to “Panel2”
Go to the Properties tab again on the right, and enter “160” for top margin. This should result in Panel2 appearing under Panel1
Then, for an encore, go to the Transform panel again and change “500” for X Projection to -500

The second panel should jump to the left and resulting design surface should now look like this:

Creating the popup buttons

At this time I am going to assume you now understand the layout panel, so I am not going to make screenshots of every button you need to click and number you need to enter in the layout panels ;-)

Drag a StackPanel on the design surface, near the bottom of the screen.
Do Reset Layout/All,
Select Vertical Alignment Bottom, and enter a height of 220.
Proceed to drag three buttons on top of the StackPanel. These should appear under each other, taking the full width of the screen.
Change the captions of the buttons to (from top to bottom) “Popup 1”, “Popup 2” and “Done”.

The final design surface, including the objects tree, should look like this:

Defining the Visual States

We have three visual states:

None of the popups are displayed
Popup 1 is displayed
Popup 2 is displayed

To create these, proceed as follows:

At the top left, click the “States” Tab.
Click the “Add state Group” Button
Rename “VisualStateGroup” to "PopupGroup”
Enter “0.5” for “Default Transition”. This indicates any state transitions will be automatically animated over a 0.5 second time period.

Next steps:

Click the “Add state” Button
Rename the state “VisualState” to “Normal”
Add two more states, “ShowPopupHello” and “ShowPopupBye”
Click the red dot before “ShowPopupBye”. The red color disappears. The main design surface should now have a caption “ShowPopupBye state recording is off”

Now the next things are tricky, so pay close attention and make sure you do this exactly right.

Select “Panel1” in “Objects and Timeline”
Click state “ShowPopupHello”. The main design surface should now have a caption “ShowHelloPopupstate recording is on” and have a red border.
Go to the Transform panel again, select under projection the Global offset (2nd tab from the right) again and change 500 back to 0. Panel 1 should now appear in the phone screen
Now select state “ShowPopupBye”. Panel 1 disappears again
Select Panel2
Change its global offset to 0 as well. Now panel 2 appears in the phone screen
Select State “Normal”
Select the red dot before “Normal” to turn state recording off. Both panels now should be outside of the phone screen again.
Select “Base” on top of the State panel.

Bringing in the ViewModel

Before we are going to connect the Visual States to the ViewModel’s actions, let’s first bring it in. That’s pretty easy.

Go top right and select the data tab.
Select the “Create data source” button all to the right and select “Create object data source”
On about the 8th line you should see “DisplayViewModel”. Select that
Enter “DisplayViewModelDataSource” in the “Data source name” box
Hit OK.
Net result should be as displayed to the right.

Setting up initial data binding

This is so ridiculously easy in Blend it always makes me happy when I get to this state.

Drag “DisplayViewModel” from the data tab on top of the LayoutRoot panel in the Objects and Timeline panel
Drag “CloseCommand” on top of all three “Done” buttons. You can do that either on the design surface or on the Objects and Timeline panel, whatever you like.
Proceed to drag “PopupCommand” on top of both the “Popup 1” and “Popup 2” button.
Now select the “Popup 1” button, and select the “Properties” tab again.
On top there’s a “Search properties” box. The developers of Blend soon recognized the number of things you can set it so big you can easily loose track. Enter “Command” in that search box to limit the number of properties it shows.
The Properties box now should only show “Command” and “CommandParameter”. Enter value “ShowPopupHello” for “CommandParameter”
Now select the “Popup 2” button, and enter “ShowPopupBye” for “CommandParameter”
Clear the text “Command” from “Search Properties” so you can see all the properties again.

Programming by dragging stuff on top of each other. Ain’t life fun sometimes?

Enter the dragon: datatriggers for putting it all together

And now for the really scary part – the datatriggers. Just kidding of course – just more dragging stuff and filling in some fields. The odd thing is – from the Blend perspective, data triggers are hardly visible. We are using GotoStateActions. Finish the app by following these final steps:

Drag a GotoStateAction from Assets box on top of ContentPanel. If you can’t find it: type “goto” in the search box of the Asset panel. It will popup in the list to the right of the panel
Under Properties, Click on the “New” button next to “TriggerType” and select “DataTrigger” in the box that pops up.
Behind “Binding”, click the barrel like icon. A dialog pops up with the properties of your DisplayViewModel. Select “DisplayState” and hit OK
Enter “0” for value
For StateName, select “Normal”
Drag another GotoStateAction from Assets box on top of ContentPanel. Make this a DataTrigger to, select the same property to bind to, but
- Enter “1” for “Value”
- Select “ShowPopupHello” for StateName
And finally, a third GotoStateAction with 2 as value and “ShowPopupBye” for StateName.

And that’s all. If you run your application (you should be able to hit F5 from Blend) you will get a simple app that scrolls Popup 1 from the left in half a second when you hit “Popup 1”, and scroll it back when you hit on of the done buttons. If you hit the “Popup 2” button when Popup 1 is visible, it will scroll the second popup into the screen while simultaneously scrolling the first on out of the screen.

The data triggers look like this in XAML:

<i:Interaction.Triggers>
  <ec:DataTrigger Binding="{Binding DisplayState}" Value="0">
    <ec:GoToStateAction StateName="Normal"/>
  </ec:DataTrigger>
  <ec:DataTrigger Binding="{Binding DisplayState}" Value="1">
    <ec:GoToStateAction StateName="ShowPopupHello"/>
  </ec:DataTrigger>
  <ec:DataTrigger Binding="{Binding DisplayState}" Value="2">
    <ec:GoToStateAction StateName="ShowPopupBye"/>
  </ec:DataTrigger>
</i:Interaction.Triggers>

Some things to note

We hardly did program anything at all, and what’s more – we did not even make animations or storyboards. By simply setting the default transition to 0.5 seconds and indicating where we want stuff to be once a state is reached, the Windows Phone framework automatically infers and creates an animation when changing state, moving the GUI elements from one place to another in half a second (in stead of flashing them from one place to another).
In the Command I was able to use names as defined in the enumeration because I did an Enum.Parse in the ViewModel, in the data triggers I had to use the real value (0,1,2) to be able to compare. Something that can be fixed using a converter, but I did not want to complicate things.
The fact that the visual state names have the same name as the enumeration values, does not bear any significance. I could have named them Huey, Dewey, and Louie for all I cared. Only the CommandParameter values need to be the same as the Enumeration string, and the DataTriggers need to have the same numeric value.

That’s it. Although the Visual Studio 2012 designer is light years ahead of the 2010 designer, Blend still rocks when defining a lot of stuff in XAML. Have fun making beautifully animated apps with this.

If you don’t feel like following all these steps yourself, find, as usual, the completed solution here.

Enabling basic OpenLayers pinch zooming for Internet Explorer 10 touch events

noreply@blogger.com (Joost van Schaik) — Wed, 27 Mar 2013 10:43:00 PDT

A phenomenon described by the term ‘webkit monoculture’ is causing quite some concern in the web development community. A lot of web developers are basically coding for webkit and webkit only, or more specifically Safari on IOS. HTML5 and standards are great, but certain parts of the web development stack are moving back to a ‘works on my environment’ status that we just were getting rid of. This phenomenon rears it’s ugly head itself on all kind of places, including in the OpenLayers toolkit that I am using for my work at Vicrea.

For those not familiar with OpenLayers: think Google Maps, but then with real GIS functionality, without commercial licensing, without ads in the map, and without all kind of legal strings attached. Pure open source client side web GIS. With the advent of touch devices its community added some basic touch functionality to it, like pinch zoom. That works very smooth, provided – you guessed it – you work on a web kit based browser. Microsoft, in all its wisdom, has chose to implement touch events in a completely different way. As to why this is, and what exactly is standard or not – that is not exactly my concern here. I am making a web GIS that is not supported my Windows 8 touch devices and Windows Phone 8. That, of course, is unacceptable to me ;-)

So I created a little OpenLayers style control that adds pinch zoom to Internet Explorer 10. It’s pure JavaScript and a little primitive – it’s basically zooming in on the map center, and not on the point between your fingers, but it’s working pretty well IMHO.

It also works pretty simple: upon the activate command, it hooks itself onto two events of the map’s layerContainerDiv – MSPointerDown and MSGestureChanged. The first one is fired at the first touch point going down, the second one when MSGesture recognizes an MSGestureChanged. Important is also setting the map’s fractionalZoom property to true.

OpenLayersWindowsPinchZoom = OpenLayers.Class(OpenLayers.Control,
  {
    autoActivate: true,

    gesture: null,

    defaultHandlerOptions: {},

    initialize: function (options)
    {
      this.handlerOptions = OpenLayers.Util.extend({}, this.defaultHandlerOptions);
      OpenLayers.Control.prototype.initialize.apply(this, options);
    },

    activate: function ()
    {
      if (OpenLayers.Control.prototype.activate.apply(this, arguments))
      {
        if (window.navigator.msPointerEnabled)
        {
          this.map.fractionalZoom = true;

          this.gesture = new MSGesture();
          this.gesture.target = this.map.layerContainerDiv;
          var self = this;

          this.gesture.target.addEventListener("MSPointerDown", function (evt)
          {
            self.gesture.addPointer(evt.pointerId);
          });

          this.gesture.target.addEventListener("MSGestureChange", function (evt)
          {
            // Make scale result smaller to prevent high zoom speeds.
            if (evt.scale !== 1)
            {
              var scale = 1;
              if (evt.scale > 1)
              {
                scale = (evt.scale - 1) / 4 + 1;
              }
              else
              {
                scale = 1 - ((1 - evt.scale) / 4);
              }
              // map.zoomTo is buggy as hell so I use this convoluted way to 
              // calculate a new zoom area
              var resolution = self.map.getResolutionForZoom(self.map.zoom * scale);
              var bounds = self.map.calculateBounds(self.map.getCenter(), resolution);
              self.map.zoomToExtent(bounds);
            }
          });
        }
        return true;
      }
      else
      {
        return false;
      }
    },

    CLASS_NAME: "OpenLayersWindowsTouch"
  }
);

The MSGestureChanged event has a scale, which is a number either bigger (zoom in) or smaller (zoom out) than 1. After that it’s simply calling some standard map functions to calculate the new display area and fire away. The most logical one to use would be map.ZoomTo, but that completely messes up the map tile layout after a few times and this workaround via the resolution calculation prevents that. I assume there is a bug in the zoomTo code.

There is another detail – to prevent Internet Explorer to handle the zoom events itself, you have to mark the div in which the map will come with css style:

-ms-touch-action: none

I did that inline for the sake of simplicity ;-)

<div id="map2" class="smallmap" style="-ms-touch-action: none"></div>

As for creating the map with the control enabled: this is a normal map with just the standard controls:

map1 = new OpenLayers.Map('map1', 
	 {controls: [new OpenLayers.Control.Navigation(), 
                       new OpenLayers.Control.PanZoomBar()], 
	  numZoomLevels: 15});

while the second one sports my new control as well:

map2 = new OpenLayers.Map('map2', 
	 {controls: [new OpenLayers.Control.Navigation(), 
		  new OpenLayers.Control.PanZoomBar(),
		  new OpenLayersWindowsPinchZoom()], 
	  numZoomLevels: 15});

And that’s all there is to it. For the OpenLayers purists: yes, I am aware that I don’t implement destroy and potentially create memory leaks. I just wanted to kick off IE10 support. I hope the ‘real’ OpenLayers developers do better and now start supporting IE10 by themselves ;-)

I have made a little live demo site which looks like showed on the left. You can watch it live here and download a zip file containing all the necessary file in one go here.

The control has been tested successfully on a Nokia Lumia Windows Phone 8, a Microsoft RT and a Microsoft Surface Pro.

Unit testing async Windows Phone 8 code on the UI thread with VS 2012.2 CTP4

noreply@blogger.com (Joost van Schaik) — Thu, 21 Mar 2013 12:38:00 PDT

This may be the most cryptic acronym-laden title I ever used for a blog post, but it quite exactly describes what I was trying to do yesterday.

The Visual Studio 2012 CTP4 makes it possible to write real Windows Phone 8 unit tests that run in the Visual Studio Unit Test runner (in stead of only on the emulator). So when I wanted to investigate the Routing API that is new in Windows Phone 8, I decided not to write an application outright, but start out with unit test.

I set up a new solution with two projects, as I usually do: one with the actual app - and one class library with the view models, models and other logic in it that isnot directly related to the user interface. And then I added a Windows Phone 8 Unit Test App.

First things first: when I want to test routing, I first need to give the user an option to select a location to go to. I decided to use the Geocoding API. I decided the view model should contain the following:

A string property SearchText to be filled by the user
An ObservableCollection of MapLocation called MapLocations to be filled by the Geocoder, intended to be bound to a list control of some kind to enable the user to select on of the founds locations.
A MapLocation property SelectedLocation to hold the MapLocation selected by the user
A little method to actually perform the geocoding
A command wrapping this method.

My good and very smart friend - and fellow Phone development MVP - Matteo Pagani has already covered some ground in this direction by writing this article and inspired by it I decided to pull in the Microsoft.Bcl.Async library as well so I could use async/await, on the premises that you can never have too much beta software in your project ;-)

The method I wanted to test was pretty simple:

public async Task SearchLocation()
{
  MapLocations.Clear();
  SelectedLocation = null;
  var geoCoder = new GeocodeQuery { 
    SearchTerm = SearchText, 
    GeoCoordinate = new GeoCoordinate() };
  MapLocations.AddRange(await geoCoder.GetMapLocationsAsync());
}

And so was the test method – I let it search for the street I live in.

[TestMethod]
public async Task TestLocationWrong1()
{
  var testVm = new GeocodeViewModel
    {SearchText = "Springerstraat Amersfoort Netherlands"};
  await testVm.SearchLocation();
  Assert.IsTrue(testVm.MapLocations.Any());
}

I ran the test…. and was quite surprised by the result. “Invalid cross thread access"??? I don’t even have a UI. Very interesting. Apparently the GeocodeQuery needs to be run on the UI thread. As to why this is, I have no idea. Some people (hi Morten ;-) ) say that if you have to unit test on the UI thread, you are doing it wrong. That may be the case, but it seems I have little choice here and I still want to test my view model.

According to this page there is a UITestMethodAttribute for Windows Store applications to solve this kind of problems – but not for Windows Phone 8 (yet) so obviously I had to pull in the Dispatcher. Since calling stuff from the Dispatcher runs asynchronously as well take 2 didn’t work of course…

[TestMethod]
public void TestLocationWrong2()
{
  var testVm = new GeocodeViewModel 
  { SearchText = "Springerstraat Amersfoort Netherlands" };
  Deployment.Current.Dispatcher.BeginInvoke(async () => await testVm.SearchLocation());
  Assert.IsTrue(testVm.MapLocations.Any());
}

…for the simple reason that the although testVM.SearchLocation is now fired on the UI thread, the Assert is not, and it is executed directly after the BeginInvoke is called and MapLocations still is empty when the Assert is evaluated.

I don’t know if there’s a smarter way to do this, but I used an AutoResetEvent to solve it. I used that to block the test thread until the UI thread is done, like this:

[TestMethod]
public void TestLocationSearchHasResult()
{
  var waitHandle = new AutoResetEvent(false);
  var testVm = new GeocodeViewModel { SearchText = "Springerstraat Amersfoort Netherlands" };
  Deployment.Current.Dispatcher.BeginInvoke(async () =>
    {
      await testVm.SearchLocation();
      waitHandle.Set();
    });
  waitHandle.WaitOne(TimeSpan.FromSeconds(5));
  Assert.IsTrue(testVm.MapLocations.Any());
}

The test thread waits until waitHandle.Set() is called – or five seconds, whatever happens first – and then it performs the Assert. And that works.

As usual, you can download a demo solution here. It was actually meant to be a solution demoing the Route API, as stated earlier, but I thought this subject deserved a blog post on its own.

As stated, this project requires installation of the Visual Studio 2012 CTP4. This has a GoLive license, but it’s still preview software. Install it on your own risk.

Update: Pedro Lamas, a Windows Phone Development specialist working for Nokia, has posted about his port of UITestMethodAttribute to Windows Phone. That runs the whole test on the UI thread in stead of only the the mandatory part. This brute-force method may not be desirable for all cases, but it sure is pretty easy to use.

Simple reverse geocoding with Windows Phone 8 and MVVMLight

noreply@blogger.com (Joost van Schaik) — Wed, 13 Mar 2013 08:07:00 PDT

Having worked in Geographical Information Systems over 20 years, I can tell you rightfully the new Windows Phone 8 mapping and location abilities are more than enough to make a map maniac like me getting twinkly eyes. It has capabilities that are unheard of even just a couple of years ago – and I don’t need a big workstation, I don’t even need a PC - it’s running on my phone. The world in my pocket – in the most literal sense possible.

Two popular applications of GIS are geocoding and reverse geocoding. Geocoding enables you to find the position of earth for a descriptive text – say an address, city, building name, or any other phrase indicating a place on Earth. This is usually rather straightforward. Reverse geocoding is exactly the opposite – it’s the “what’s here?” question – given a location, what do I find here? Incidentally, answering questions like this is how I make a living at Vicrea.

Windows Phone 8 makes reverse geocoding almost embarrassingly easy. Even when using MVVMLight. So I made a simple app that show the address(es) found at the location where you tap on the map.

We start off with a simple model with two properties:

using System.Collections.ObjectModel;
using System.Device.Location;
using System.Linq;
using GalaSoft.MvvmLight;
using Microsoft.Phone.Maps.Services;

namespace TapReverseGeocode.Logic.ViewModels
{
  public class MapViewModel : ViewModelBase
  {
    public MapViewModel()
    {
      Addresses = new ObservableCollection<string>();
    }

    private GeoCoordinate tapCoordinate;
    public GeoCoordinate TapCoordinate
    {
      get { return tapCoordinate; }
      set
      {
        tapCoordinate = value;
        RaisePropertyChanged(() => TapCoordinate);
        StartReverseGeoCoding();
      }
    }

    public ObservableCollection<string> Addresses { get; set; }
  }
}

The ObservableCollection “Addresses” will hold the results, and as usual when binding to ObservableCollection you must make sure it is initialized before anything else – the constructor is a good place for that. The designer can bind this to some kind of GUI element that displays the result.

The TapCoordinate property is a GeoCoordinate and that fires off the actual reverse geocoding – and I have omitted the usual “if (viewModelPropertyName != value)” check on purpose. Even when the user taps the same location twice, I want to have the reverse geocoding code to fire every time.

The code that starts the reverse geocoding itself ain’t quite rocket science:

private void StartReverseGeoCoding()
{
  var reverseGeocode = new ReverseGeocodeQuery();
  reverseGeocode.GeoCoordinate = 
    new GeoCoordinate(TapCoordinate.Latitude, TapCoordinate.Longitude);
  reverseGeocode.QueryCompleted += ReverseGeocodeQueryCompleted;
  reverseGeocode.QueryAsync();
}

To prevent race conditions I make a new GeoCoordinate from the one provided by the user, set up a call back, and fire off the async query.

The final piece is this simple callback that processes the result of the reverse geocoding.

private void ReverseGeocodeQueryCompleted(object sender, 
  QueryCompletedEventArgs<System.Collections.Generic.IList<MapLocation>> e)
{
  var reverseGeocode = sender as ReverseGeocodeQuery;
  if (reverseGeocode != null)
  {
    reverseGeocode.QueryCompleted -= ReverseGeocodeQueryCompleted;
  }
  Addresses.Clear();
  if (!e.Cancelled)
  {
    foreach (var adress in e.Result.Select(adrInfo => adrInfo.Information.Address))
    {
      Addresses.Add(string.Format("{0} {1} {2} {3} {4}", 
        adress.Street, adress.HouseNumber, adress.PostalCode,
        adress.City,adress.Country).Trim());
    }
  }
}

It clears up the callback, clears the Addresses list, and then processes the parts of the result into a single string per address. Like any good reverse geocoding service Microsoft have implemented this to return a set of results – there may be more addresses on one location, for instance in a large apartment building – although I never got more than one result back per location when I tested this in the Netherlands.

This a complete reverse geocoding viewmodel that basically does not care where the GeoCoordinate comes from, or the result goes to. So this is very versatile. There isn’t any GUI, and yet we already have a working app

The initial XAML for binding this stuff – after setting the datacontext to this viewmodel – looks pretty simple:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
  <maps:Map/>
  <Grid Height="58" VerticalAlignment="Top" Background="#7F000000">
    <phone:LongListSelector ItemsSource="{Binding Addresses}" 
      HorizontalContentAlignment="Left" Margin="12,0"/>
  </Grid>
</Grid>

… and then we run into a challenge. Two actually. The last tapped location is not a property we can bind to, and that the location is a Point – a screen location, not a GeoCoordinate in real world coordinates.

This can be solved by using an Attached Dependency Property (I think), by some Code Behind or my trademark way - by creating a simple behavior. After all, I don’t want to bother designers with code and I like the easy reusability of a behavior:

using System.Device.Location;
using System.Windows;
using Microsoft.Phone.Maps.Controls;
using Wp7nl.Behaviors;

namespace Wp8nl.Behaviors
{
  public class TapToCoordinateBehavior : SafeBehavior<Map>
  {
    protected override void OnSetup()
    {
      AssociatedObject.Tap += AssociatedObjectTap;
    }

    void AssociatedObjectTap(object sender, 
      System.Windows.Input.GestureEventArgs e)
    {
      var tapPosition = e.GetPosition((UIElement)sender);
      TappedCoordinate = 
        AssociatedObject.ConvertViewportPointToGeoCoordinate(tapPosition);
    }

    protected override void OnCleanup()
    {
      AssociatedObject.Tap -= AssociatedObjectTap;
    }

 // GeoCoordinate TappedCoordinate dependency property omitted

   }
}

This behavior is implemented as a SafeBehavior child class, to prevent memory leaks. It’s actually pretty simple – it traps the ‘Tap’ event, determines the location, converts it to a GeoCoordinate and puts it into the TappedCoordinate Dependency Property. Which, in turn, can be bound to the view model. The designer can simply drag this behavior on top of the map and set up the data binding. Don’t you love Blend? XAML take 2:

<Grid x:Name="ContentPanel" Grid.Row="1" 
   Margin="12,0,12,0">
  <maps:Map>
    <i:Interaction.Behaviors>
      <Behaviors:TapToCoordinateBehavior 
          TappedCoordinate="{Binding TapCoordinate, Mode=TwoWay}"/>
    </i:Interaction.Behaviors>
  </maps:Map>
  <Grid Height="58" VerticalAlignment="Top" Background="#7F000000">
    <phone:LongListSelector ItemsSource="{Binding Addresses}" 
           HorizontalContentAlignment="Left" Margin="12,0"/>
  </Grid>
</Grid>

And that’s all there is to it. Reverse geocoding is Windows Phone 8 is insanely easy.

Full source code, as usual, can be downloaded here.

Surface RT versus Surface Pro versus the competition for REAL dummies

noreply@blogger.com (Joost van Schaik) — Fri, 08 Mar 2013 07:39:00 PST

About every pundit who is somewhat interested in Microsoft either by love or abject hate has written about this already – and still I am going to do my take. Why? Because I am one the few people on this planet who actually was crazy enough to purchase both a Surface RT and a Surface Pro and therefore am entitled to my rant – and because I still get comments like “I think Surface Pro is too expensive for a tablet and has too little battery life for it”, which indicates people still completely don’t get it. With ‘tablet’ almost invariantly people mean “iPad”, by the way.

The very short version of this post is this ‘infographic’

I used a mathematical symbol ≈ which means ‘is equivalent to’. That is something entirely different than “equals to”. Very important distinction. Keep that in mind. I will use a lot of ‘equivalents’ in this ~~blog post~~ rant.

When you think of a Surface RT – think of something that moves in the same space as an iPad. Long battery life, relatively cheap (don’t get me started on Apple pricing), light, ideal for use on your lap or in your hand, good content consumption device. Plus some extras. But let’s not confuse the picture already.

When you think of a Surface Pro – think of an Ultrabook. Yes, a real computer. A real powerhouse too, ultra portable, and it runs the full Monty – I mean Windows 8 - but that comes at a price. It’s heavier, more expensive, burns more battery, and it gets hotter too. Of course it does. Look, it’s like saying “My wife has this cute Japanese car that does over 50 miles to the gallon when she’s doing 70 on the interstate but this other car burns much more fuel and generates a lot of exhaust” and then the car you use…

…is the car equivalent of something like this:
Dude, I have some bad news for you. If there’s indeed the equivalent of an F22 Raptor sitting in your driveway when you just want to do some cruising, you might have paid some more attention to the brochure or might have asked some more questions at the dealer clerk before getting out the ole’ VISA card. This machine can carry more and heavier load than your wife’s car – and it can take it there very much faster. This machine is made for serious business. As is Surface Pro. Only with less pyrotechnics.

Now I will admit Microsoft has made life a little bit more complicated than my simple images and broad statements do justice. That’s because of a very a simple reason: the current state of affairs in electronics, as well as the radical design approach the Surface hardware engineering team took, made it possible that under the “Surface” flag now reside two very similar looking – but very dissimilar devices. It’s like the F22 and your wife’s Japanese car nearly look the same, have the same controls, and even share accessories – but one will be a very good car, the other will take off at supersonic speed and be halfway Some Place Where Bad People Live (and – admittedly – a place where those Bad People won’t probably be for very much longer) before your wife has even made it to the onramp of the interstate. Incidently, your wife may be in for a hell of surprise when one day she just wants to take the kids to school and takes the wrong key set ;-).

The funny thing is – radical as it’s design may be, Surface Pro is ‘just a PC’. As I showed in the ‘infographic’ above, it’s actually ‘just an Ultrabook’, in the same way an F22 is ‘just a jet airplane’. Surface Pro is the nth generation descendant of all the PC’s in the world, and it’s odd that it took a software company to let it see the light. Yet, the smaller, cheaper Surface RT is actually a much more remarkable and innovative design – it runs on total different hardware, that has an extremely long battery life, but still it runs Windows 8. Like I said, RT is more like a tablet. But, to make things more complicated, in a smart move to make their ‘tablet’ offering more attractive and not just another me-too, Microsoft have made it possible to attach a keyboard to Surface RT and ships you a fully licensed Home version of Office. You get the crown ‘desktop jewels’ for free. Office in a very portable box. So in stead of only a consumption device, Surface RT is also a content creation device. You can make Word documents, Excel sheets, PowerPoint presentations just like on any other PC. Using a traditional desktop program. You can even attach a mouse to it using it’s USB port. So your tablet can act like a PC to an extent. And here my infographic breaks down, and my F22 versus the wife’s car analogy as well. It’s like your wife’s car has this extra set of controls that can be used to fly short distances at limited height as well - wouldn’t she want have that to overcome traffic jams and red lights ;).

So a more accurate way to position RT next to the competition is like this:

There is this other funny side effect too – because Surface RT runs on different hardware, the ‘foundation’ of it’s Windows needed to be changed too. You can hardly see that on the outside, but it has profound effects, one of them being that Windows RT – the Windows version that runs on Surface RT - is completely impervious to viruses. It’s like trying infect a fish with the human common cold – DNA does not match, the organs that are needed for infection are simply not there.

So it comes down to this:

Surface Pro is a PC – it may look like a tablet and it can be used as a tablet, but it’s not its primary intended use. It’s a bit heavy for that and has this other characteristics that doesn’t make it the ideal tablet. Just like an F22 can be used on the highway – but it’s better in the air. You are doing development? Heavy gaming? Heavy duty photo or movie editing? This is the machine for you.
Surface RT is primary a tablet but can also be used for some PC (Office) tasks that used to require a full PC. It’s like a car that can fly a little, but it cannot carry deadly loads with it. You are doing office, mail and some content/web browsing, casual games, maybe a bit of movie watching? A lot of it on the go, removed from any outlet? Try this one.

And of course, you can also try any other kind of device, running either Windows RT or Windows Pro (i.e. being equivalent to Surface RT and Surface Pro) to find out what suits your need. I give you only one golden rule – whatever you buy, Surface or no Surface, RT of Pro – make sure it has a touch screen. With touch Windows 8 really shines.

PS: In case anyone wonders whether or not I am happy with my choice for Surface Pro as a portable development machine – let me just quote my fellow MVP Rob Miles on that one: “HELL YEAH!”

Publishing games in the Brazilian Windows Phone store

noreply@blogger.com (Joost van Schaik) — Sat, 02 Mar 2013 09:03:00 PST

Brazil, a strong developing economy, is the largest country is South America, and has the biggest population of South America as well. From a game developer’s standpoint, it’s unfortunately also one of the ‘restricted’ countries. In short, this means you cannot submit a game – any game - to the Brazilian Windows Phone store without it being rated first. Since most developers outside of Brazil think this is a complicated and expensive procedure, and don’t speak Portuguese anyway – they tend to uncheck the Brazilian store and thereby leaving the Brazilians stranded, and denying themselves the opportunity to branch out in South America.

Now this is no longer necessary. A Brazilian guy named Guilherme S. Manso contacted me on twitter about a month ago claiming he made a write-up describing how to get your game rated for the Brazilian store. This got me about half-way, and the rest was explained to me in a Skype session by my fellow Phone Development MVP Rodolpho Marques Do Carmo. With Guilherme’s permission I reworked both explanations to one blog post, making it easy for every game developer to enter the Brazilian store. And the procedure is free, too.

If the game already has an ESRB or PEGI game rating
Recently, the government of Brazil started accepting the indicative international PEGI and ESRB ratings as a prerequisite for a “national auto rating”. That is, if a game has been rated by any of these institutions, all you need to do is to select one of the age groups from the DJCTQ (the Brazilian government rating) and attach the document that proves that the game has the PEGI or ESRB rating when you submit the game in the Windows Phone Development center. You must choose an age range that matches as closely as possible to the age received by indicative classification PEGI or ESRB. L is for all ages, the others show the age groups – 10 years, 12 and so on. If you already have a rating like this you probably know all about rating and probably don’t need this blog post anyway. I did not follow this track – my game had no rating at all.

If you don’t have any rating yet and want a Brazilian specific rating
First of all, you will need this document. It’s mostly English so it should be intelligible for almost everyone able to read this blog post ;-). It’s a Word document, and it mostly contains check boxes. I ticked check boxes by right-clicking them, selecting “Properties” and then clicking “Selected” under “default value”. You have to fill in some other stuff and then you have to hand-sign it. It’s rather straightforward. You can then print the result, sign it and scan it, or – as I did - sign it with the a pen on a tablet and save the result as PDF. The word document as I used it – minus my signature – can be seen here and used as an example.

Second, you will need to write a synopsis of the game – and provide game itself. I did this the easy way and combined these points: I made another Word document that described the game, provided a global store link to the game, a link to the game in the USA store, and I made a video of the game play that I made available for download. The document I used can be found here. They have a lot of games to process, so make the work of the raters as easy as possible. Another tip: make sure there is a trial version of the game available. If the game needs to be bought first, it will take much longer to get certified.

Third – optionally – you will need to provide a bill of rights for the game. This is only necessary when the Rating Requester Name is different from the Publisher Name (or when it’s not clear that it comes from the same producer). It is a simple statement signed by hand as well, saying that you are the copyright owner of the game or that the holder is aware that you are asking for the classification. Since that did not apply to me, I have no example of that.

E-mailing the rating request
You will need to e-mail the rating request document (the thing with all the checkboxes), the synopsis and optionally the bill of rights to classificacaoindicativa@mj.gov.br.
The title of the mail needs to be: "Jogo para Classificação - <your game name>" (this is the only part that needs to be Portuguese).
I simply e-mailed:
"Dear Sir, Madam,
I hereby request certification of my game Catch’em birds for release in Brazil according to the attached documentation.

Highest regards

Joost van Schaik
Amersfoort
The Netherlands”

Obtaining the game certificate
Here things get a little odd: certification will take about ten days, but you will not be informed about the progress or the result. You will need to go to this page regularly to check if your app has passed certification. It shows itself like showed to the left. You simply enter the name or part of the name of your game, click ‘consulta’, and with any luck it will show a result. There is a catch: it will only displayed on this page for a pretty short time. If you miss it, you will get this page, which basically means ‘not found’

But, if you hit the grey bar at the left bottom that says “Abrir/Fechar Pesquisa” you get an extended search form that allows you to enter dates and stuff:
So here I ask the ‘find everything (todos) that contains the word ‘birds’ and was approved between January 1st and February 28th 2013 and now if you hit ‘consulta’…

Bingo! Click the blue header (in my case “Diário Oficial da União - Seção 1 - Edição nr 38 de 26/02/2013 Pag. 27”) and this will download a file called “INPDFViewer.pdf”. That’s basically a page of a Brazilian law book saying your game is permitted for the given classification. There’s a bunch of games on that page, but near the end of the page it says:
Título: CATCH`EM BIRDS (Holanda - 2012)
Titular dos Direitos Autorais: JOOST VAN SCHAIK
Distribuidor(es): JOOST VAN SCHAIK (MICROSOFT`S WINDOWS PHONE STORE)
Classificação Pretendida: Livre
Categoria: Ação
Plataforma: Telefone Celular/Smartphone
Tipo de Análise: Sinopse e Vídeo
Classificação: Livre
Processo: 08017.004064/2013-35
Requerente: JOOST VAN SCHAIK

And that’s it. Now you can tick the ‘Brazil’ checkbox in the Windows Phone dev center, select a category according to your classification, and upload the INPDFViewer.pdf as proof. I have tried this procedure to the end, and my game is now in the Brazilian store. And so, my friends, can be yours. The road to Brazil is now wide open for game developers, thanks to Guilherme and Rodolpho, so let’s go to Brazil!

BTW, I haven’t tried this but I assume publishing Windows 8 Store apps can be done following the same procedure.

A KnockOut.js binding helper for a JQuery Mobile Slider

noreply@blogger.com (Joost van Schaik) — Wed, 06 Feb 2013 23:59:00 PST

For those who have missed it – besides all the things I do on Windows Phone and Windows 8 I actually have a job, and in that job I am currently doing a lot of HTML5/Javascript development – now focusing on a Single Page App using (amongst others) Knockout.js and JQuery Mobile. For those who don’t know: Knockout is a great tool that makes data binding possible in a web environment, making the way I think about making applications – using MVVM – possible in an HTML/Javascript environment as well. If you use Amplify.js you even have messaging. Oh goody!

Now don’t get me wrong – I am not forsaking XAML and C# (like some others *ahem*), but I tried to find a way to bind a JQuery Mobile slider to Knockout.js. That’s not supported out of the box, so you have to make or find a customer ‘binding helper’ and I found so much examples that were plainly wrong or incomplete that I had to blog mine, which is complete and actually works:

ko.bindingHandlers.jQuerySliderValue = {
  // Initialize slider
  init: function (element, valueAccessor)
  {
    var val = valueAccessor()();
    var el = $(element);
    el.slider({ value: val });

    el.bind("change", function (event, ui)
    {
      var value = valueAccessor()();
      if (value !== el.val)
      {
        valueAccessor()(parseInt(el.val()));
      }
    });
  },

  //handle the model value changing
  update: function (element, valueAccessor)
  {
    var el = $(element);

    var value = ko.utils.unwrapObservable(valueAccessor()());
    if (value !== el.val())
    {
      el.val(value);
      el.slider("refresh");
    }
  }
};

You can use this in HTML like this:

<input type="range" name="slider-1" id="slider-1" 
  min="0" max="5"
  data-bind="jQuerySliderValue: locationDataIndex" />

Now I haven’t all conjured this up out of thin air, there are plenty of samples on, for instance, stackoverflow. Actually my most important addition to the samples out there is the red parseInt piece. All samples seem to fail to take into account that a) data binding can happen both way and b) a Jquery mobile slider apparently returns a string value. This leads to some interesting results if you try to manipulate the return value in your javascript view model by adding 1 to it. What you think happens is:

0+1=1 , 1+1=2 etc.

But like I said, used this way a range return a string, so you get

“0” + 1 = “01” , “01” +1 = “011”.

And an interesting out of range error. The really gotcha is that it seems to go well the first time, the error only occurs the second time. It seems to make no sense at all. Sure, I could have used input type="number" data-type="range", maybe that would have helped as well, but that ain’t in the samples either. Either way, this fixes it for all cases.

So, this is a very old type of blog post, not so much written from the desire to teach and share but borne from sheer annoyance about the incompleteness and incorrectness of what’s out there – the feeling that actually fuelled the creation of this blog ;-)

An MVVM-friendly ‘tap-to-connect’ NFC socket network helper for Windows Phone 8

noreply@blogger.com (Joost van Schaik) — Mon, 14 Jan 2013 12:25:00 PST

For my Windows Phone 8 game “Pull the Rope” I wrote a utility class to make pairing phones and obtaining a two-way communication channel a little bit easier. I already dabbled into this while developing the game, but now I feel it’s time to show a more comprehensive solution.

I re-use the NavigationEventArgsExtensions and the NavigationMessage from my previous article “Handling Windows Phone 8 NFC startup events using the MVVMLight” without describing them further – I suggest you read this article as a preface to this one if you haven’t done so before. The utility class I describe in this article handles the pairing via tap-to-connect and provides – when that’s done – a method for sending a message and an event for receiving a message. I have peppered the code with debug statements, so can you nicely see in your output windows what’s exactly happening inside of the class when you are debugging on the phone.

Messages are sent and received as strings, therefore the message argument class is not very complex either:

using System;

namespace Wp7nl.Devices
{
  public class ReceivedMessageEventArgs : EventArgs
  {
    public string Message { get; set; }
  }
}

The start of the TtcSocketHelper (‘Tap-To-Connect’) class, as I have called it, is as follows:

using System;
using System.Diagnostics;
using System.Threading.Tasks;
using GalaSoft.MvvmLight.Messaging;
using Windows.Foundation;
using Windows.Networking.Proximity;
using Windows.Networking.Sockets;
using Windows.Storage.Streams;

namespace Wp7nl.Devices
{
  public class TtcSocketHelper
  {
    public TtcSocketHelper()
    {
      Messenger.Default.Register<NavigationMessage>(this, 
        ProcessNavigationMessage);
    }

    public virtual void Start()
    {
      PeerFinder.TriggeredConnectionStateChanged += 
         PeerFinderTriggeredConnectionStateChanged;

      PeerFinder.AllowBluetooth = true;
      PeerFinder.Start();
    }

    private void ProcessNavigationMessage(NavigationMessage message)
    {
      Debug.WriteLine("TtsHelper.ProcessNavigationMessage " + 
        message.NavigationEvent.Uri);

      if (message.IsStartedByNfcRequest)
      {
        Start();
      }
    }
  }
}

The constructor subscribes this helper class to a message that will need to be fired when the application navigates to it's main page. If it detects the app is started by an NfcRequest - i.e. a tap-to-connect, the PeerFinder is immediately started to allow for the further build-up of the connection. I already described this technique in the article I already mentioned. The method Start can also be called by an the application, for instance the press of a “connect” button. Note that I only allow Bluetooth connections – this is because this class comes from my game, which does not need the highest possible speed, but the lowest possible latency. Ironically Wi-Fi seems to have a little more latency than Bluetooth.

The next part is the handling of the connection process itself:

private void PeerFinderTriggeredConnectionStateChanged(object sender, 
             TriggeredConnectionStateChangedEventArgs args)
{
  switch (args.State)
  {
    case TriggeredConnectState.Completed:
      FireConnectionStatusChanged(args);
      socket = args.Socket;
      StartListeningForMessages();
      PeerFinder.Stop();
      break;
    default:
      FireConnectionStatusChanged(args);
      break;
  }
}

private void FireConnectionStatusChanged(TriggeredConnectionStateChangedEventArgs args)
{
  Debug.WriteLine("TtsHelper: " + args);
  if (ConnectionStatusChanged != null)
  {
    ConnectionStatusChanged(this, args );
  }
}

public event TypedEventHandler<object, 
             TriggeredConnectionStateChangedEventArgs> ConnectionStatusChanged;

private StreamSocket socket;

This is kind of nicked from the Bluetooth app to app sample at MSDN, although I made it a bit simpler: only on TriggeredConnectState.Completed I need to do something, i.e. obtain a socket. For the rest of the events, I just pass them to the outside world in case it’s interested.

Next is the part that initiates and performs the actual listening for messages, once the socket is obtained:

private async void StartListeningForMessages()
{
  if( socket != null )
  {
    if (!listening)
    {
      listening = true;
      while (listening)
      {
        var message = await GetMessage();
        if (listening)
        {
          if (message != null && MessageReceived != null)
          {
            MessageReceived(this, 
               new ReceivedMessageEventArgs {Message = message});
          }
        }
      }
    }
  }
}

private async Task<string> GetMessage()
{
  try
  {
    if (dataReader == null) dataReader = new DataReader(socket.InputStream);
    await dataReader.LoadAsync(4);
    var messageLen = (uint)dataReader.ReadInt32();

    await dataReader.LoadAsync(messageLen);
    var message = dataReader.ReadString(messageLen);
    Debug.WriteLine("Message received: " + message);

    return message;
  }
  catch (Exception ex)
  {
    Debug.WriteLine("GetMessage: " + ex.Message);
  }
  return null;
}

public event TypedEventHandler<object, ReceivedMessageEventArgs> MessageReceived;

private DataReader dataReader;

private bool listening;

The StartListeningForMessages basically enters an endless loop – endless that is, until the “listening” is set to “false” - waiting for GetMessage to return something. The GetMessage is almost 100% nicked from the Bluetooth app to app sample at MSDN. the first four bytes are supposed to contain the message length, the rest is payload, hence the two read actions.

Then of course we need a method to actually send messages:

private readonly object lockObject = new object();

public async void SendMessage(string message)
{
  Debug.WriteLine("Send message:" + message);
  if (socket != null)
  {
    try
    {
      lock (lockObject)
      {
        {
          if (dataWriter == null)
          {
            dataWriter = new DataWriter(socket.OutputStream);
          }

          dataWriter.WriteInt32(message.Length);
          dataWriter.StoreAsync();

          dataWriter.WriteString(message);
          dataWriter.StoreAsync();
        }
      }
    }
    catch (Exception ex)
    {
      Debug.WriteLine("SendMessage: " + ex.Message);
    }
  }
}
private readonly object lockObject = new object();

private DataWriter dataWriter;

which comes almost directly from my earlier article “Preventing high speed socket communication on Windows Phone 8 going south when using async/await”

And finally we have this brilliant method, which basically resets the TtcSocketHelper class back to its initial status.

public void Reset()
{
  PeerFinder.Stop();
  if (dataReader != null)
  {
    try
    {
      listening = false;
      if (dataReader != null)
      {
        dataReader.Dispose();
        dataReader = null;
      }
      if (dataWriter != null)
      {
        dataWriter.Dispose();
        dataWriter = null;
      }
      if (socket != null)
      {
        socket.Dispose();
        socket = null;
      }
    }
    catch (Exception ex)
    {
    }
  }
}

To use this class:

Make sure you app does fire a NavigationMessage as described here
Make a new TtcSocketHelper.
Subscribe to its ConnectionStatusChanged event
Subscribe to its MessageReceived event
Call Start
Wait until a TriggeredConnectState.Completed comes by
Call SendMessage – and see them appear in the method subscribed to MessageReceived on the other phone.

Oh, and don’t forget to set ID_CAP_PROXIMITY in your WMAppManifest.Xaml.right?

The source code – and a working demo of this component – can be found in the demo solution right here. It’s a very simple chat-application built upon TtcSocketHelper. Of course this is all MVVMLight based, and I start off with the basic viewmodel and its properties:

using System.Collections.ObjectModel;
using System.Windows;
using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using GalaSoft.MvvmLight.Messaging;
using Windows.Networking.Proximity;
using Wp7nl.Devices;

namespace TtcDemo.Viewmodels
{
  public class NfcConnectViewModel : ViewModelBase
  {
    private TtcSocketHelper ttcSocketHelper;

    public ObservableCollection<string> ConnectMessages { get; private set; }
    public ObservableCollection<string> ReceivedMessages { get; private set; }

    private bool canInitiateConnect;
    public bool CanInitiateConnect
    {
      get { return canInitiateConnect; }
      set
      {
        if (canInitiateConnect != value)
        {
          canInitiateConnect = value;
          RaisePropertyChanged(() => CanInitiateConnect);
        }
      }
    }

    private bool isConnecting;
    public bool IsConnecting
    {
      get { return isConnecting; }
      set
      {
        if (isConnecting != value)
        {
          isConnecting = value;
          RaisePropertyChanged(() => IsConnecting);
        }
      }
    }

    private bool canSend;
    public bool CanSend
    {
      get { return canSend; }
      set
      {
        if (canSend != value)
        {
          canSend = value;
          RaisePropertyChanged(() => CanSend);
        }
      }
    }
    
    private string message;
    public string Message
    {
      get { return message; }
      set
      {
        if (message != value)
        {
          message = value;
          RaisePropertyChanged(() => Message);
        }
      }
    }
  }
}

We have a TtcSocketHelper itself, and two ObservableCollections of strings. ConnectMessages serves is to report the connection progress, and ReceivedMessages hold the messages received by your ‘opponent’ once the connection is established. Then we have three booleans, that basically turn on or off certain parts of the user interface depending on the state:

Initially, IsConnecting is true and CanSend is false. That should show a part of the user interface to show ConnectMessages.
If the app is started by the user, CanInitiateConnect is true as well, so the user can click on some “connect” button as well. If the apps is started by an NFC request, the process of creating a connection is initiated by someone else and the user should not be able to press a “connect” button to prevent the whole process from being south. I my mind I call the instance of the app that has been started by the user “master”, the instance started by the NFC request “slave”.
If the connection has been successfully established, IsConnecting should become false and CanSend true, disabling the controls handling the connection setup, and enabling the controls doing the actual chatting stuff.

And yeah, I know, usually CanSend != IsConnecting so I could replace this with one boolean. But that makes the designer’s job harder, as I will show further on.

Finally we have the Message property, which is where the message the user wants to send. We’ll come to that later. The viewmodel is initialized via a method “Init”, now called in the constructor:

public NfcConnectViewModel()
{
  Init();
}

private void Init()
{
  Messenger.Default.Register<NavigationMessage>(this, ProcessNavigationMessage);

  if (ConnectMessages == null)
  {
    ConnectMessages = new ObservableCollection<string>();
  }

  if (ReceivedMessages == null)
  {
    ReceivedMessages = new ObservableCollection<string>();
  }

  if (!IsInDesignMode)
  {
    if (ttcSocketHelper == null)
    {
      ttcSocketHelper = new TtcSocketHelper();
      ttcSocketHelper.ConnectionStatusChanged += ConnectionStatusChanged;
      ttcSocketHelper.MessageReceived += TtsHelperMessageReceived;
    }
    else
    {
      CanSend = true;          
    }
  }
  IsConnecting = true;
}

It doesn’t really do that much – apart from initializing the ObservableCollections, creating an instance of TtcSocketHelper and subscribing to its events, and setting the initial status. There are two things to note here – one, in design mode both CanSend and IsConnecting are true so all the parts of the GUI are enabled. This is to remain friends with the designer, who can now shut on or off both the connection part of the GUI and the messaging part when he/she chooses using Blend, making the design process a lot easier - in stead of having to muck around in your code – or worse, by coming to complain to you.

The second thing to note is that this viewmodel also subscribes to NavigationMessage (just as TtcSocketHelper itself) . This is because the viewmodel likes to know as well if it’s in a master or slave app:

private void ProcessNavigationMessage(NavigationMessage message)
{
  CanInitiateConnect = !message.IsStartedByNfcRequest;
}

so it can enable or disable the connect button. The handling of the connection messages is done by ConnectionStatusChanged:

private void ConnectionStatusChanged(object sender,
  TriggeredConnectionStateChangedEventArgs e)
{
  Deployment.Current.Dispatcher.BeginInvoke(() =>
    ConnectMessages.Add(GetMessageForStatus(e.State)));
    
  if (e.State == TriggeredConnectState.Completed)
  {
    Deployment.Current.Dispatcher.BeginInvoke(() =>
    {
      IsConnecting = false;
      CanSend = true;
    });
  }
}

private static string GetMessageForStatus(TriggeredConnectState state)
{
  switch (state)
  {
    case TriggeredConnectState.Listening:
      return "Listening....";

    case TriggeredConnectState.PeerFound:
      return "Opponent found";

    case TriggeredConnectState.Connecting:
      return "Opponent found";

    case TriggeredConnectState.Completed:
      return "Connection succesfull!";

    case TriggeredConnectState.Canceled:
      return "Connection canceled";

    default: //TriggeredConnectState.Failed:    
      return "Connection failed";
  }
}

That first adds a message to ConnectMessages using a little helper method GetMessageForStatus (I’d suggest loading this from a resource if you do this in a real app) . After that, if it detects a TriggeredConnectState.Completed message coming by, switches from connect mode to chat mode, so to speak. Since all these events are raised outside of the UI thread, say hello to your old friend Dispatcher to prevent cross-thread access exceptions. Oh, and then of course there’s the little matter of enabling the user actually starting the whole connection process:

public ICommand StartCommmand
{
  get
  {
    return new RelayCommand(
        () =>
        {
          ConnectMessages.Add("Connect started...");
          CanSend = false;
          CanInitiateConnect = false;
          ttcSocketHelper.Start();
        });
  }
}

It adds a message to ConnectMessage (to show “see, I am really doing something!”), disables the connect button (as to prevent an annoying Windows Phone certification tester crashing your program) and then it starts the helper. All this is only needed to handle the build-up of the connection. All that actually handles the chatting is merely this:

public ICommand SendComand
{
  get
  {
    return new RelayCommand(
      () =>
      {
        ttcSocketHelper.SendMessage(Message);
        Message = string.Empty;
      }
   );
  }
}

private void TtsHelperMessageReceived(object sender,
                                      ReceivedMessageEventArgs e)
{
  Deployment.Current.Dispatcher.BeginInvoke(() =>
    ReceivedMessages.Add(e.Message));
}

As you can see it’s only a command that relays the message to the TtcSocketHelper and then clears the field, and a simple method listening for messages and adding received message contents to ReceivedMessages, once again with the aid of the Dispatcher.

Since this article is already way longer than I planned, I limit myself to the part of the XAML that is actually interesting:

<!-- Connect panel-->
<Grid x:Name="ConnectGrid" Margin="0,0,0,76" Grid.RowSpan="2" 
   Visibility="{Binding IsConnecting, Converter={StaticResource VisibilityConverter}}">
  <Grid.RowDefinitions>
    <RowDefinition Height="425*"/>
    <RowDefinition Height="106*"/>
  </Grid.RowDefinitions>
  <Button Content="Connect" HorizontalAlignment="Center" VerticalAlignment="Top"
     IsEnabled="{Binding CanInitiateConnect}" Command="{Binding StartCommmand}" 
     Grid.Row="1"/>
  <ListBox ItemsSource="{Binding ConnectMessages}" Background="#FF091630"/>
</Grid>

<!-- Message panel-->
<Grid x:Name="MessageGrid" 
      Visibility="{Binding CanSend, Converter={StaticResource VisibilityConverter}}" >
  <Grid.RowDefinitions>
    <RowDefinition Height="110*"/>
    <RowDefinition Height="100*"/>
    <RowDefinition Height="412*"/>
  </Grid.RowDefinitions>
  <TextBox Height="72" Margin="0,10,0,0" TextWrapping="Wrap" VerticalAlignment="Center" 
    Text="{Binding Message, Mode=TwoWay}"/>
  <Button Content="send message" Grid.Row="1" Command="{Binding SendComand, Mode=OneWay}"/>
  <ListBox Grid.Row="2" ItemsSource="{Binding ReceivedMessages}" 
           Background="#FF091630" Margin="12,0"/>
</Grid

You can see ConnectGrid whose visibility is controlled by IsConnecting, and a MessageGrid whose visibility is controlled by CanSend. Then there is the Connect button that is enabled or disabled by CanInitiateConnect. The two faces of the application look like as showed on the right. On the left image you see the app just after connect has been initiated by the ‘master’ the right shows the app after having received a message from the first phone and the user of the second phone responding.

I will add the classes described in this article to the wp8-specific version of my wp7nl CodePlex library soon. In the mean time, you can find them in the Wp7nl.Contrib project of the demo solution.

For the record, there’s also a ResetCommand in the viewmodel that makes it possible to reset the whole connection process, but that’s currently not bound to a button of sorts. I leave that as exercise for the reader ;-)

A final word: I am aware of the fact that I could also have used the Visual State Manager to turn pieces of the GUI on and off (and animate that, too) but I did not want to add even more complexity to this article.

Playing sounds on Windows Phone using the MVVMLight Messenger

noreply@blogger.com (Joost van Schaik) — Sun, 13 Jan 2013 05:01:00 PST

In my never-ending quest to preach the gospel of MVVM in general and MVVMLight in particular as the way to make a structured Windows Phone application I show a little part of my my newest Windows Phone app, “Pull the Rope”. It’s a basically a rope pulling contest played on two phones. I think it’s quite fun to play but I am pretty sure it’s even more hilarious to watch other people play it, swiping like maniacs on their phones.

The first version did not even have sounds – I decided to go the “ship early ship often” route this time – so some days ago I submitted a version that does some supportive sound. Of course my game is MVVMLight based and for adding the game sound I pulled a tried-and-tested (at least, by me) out of the hat – the Messenger-Behavior combo.Using the Messenger requires of course a message, so I started off with that:

namespace Wp7nl.Audio
{
  public class PlaySoundEffectMessage
  {
    public PlaySoundEffectMessage(string soundName, bool start = true)
    {
      SoundName = soundName;
      Start = start;
    }

    public string SoundName { get; private set; }

    public bool Start { get; private set; }
  }
}

So this message has only two options – an identifier for the sound that must be started, and a boolean that indicates whether the sound should be started (default) or stopped (this for sounds that are played in a loop).

Then the behavior itself. As usual, I start off with a couple of Dependency Properties, to support data binding:

SoundFileLocation (string) – the location of the sound file to play
SoundName (string) – the sound identifier; if PlaySoundEffectMessage.SoundName has the same value a this property, the behavior will take action.
Repeat (bool) – indicates if the sound should be played in a loop or not.

I hope you will forgive me for not including the Dependency Properties’ code in the this article as it is pretty much run of the mill and takes a lot of space.

The core of the behavior itself is actually pretty simple. It’s meant to be used in conjunction with a MediaElement. First, the setup. I created this as a SafeBehavior to make setup and teardown a little less complex:

using System;
using System.Windows;
using System.Windows.Controls;
using GalaSoft.MvvmLight.Messaging;
using Wp7nl.Behaviors;

namespace Wp7nl.Audio
{
  public class PlaySoundEffectBehavior : SafeBehavior<MediaElement>
  {
    protected override void OnSetup()
    {
      Messenger.Default.Register<PlaySoundEffectMessage>(
        this, DoPlaySoundFile);
      AssociatedObject.IsHitTestVisible = false;
      AssociatedObject.AutoPlay = false;
      var soundUri = new Uri(SoundFileLocation, UriKind.Relative);
      AssociatedObject.Source = soundUri;
      AssociatedObject.Position = TimeSpan.FromSeconds(0);
      SetRepeat(Repeat);
    }
  }
}

So basically this behavior subscribes to the message type we just defined. Then it goes on initializing the MediaElement – disabling hit test and autoplay, actually setting the sound file URI, initializing it to the beginning and initializing repeat (or not).

The method DoPlaySoundFile, which kinda does all the work, isn’t quite rocket science either:

private void DoPlaySoundFile(PlaySoundEffectMessage message)
{
  if (SoundName == message.SoundName)
  {
    if (message.Start)
    {
      AssociatedObject.Position = TimeSpan.FromSeconds(0);
      AssociatedObject.Play();
    }
    else
    {
      AssociatedObject.Stop();
    }
  }
}

If a message is incepted with the same sound name as has been set to the behavior in the XAML, then either start or stop the sound.

The rest of the behavior is basically some odds and ends:

private void SetRepeat(bool repeat)
{
  if (AssociatedObject != null)
  {
    if (repeat)
    {
      AssociatedObject.MediaEnded += AssociatedObjectMediaEnded;
    }
    else
    {
      AssociatedObject.MediaEnded -= AssociatedObjectMediaEnded;
    }
  }
}

private void AssociatedObjectMediaEnded(object sender, RoutedEventArgs e)
{
  AssociatedObject.Position = TimeSpan.FromSeconds(0);
  AssociatedObject.Play();
}

protected override void OnCleanup()
{
  Messenger.Default.Unregister(this);
  AssociatedObject.MediaEnded -= AssociatedObjectMediaEnded;
}

The first method, SetRepeat, enables or disables repeat. As a MediaElement does not support the endless loop by itself, repeat as such is implemented by subscribing the method AssociatedObjectMediaEnded to the MediaEnded event of the MediaElement – that does nothing more than kicking off the sound again. If repeat has to be turned off, the AssociatedObjectMediaEnded is unsubscribed again and the sound automatically ends.

Finally, the last method is called when the behavior is deactivated. It removes the messenger subscription and a possible repeat event subscription.

So how would you go about and use such a behavior? To demonstrate it’s working, I have created a small sample solution with the very exiting *cough* user interface showed to the right. What this app does is, as you click on the go button, is fire off the PlaySoundCommand command in the following, admittedly somewhat contrived view model:

using System;
using System.Windows;
using System.Windows.Input;
using System.Windows.Threading;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using GalaSoft.MvvmLight.Messaging;
using Wp7nl.Audio;

namespace SoundMvvm.Viewmodels
{
  public class SoundViewModel : ViewModelBase
  {
    public ICommand PlaySoundCommand
    {
      get
      {
        return new RelayCommand(
          () =>
            {
              var t = new DispatcherTimer {Interval =  
                      TimeSpan.FromSeconds(4)};
              t.Tick += TimerTick;
              t.Start();
            });
      }
    }

    private void TimerTick(object sender, EventArgs e)
    {
      tickNumber++;
      switch (tickNumber)
      {
        case 1:
          Messenger.Default.Send(new PlaySoundEffectMessage("Sad trombone"));
          break;
        case 2:
          Messenger.Default.Send(new PlaySoundEffectMessage("Ping"));
          break;
        case 3:
          Deployment.Current.Dispatcher.BeginInvoke(() => 
            Messenger.Default.Send(new PlaySoundEffectMessage("Ping", false)));
          var t = sender as DispatcherTimer;
          t.Stop();
          t.Tick -= TimerTick;
          break;
      }
    }

    private int tickNumber;
  }
}

This initializes and starts a DispatcherTimer that will fire every four seconds. So the first four seconds after you click the button absolutely nothing will happen – I wanted to simulate the situation in which an event in the view model, not necessarily directly kicks off the sound. At the first tick – after four seconds – the view model fires a message making the behavior start the “Sad trombone” sound, which runs about four seconds. Then it fires off the “Ping” message, which causes the “Ping” sound to be started and repeated by the behavior. After another four seconds (good for about three ‘pings’) it’s killed again by the second “Ping” message. And then this little app has done all it could. Cue sad trombone indeed ;-)

As to the XAML to make this all work, I’ve outlined in red (and underline for the color blind readers) the interesting parts:

<phone:PhoneApplicationPage
    x:Class="SoundMvvm.MainPage"
    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:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
    xmlns:audio="clr-namespace:Wp7nl.Audio;assembly=Wp7nl.MvvmLight"
    xmlns:viewmodels="clr-namespace:SoundMvvm.Viewmodels"
    mc:Ignorable="d"
    FontFamily="{StaticResource PhoneFontFamilyNormal}"
    FontSize="{StaticResource PhoneFontSizeNormal}"
    Foreground="{StaticResource PhoneForegroundBrush}"
    SupportedOrientations="Portrait" Orientation="Portrait"
    shell:SystemTray.IsVisible="True" >

  <phone:PhoneApplicationPage.Resources>
    <viewmodels:SoundViewModel x:Key="SoundViewModel" />
  </phone:PhoneApplicationPage.Resources>
  <Grid x:Name="LayoutRoot" Background="Transparent" 
                            DataContext="{StaticResource SoundViewModel}">
    <Grid.RowDefinitions>
      <RowDefinition Height="Auto"/>
      <RowDefinition Height="*"/>
    </Grid.RowDefinitions>

    <StackPanel x:Name="TitlePanel" Grid.Row="0" Margin="12,17,0,28">
      <TextBlock Text="DEMO MVVM SOUNDS" 
                 Style="{StaticResource PhoneTextNormalStyle}" Margin="12,0"/>
      <TextBlock Text="play sounds" Margin="9,-7,0,0" 
                     Style="{StaticResource PhoneTextTitle1Style}"/>
    </StackPanel>

    <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
      <Button Content="go!" Margin="0,31,0,0" VerticalAlignment="Top" 
              Width="128" Height="80" Command="{Binding PlaySoundCommand}"/>
    </Grid>

    <MediaElement>
      <i:Interaction.Behaviors>
        <audio:PlaySoundEffectBehavior SoundName="Sad trombone"
               SoundFileLocation="/Sound/Sad_Trombone-Joe_Lamb-665429450.mp3"/>
      </i:Interaction.Behaviors>
    </MediaElement>
    <MediaElement>
      <i:Interaction.Behaviors>
        <audio:PlaySoundEffectBehavior Repeat="True" SoundName="Ping" 
               SoundFileLocation="/Sound/Elevator-Ding-SoundBible.com-685385892.mp3"/>
      </i:Interaction.Behaviors>
    </MediaElement>
  </Grid>
</phone:PhoneApplicationPage>

On top we have the DataContext set to our viewmodel, which, by using it this way, is automatically instantiated. The “go!” button is bound to the PlaySoundCommand, and then you see near the bottom the two MediaElement objects which each a PlaySoundEffectBehavior. The first one plays the “Sad trombone" once as the message is received, the second repeatedly (Repeat=”True”) the “ping” sound until it receives a message with “Start” the to “false” indicating it should shut up.

In the sample solution you will find two projects: SoundMvvm (the app itself) and Wpnl.Contrib, which both the behavior and the message class. As you probably understand from this setup, both classes will be soon in the wp7nl CodePlex library.For the record, this is a Windows Phone 8 app, but I think this should work on Windows Phone 7 as well, although on 7 I would still go for the XNA SoundEffect class. The technique used for this behavior comes from my Catch’em Birds for Windows 8 app by the way, where you don’t have XNA at all.

Handling Windows Phone 8 NFC startup events using the MVVMLight Messenger

noreply@blogger.com (Joost van Schaik) — Wed, 26 Dec 2012 07:49:00 PST

As regular readers of this blog know, I am currently playing around with NFC on Windows Phone 8. I peeked a little in the Bluetooth app to app sample at MSDN to understand how to find a ‘peer’. A peer is defined as the same app, installed on a different phone. So basically you go around installing the app on two phones, start it on phone 1, make sure it calls PeerFinder.Start(), tap the phones together and presto - the popup as displayed in the image on the right appears. If you check ‘open app’ – or whatever it shows in the language you have selected – the app is started on the second phone as well.

You can distinguish between an app being started by itself, or with the “open app” button by overriding the OnNavigatedTo method from the app’s main startup page. If the app is all started up by itself, the NavigationEventArgs.Uri just contains the name of the main page, for instance “MainPage.xaml”. But if it is started by an NFC event, the Uri ends with the following rather funny long string:

ms_nfp_launchargs=Windows.Networking.Proximity.PeerFinder:StreamSocket

Annoyingly, the OnNavigatedTo event is only available inside the page’s code. If you want to handle this the MVVM way, you want this to be taken care of by a view model or a model, not by the page’s code behind.

I have gone the following route. First, I define a little extension method that easily helps me to determine if the app was initiated by the user or by an NFC event:

using System.Windows.Navigation;

namespace Wp7nl.Devices
{
  public static class NavigationEventArgsExtensions
  {
    public static bool IsStartedByNfcRequest(this NavigationEventArgs e)
    {
      var isStartedByNfcRequest = false;
      if (e.Uri != null)
      {
        isStartedByNfcRequest = 
          e.Uri.ToString()
          .Contains("ms_nfp_launchargs=Windows.Networking.Proximity.PeerFinder:StreamSocket");
      }
      return isStartedByNfcRequest;
    }
  }
}

And as I don’t like to pass bare events around, I make a little wrapper class to use as a message:

using System.Windows.Navigation;
using Wp7nl.Devices;

namespace PullTheRope.Logic.Messages
{
  public class NavigationMessage
  {
    public NavigationEventArgs NavigationEvent { get; set; }

    public bool IsStartedByNfcRequest
    {
      get 
      { 
        return NavigationEvent != null && NavigationEvent.IsStartedByNfcRequest();
      }
    }
  }
}

And it contains a convenient shortcut method as well. Then the only thing you have to do is indeed override the OnNavigatedTo method, like this:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
  base.OnNavigatedTo(e);
  Messenger.Default.Send(new NavigationMessage {NavigationEvent = e});
}

This is the only ‘breaking’ of the purist's MVVM approach – but as the event is nowhere else available, it’s also the only way to get it done. Sometimes you have to take the pragmatic approach. Anyway, somewhere in your model or view model you define which method should be called when the message is received

Messenger.Default.Register<NavigationMessage>(this, ProcessNavigationMessage);

a method to trap it

private void ProcessNavigationMessage(NavigationMessage message)
{
  // whatever – we are back in MVVM territory
}

and I trust you can take it from there ;-) .

Be aware the events generated are generated outside the GUI thread, so if you try to data bind properties changed from the event method, you might run into cross thread access errors. Deployment.Current.Dispatcher.BeginInvoke is your friend, then.

On blogging, sharing and commenting

noreply@blogger.com (Joost van Schaik) — Mon, 17 Dec 2012 11:06:00 PST

This is not about code, but about something a fellow developer and blogger told me, which made me quite sad. It’s a kind of personal rant, so feel free to skip it if you are looking for code.

In 2007, after a frustrating search on the internet for a complete and working code sample for whatever it was, I was quite pissed off. And I decided “well if apparently people are too lazy or too much ‘look at me’ superior to post complete and working samples, I will start doing so myself”. I also could have gone to the blogs I visited posting comments like “you moron, this code is incomplete and/or wrong” or “why don’t you stop coding/blogging the cr*p you post is useless”. While technically I would have been right, I don’t think it would have helped me solve my problems. Starting blogging myself did not help me solve that problems either, but at least I had a place where I could dump my own solutions for later reference. Very handy. Apparently other people liked it too.

I was lucky enough to post a few good articles, and a few very dumb ones too, but those were met with “hey, that’s obsolete”, “hey, this is a better solution” or “I think you are missing a few steps” – with links and information. I either did take the articles down, or reworked them with the new information. I was lucky enough not to get lambasted, flamed or receive abusive comments or mails – no, my baby steps were encouraged by a few people – mostly MVPs by the way – who kind of nudged me along the rocky path of the beginning blogger.

That encouragement made me go on, becoming confident enough so that when the occasional abusive comment arrived, I was able to ignore the wording of the comment and fix the error, or challenge the commenter: “so if you are such a know-it-all, why don’t you blog about it - why do you leave me stumbling in the dark making stupid avoidable errors?”.

I recently talked to the beginning blogger I mentioned before, who was severely flamed in the beginning of his ‘career’, and he almost quit blogging of that. The wording I use in the second paragraph are more or less quotes of what he received.

This is really very counterproductive behavior. If you are someone who likes to demonstrate his/her knowledge on someone else’s blog by making demeaning remarks – realize what you are effectively doing is extinguishing enthusiasm that may have grown into the creation of a vast information resource. You are killing creativity, stomping out the sharing flame, making one of the very few willing to take time to share knowledge retreat into his/her shell, maybe never to come back again.

The very short version:

Flaming other people’s blog has never led to more examples and information. If you want more and better examples: stimulate and encourage where you can, correct if you feel you must, and try to behave like a civilized human being.

And above all, start blogging yourself. Don’t be a prick – share. Use your knowledge to improve people, not to tear them down. That’s community. That’s how it works.

Thank you.

Preventing high speed socket communication on Windows Phone 8 going south when using async/await

noreply@blogger.com (Joost van Schaik) — Sun, 16 Dec 2012 11:15:00 PST

Currently I am working on a Windows Phone 8 action game in which you can fight a kind of duel. This involves pairing the phones via NFC and then obtaining a socket trough which the phones can exchange game information. Liking to steal from examples myself (why do you think I name my blog this way, eh?) I stole code from the Bluetooth app to app sample at MSDN. Now this is a great sample but it has one kind of problem for me.

I’ll skip the pairing, the obtaining of the socket and the definition of the data reader – that’s all documented in the MSDN sample. The method to send a message to the opponent was, in condensed form:

public async void SendMessage(string message)
{
  if (dataWriter == null)
  {
    dataWriter = new DataWriter(socket.OutputStream);
  }

  dataWriter.WriteInt32(message.Length);
  await dataWriter.StoreAsync();

  dataWriter.WriteString(message);
  await dataWriter.StoreAsync();
}

while at the same time both opponenents where listening using a simple method like

public async Task GetMessage()
{
  if (dataReader == null) dataReader = new DataReader(socket.InputStream);
  await dataReader.LoadAsync(4);
  var messageLen = (uint)dataReader.ReadInt32();
  Debug.WriteLine(messageLen);

  await dataReader.LoadAsync(messageLen);
  var message = dataReader.ReadString(messageLen);
  Debug.WriteLine(message);
  return message;
}

From the debug statements in this code you can see things weren’t exactly working as planned. Now the way this is supposed to work is as follows: as the opponent sends a message using SendMessage, the other phone is receiving a message via the socket in GetMessage. The first four bytes contain an unsigned integer containing the length of the rest of the message – which is supposed to be a string.

I noticed that while things went off to a good start, sooner or later one of the two phones would stop receiving messages or both games crashed simultaneously. I got all kind of null value errors, index out of range and whatnot. When I started debugging, I found out that while the app on phone 1 said it sent a 3-character string, the receiving app on phone 2 sometimes got a huge number for the message length, that obviously wasn’t sent, it read past the end of the stream – crash.

The MSDN sample works fine, as long as it is used for the purpose it was written, i.e. sending out (chat) messages at a kind of sedate pace – not for sending a lot of events per second to keep a game in sync. The essence of a stream is that it’s a stream indeed – things have to be written and read in the right order. For what happened of course was a race condition between two or more events in a short timeframe. The first event wrote the message length, the second event as well, then possibly a third, before the first one came to writing the actual message, and whatever arrived on the other phone was a garbled jumble of bytes that did exactly reflect what happened on the sending phone, but wasn’t the orderly message length – message payload stream the other phone expected.

The way I solved it – in a ‘there-I-fixed-it’ kind of way – was to use a lock on the write code so at least stuff went in the stream in the order the other phone was expecting it:

public async void SendMessage(string message)
{
  lock (this)
  {
    if (dataWriter == null)
    {
      dataWriter = new DataWriter(socket.OutputStream);
    }

    dataWriter.WriteInt32(message.Length);
    dataWriter.StoreAsync();

    dataWriter.WriteString(message);
    dataWriter.StoreAsync();
  }
}

Note you have to remove the “await” before the StoreAsync methods as those are not allowed within a lock. This method makes sure one message – and the whole message – is written on the stream and nothing comes in between.

Update – the first version of this posting contained a small error – which has been graciously pointed out to me by a few readers (see comments section). Also, I’ve been pointed to an article by Scott Hanselman about a similar subject. I’ve tried using the AsyncLock by Stephen Toub he describes but found out that although it works very good and my game does become a bit more fluid, the lag in getting messages across is a lot higher. Net effect: while the game runs more smoothly on both phones, the game state actually gets out of sync very fast, making the game unplayable. Apparently the AsyncLock approach doesn’t work for high speed continuous message exchange, so for now I’ll stick to the approach I described above.

Passing event arguments to the WinRT EventToCommandBehavior

noreply@blogger.com (Joost van Schaik) — Tue, 20 Nov 2012 09:00:00 PST

This week my fellow MVP Scott Lovegrove contacted me and asked if and how he could pass the result of an event to my WinRT EventToCommandBehavior and/or EventToBoundCommandBehavior. I replied this was currently not supported, but that would not be hard to make. He acknowledged that, and asked if he could mail some code. Since I am not very possessive of ‘my’ libraries, and am a lazy as any programmer should be, I responded with giving him developer access to Win8nl. He actually took up the challenge, and submitted the code.

Both EventToCommandBehavior and EventToBoundCommandBehavior now sport an extra property:

public bool PassEventArgsToCommand { get; set; }

If you set this property to true and don’t use the CommandParameter property, the method firing the command will actually pass the captured event to the model. How this works, is pretty simple to see in EventToBoundCommandBehavior:

private void FireCommand(RoutedEventArgs routedEventArgs)
{
  if (Command != null && Command.CanExecute(CommandParameter))
  {
    if (PassEventArgsToCommand && CommandParameter == null)
    {
      Command.Execute(routedEventArgs);
    }
    else
    {
      Command.Execute(CommandParameter);
    }
  }
}

Red shows the additions. Usage of course is pretty simple:

<TextBlock Text="TextBlock" FontSize="48">
  <WinRtBehaviors:Interaction.Behaviors>
    <Behaviors:EventToBoundCommandBehavior Event="Tapped" 
      Command="{Binding TestCommand}" 
      PassEventArgsToCommand="true"/>
  </WinRtBehaviors:Interaction.Behaviors>
</TextBlock>

And then you have to define a command TestCommand like this in your model:

public ICommand TestCommand
{
  get
  {
    return new RelayCommand<TappedRoutedEventArgs>(
      (p) =>
        {
           Debug.WriteLine(p.PointerDeviceType);
        });
  }
}

This will write '”Mouse”, “Touch” or “Pen” in your output window, depending on what you use to tap. Of course this is not a very useful application of this technique, but it proves the point. If you don’t use PassEventArgsToCommand both behaviors will work as before.

Now as an architect I am not too fond of this technique, because it introduces user-interface related objects into the view model – I get a bit restless when I see something like “using Windows.UI.Xaml.Input” on top of a view model class. Be careful when you use this. On the other hand, a holier-than-thou attitude ain’t gonna help getting Window 8 apps shipped and so if this will help people, I am more than fine with that.;-)

Scott tells me this code is derived from Laurent Bugnion’s original code – I did not check, but I am going to take his word for it. At the time of this writing it’s part of Win8nl 1.0.6 and already available as Nuget package. Now I only have the problem that not every line of code comes from the Netherlands, so maybe I should indeed rename this package to Win8eu ;-)

As (almost) always, a demo solution can be found here

Reactive Extensions in Windows Phone 8 and the 2001 submission error

noreply@blogger.com (Joost van Schaik) — Sat, 17 Nov 2012 04:39:00 PST

You can read the whole story if you like reading, but this whole blog post comes down to one piece of advice:

If you value your sanity, do not, under any circumstances, pull in Reactive Extensions from NuGet into a Windows Phone 8 application. Use the built-in Microsoft.Phone.Reactive.dll instead.

Those who follow me on twitter may have seen a few tweets pass by over problems I had with the Windows Phone 8 version of my app Map Mania. The submission went OK the first time, but the test team found two bugs – bugs that were also there in previous versions, but apparently they have ramped up the quality bar again. I can only applaud that, even if I got bitten by it myself, because the test report was comprehensive and showed someone actually understood or had read into some issues that may arise when using WMS services – and by doing so, succeeded in crashing my app.

Anyway, I fixed the app, resubmitted, and then the trouble started. Although the Store Test kit showed no errors, and submission went fine showing only validated XAP’s – after a few minutes I got an e-mail from the Windows Phone dev center:

Windows Phone Dev Center app submission

We weren't able to process the app submission for Map Mania.
Unfortunately, something happened with your Windows Phone app submission. Check the status of the submission in your app list at https://dev.windowsphone.com/applicationlist. If the problem persists, contact support for assistance.

When I looked at the submission it said I had a “2001 error” with a helpful link, that leads you to a table in which it says:

There are duplicate files in AppManifest.xaml. Remove one of the files and then try again.
If rebuilding your XAP doesn't solve this problem, you may have to manually remove any duplicate files from the AppManifest.xaml in your XAP file. To rebuild your app, see Rebuilding your project in Visual Studio.

My friends, I have rebuilt the app till my fingers bled, cleaned the solution, then removed all the binaries manually, to no avail. Then I opened up the XAP to look for duplicate assemblies – there weren’t any duplicates; I scanned the AppManifest.xaml till I saw cross-eyed and didn’t find any duplicate entries there either - and after the 10th or so submit followed by automatic mail error within five minutes I gave up and indeed contacted Support.

I won’t go into full detail, but I think it’s fair to say this problem wasn’t easy to solve and Support struggled as much with it as I did. Quite some mails went back and forth, and the 9 hour time zone difference didn’t exactly work favorably for a quick resolve. It wasn’t until our Dutch DPE Matthijs Hoekstra, who I think now owe not only my sanity but possibly also my soul ;-), queried his sources and got back that a post-processing error apparently was being caused by System.Reactive.Core.dll and I was recommended to use Microsoft.Phone.Reactive.dll instead if possible.

I finally had a possible smoking gun - my own port of the #wp7nl library pulls in Reactive extensions from Nuget. So I removed the dependency from the library package, made a new local build, installed that into the app, compiled, uploaded and submitted, waiting for the inevitable dreaded 2001 error mail to pop up. Over an hour later, the only mail I got was from outlook.com reminding me of a birthday and the app status at the moment of this writing says “Status: In signing stage". Hallelujah!

Now I don’t understand why submission went OK the first time and not the second time around. But I am very glad the issue is resolved. If you use my library, please remove the references it makes to the external reactive stuff manually or wait for me to publish the version that will do without. It will be out soon, I can tell you that.

Update: #wp7nl was updated within a few hours of this post. If you use the Windows Phone 8 version, please update to 3.0.1. Should you experience problems with missing assemblies, make a manual reference to Microsoft.Phone.Reactive.dll to the projects that use wp7nl. And please remove any reference to Rx* should they linger along.

A WinRT behavior to mimic EventToCommand (take 2)

noreply@blogger.com (Joost van Schaik) — Wed, 14 Nov 2012 01:13:00 PST

(Updated with sample code January 19 2013)

Some time ago I posted a WinRT behavior to mimic EventToCommand. This behavior cunningly looked for the command name in the DataContext, but it occurred to me (and some blog post commenters as well) that it actually might be more logical skip all that skullduggery and let the developer bind to a command in stead of letting her/him provide its name as string and then go look for it.

Anyway, not wanting to break compatibility I added a new behavior to my win8nl library on CodePlex, very originally called EventToBoundCommandBehavior.

It’s working is very similar to the original EventToCommandBehavior. There are two notable differences:

The Command property is now no longer of type string but ICommand
The FireCommand method is now very simple:

private void FireCommand()
{
  if (Command != null && Command.CanExecute(CommandParameter))
  {
    Command.Execute(CommandParameter);
  }
}

Which goes to show that you can be too clever.

If you want to replace the original behavior for the new one – say, you used it like this

<TextBlock Text="TextBlock" FontSize="48">
  <WinRtBehaviors:Interaction.Behaviors>
    <Behaviors:EventToCommandBehavior Event="Tapped" 
      Command="TestCommand" 
      CommandParameter="{Binding TestProperty, Mode=TwoWay}"/>
  </WinRtBehaviors:Interaction.Behaviors>
</TextBlock>

Just go to the places marked red/underlined:

<TextBlock Text="TextBlock" FontSize="48">
  <WinRtBehaviors:Interaction.Behaviors>
    <Behaviors:EventToBoundCommandBehavior Event="Tapped" 
      Command="{Binding TestCommand}" 
      CommandParameter="{Binding TestProperty, Mode=TwoWay}"/>
  </WinRtBehaviors:Interaction.Behaviors>
</TextBlock>

Those who want to see the full source code of the new (and largely simplified) behavior can do so at http://win8nl.codeplex.com/SourceControl/changeset/view/20896#395786

Update: I’ve added some more sample code as a lot of people seem to struggle with the correct use of this behavior. Lots of time I get program problems like this: “I have a list in my view model and a command yet my command is not fired when then I tap the item”. The view model usually contains these properties:

public ObservableCollection Phones { get; set; }

public ICommand TappedCommand
{
  // code omitted
}

and the XAML is like this:

<Grid Background="{StaticResource ApplicationPageBackgroundThemeBrush}" 
  DataContext="{StaticResource DemoViewModel}">

  <GridView ItemsSource="{Binding Phones}" SelectionMode="None" 
     IsTapEnabled="True">
    <GridView.ItemTemplate>
      <DataTemplate>
        <Grid Width="350">
          <Grid.ColumnDefinitions>
            <ColumnDefinition/>
            <ColumnDefinition/>
          </Grid.ColumnDefinitions>
          <WinRtBehaviors:Interaction.Behaviors>
            <Behaviors:EventToBoundCommandBehavior 
              Command="{Binding TappedCommand}" 
              CommandParameter="{Binding}" Event="Tapped" />
          </WinRtBehaviors:Interaction.Behaviors>

          <TextBlock Text="{Binding Brand}"/>
          <TextBlock Text="{Binding Type}" Grid.Column="1"/>
        </Grid>
      </DataTemplate>
    </GridView.ItemTemplate>
  </GridView>
</Grid>

I this case, the programmer has lost track of what’s the exact data context. Happens all the time, even to me. I’ve used colors to depict the data context changes.

In the black code, DemoViewModel is the data context
In the red code, the ObserservableCollection Phones is the data context
In the blue code, a single Phone is the context.

So what this code tries to do is to call a command TappedCommand on class Phone in stead of DemoViewModel.So either the command needs to be in “Phone”, or the behavior’s binding must be updated like this:

<WinRtBehaviors:Interaction.Behaviors>
  <Behaviors:EventToBoundCommandBehavior 
    Command="{Binding TappedCommand, Source={StaticResource DemoViewModel}}" 
    CommandParameter="{Binding}" Event="Tapped" />
</WinRtBehaviors:Interaction.Behaviors>

Full working example can be found here.

Data binding shapes to the new Windows Phone 8 Map control (and more)

noreply@blogger.com (Joost van Schaik) — Tue, 30 Oct 2012 11:25:00 PDT

A little history

When I accepted the invitation from MADNbe to talk about Maps and MVVM on September 20 early in the summer (or what was supposed to be the summer) of 2012 the actual release date for the Windows Phone SDK 8.0 was still a mystery. As it gradually became clear the SDK would not be available at the date my talk was scheduled, I devised a plan B and in stead talked about Windows Phone 7 mapping and how to port this code and knowledge to Windows 8. I also wrote a blog post I wrote about it. Now the funny thing is - the Windows Phone 8 mapping control and the Windows 8 Bing Maps control show some remarkable similarities. So if you read this article and think “Huh? I’ve read this before” that’s entirely possible!

So world in general, and Belgium in particular, meet the new Hello World, Windows Phone 8 style!

Windows Phone 7 map binding recap

Not going to happen - I am not going to repeat myself for the sake of content ;-). In the the Windows 8 article I give a short recap of how you can bind to a Windows Phone 7 map, using templates. I’d suggest you read that if you haven’t done so already ;-). By the way, the sample solution contained with this project is mostly the same as the sample Windows Phone 7 application I use in my talk. I upgraded to Windows Phone but did not even bother to change the libraries I used. (like MVVMLight, Phone7.Fx or my own wp7nl library). That’s still Windows Phone 7 code and you call that code from Windows Phone 8 without any problem. Very soon I hope to publish updates for the libraries specific to the platform, and you will see them appearing in your NuGet package manager. The only thing you have to keep in mind is that the app no longer runs in quirks mode once you upgraded to Windows Phone 8. That means – if your library code does something funky that has a different behavior under Windows Phone 8, the platform is not going to help you keep that funky behavior - unlike when you run a (real) Windows Phone 7 app on it.

Data binding and the new map control

Without cheering overly loud for ‘my’ home team, I actually think the Windows Phone mapping team actually has done a better job on this part than their Windows 8 brethren. That’s actually not so very hard, as the Windows 8 Bing Maps control does not support data binding at all. The Windows Phone 8 control actually (still) supports the binding of Center and ZoomLevel, as well as the new properties CartographicMode, LandMarksEnabled, Heading and Pitch, – “Heading” being the direction of the top of the map, default 0, being North – and Pitch the viewing angle of the map (normally zero, or ‘straight from above’). And probably some more I haven’t used yet.

But as far as drawing shapes on the maps are concerned, we are in the same boat as in Windows 8:

The shapes the control draws cannot be templated. They are apparently just projections of something native (as is the map itself).
There are only two kinds of shapes: MapPolygon and MapPolyline, both descending from MapElement (as opposed to MapShape in Windows 8), which in turn descends from DependencyObject – so I can use the same trick again – storing data in attached dependency properties.

To solve this, I use the same approach as I did in Windows 8: apply behaviors. Only that’s a lot easier now because unlike Windows 8, Windows Phone 8 supports behaviors out of the box.

Introducing MapShapeDrawBehavior for Windows Phone 8

This behavior is, just like it’s Windows 8 brother, called MapShapeDrawBehavior. It’s use is quite similar:

<Maps:Map x:Name="map" CartographicMode="Road">
  <i:Interaction.Behaviors>
    <MapBinding:MapShapeDrawBehavior LayerName="Roadblocks" 
       ItemsSource="{Binding RoadBlocks}" 
       PathPropertyName="Geometry">
      <MapBinding:MapShapeDrawBehavior.EventToCommandMappers>
        <MapBinding:EventToCommandMapper EventName="Tap" 
                                         CommandName="SelectCommand"/>
      </MapBinding:MapShapeDrawBehavior.EventToCommandMappers>
      <MapBinding:MapShapeDrawBehavior.ShapeDrawer>
        <MapBinding:MapPolylineDrawer Color="Green" Width="10"/>
      </MapBinding:MapShapeDrawBehavior.ShapeDrawer>
    </MapBinding:MapShapeDrawBehavior>
  </i:Interaction.Behaviors>
</Maps:Map>

The only difference, in fact, with the Windows 8 behavior is that there is not a TapCommand property but an EventMapper collection. That is because unlike the Windows 8 map shapes, Windows Phone 8 shapes don’t support events at all. These are events of the map. There aren’t any layers for shapes too – there is just a MapElements collection that you can add shapes to.

So for every category of objects you define a behavior; in this case the road blocks (the green line on the app sceenshot above). This translates conceptually to a ‘layer’. Then you need to define three things per layer:

Which property in the item view model contains the Path – this is the terminology for a MapElement collection of points. This is of type GeoCoordinateCollection.
A drawer. A drawer is a concept I made up myself. It’s a class that creates a shape from a collection of points contained in a GeoCoordinateCollection. It’s my way to make something that’s not templatable more or less configurable and the idea behind is exactly the same as for Windows 8.
What command in the item view model (in this case, a RoadBlockViewModel) must be called when a GestureEvent is called on the map. This can be either Tap or DoubleTap. You do this by adding an EventToCommandMapper to the EventToCommandMappers list.

This behavior comes, just like it’s Windows 8 brother, the three out-of-the box standard drawers: MapPolylineDrawer, MapPolygonDrawer, and MapStarDrawer. The last one draws a configurable star shaped polygon around a point – since map shapes cannot be points by themselves. A drawer needs only to implement one method:

public override MapElement CreateShape(object viewModel, LocationCollection path)

The basic drawers don’t do anything with the view model: they just take the settings from XAML. You can write your own if you want for instance return a shape of a different color based upon view model values. Thematic mapping again, just like I said last time.

If you just want to use the behavior, download the sample solution, rip the Wp8nl.Contrib project from it and use it. It just needs a reference to System.Windows.Interactivity.dll, that’s about all.

Some technical details

As the inner workings of the behavior are almost identical to that of their Windows 8 counterparts, I am not going to recap everything again. The trick is the same: view models and layer names are stored in and retrieved from attached dependency properties that are attached to the shapes themselves - the behavior uses this how to hold view models and map shapes together, and which shape belongs to which layer. For the technically interested I will stress a few small points. First of all, I already said the map elements themselves don’t have any events. Therefore, I have to attach events to the map, using the “AddEventMappings” method that’s loaded when the behavior’s OnLoad is called:

private void AddEventMappings()
{
  foreach (var mapper in EventToCommandMappers)
  {
    var evt = AssociatedObject.GetType().GetRuntimeEvent(mapper.EventName);
    if (evt != null)
    {
      AddEventMapping(mapper);
    }
  }
}

private void AddEventMapping(EventToCommandMapper mapper)
{
  Observable.FromEvent<GestureEventArgs>(AssociatedObject, mapper.EventName)
    .Subscribe(se =>
     {
       var gestureArgs = se.EventArgs;
       if (gestureArgs != null)
       {
         var shape = 
            AssociatedObject.GetMapElementsAt(
               gestureArgs.GetPosition(AssociatedObject)).FirstOrDefault(
                 p => MapElementProperties.GetLayerName(p)==LayerName);
         if (shape != null)
         {
           FireViewmodelCommand(
             MapElementProperties.GetViewModel(shape), mapper.CommandName);
         }
       }
     });
}

So this works fundamentally different from it’s Windows 8 counterpart: not the shapes respond to events, but the map does so, and reports the shapes found at a location of the tap or the doubletap. The shapes in question can be retrieved using the map’s GetMapElementsAt method. And then I select the first shape I find that has the same layer name in it’s LayerName attached dependency property as the behavior. Note this filter is necessary: the map reports the shapes and it reports all of them - since there is no real layer structure the map has no notion of which behavior put the shape on the map. And you don’t want every behavior reporting all other shapes that happen to be on the same location as well – that would result in double events. But if the behavior finds a hit, it calls the FireViewModelCommand, which is essentially the same as in Windows 8, and it shows the window with alphanumeric info. That part has not been changed at all.

The rest of the behavior is mainly concerned with adding, removing and replacing shapes again. I would suggest you’d study that if you are interested in how to respond to the various events of an ObservableCollection. To prove that data binding actually works, you can open the menu and select “change dhl building”. That’s the most eastward building on the map. If you choose that, you will actually see the building change shape. The only thing the TestChangedShapeCommand command - that’s called when you hit that menu item – does, it change a building’s geometry property. The image on the map is updated automatically.

Some concluding observations

Somewhere down in the guts of Windows Phone 8 there’s a native control, and I very much think both it and it’s Bing Maps control for Windows 8 counterpart are of the same breed. Both have similar, yet subtly different projections to managed code. As I already mentioned – in Windows 8 the shapes descend from MapShape, in Windows Phone 8 from MapElement. In addition, Windows Phone Map Elements support StrokeColor, StrokeThickness and StrokeDash – no such thing on Windows 8 - one more cheer for the Windows Phone team ;). But neither are supporting complex shapes and things like donuts (polygons with holes in it). These are the hallmarks of the real heavy duty GIS systems like the stuff Cadcorp. ESRI et al are making.

Also important when sharing code is to note the following:

In Windows Phone 7, we made shapes from a LocationCollection, which is a collection of GeoCoordinate
In Windows Phone 8, shapes are created from a GeoCoordinateCollection, which is a collection of GeoCoordinate
In Windows 8, shapes are created from a LocationCollection which is a collection of Location.

So both platforms refactored the Locations and their collection, and both in opposite ways. This can be solved by using converters or a generic subclass specific for both platforms but I leave things like that as exercise for the reader. The fun thing is: once again it shows that a lot of code can be reused as long as you keep application and business logic in models and view models – that way, you only have to deal with user interface and platform considerations, but your basic app structure stays intact. Once more: three cheers for MVVM.

And as usual you can download the sample solution. I will shortly add this stuff to the Windows Phone 8 specific version of the wp7nl library on CodePlex

Happy mapping on Windows Phone 8!

Introducing the new Windows Phone 8 Map control

noreply@blogger.com (Joost van Schaik) — Tue, 30 Oct 2012 11:04:00 PDT

The time is finally there: the Windows Phone SDK 8.0 is out, and now we can finally talk about all the great news things for developers that this new SDK brings, and I’ll start that right now. And I don’t think it will surprise anyone who knows me that the first thing I did was looking at the much-rumored new maps control.

I was not disappointed. In general, just two words: super slick. The very embodiment of fast and fluid. What Windows Phone 8 brings to the mapping table made by geo hart skip and is nothing short of dramatic. Think the Nokia drive map on your Windows Phone 7. On steroids. As a control. For you to use in your apps. With downloadable maps for use offline. I have seen it run on actual hardware and for me as a GIS buff, used to the fact that maps stuff usually take a lot of processing power and doesn’t necessary always go super fast, this was a serious nerdgasm. So I created a little app to show off the very basics of this map control. It allows you to select the various map modes, as well to to select map heading and pitch. Heading is the direction the top of the map is pointing – in Bing Maps this was always “North”, and Pitch is how you are looking on the map. If that’s 0, you are looking straight from above.

Now the important the thing about Windows Phone 8 is that the team really went out of their way to make sure code is backwards compatible. That means that not only the new maps control is in the framework, but also Ye Olde Bing Maps control. This can lead to some confusing situations. The important thing to remember when working with the new map control is

The (old) Bing Maps control stuff is in namespace Microsoft.Phone.Controls.Maps
The new map control stuff in in namespace Microsoft.Phone.Maps.Controls.

So “Controls” and “Maps” are swapped. I always keep in mind “maps first” as a mnemonic to remember which namespace to use. Especially when you are using ReSharper or a tool like it that most helpfully offers you to add namespaces and references (again) can really get you caught on the wrong foot, so pay attention.

I started out creating a “New Windows Phone App”, selected OS 8.0 (of course), fired up the Library Package Manager and downloaded my wp7nl library. This gives MVVMLight and some other stuff I need for my sample. At the moment of this writing this is still Windows Phone 7 code but this will run fine (of course this all will be updated shortly). The only thing you need to take care of is that you delete the references to Windows Phone Controls.dll and Windows Phone Controls.Maps.dll the package makes.

First step is to make a simple view model describing the cartographic modes the new map control supports:

using GalaSoft.MvvmLight;
using Microsoft.Phone.Maps.Controls;

namespace MvvmMapDemo1.ViewModels
{
  public class MapMode : ViewModelBase
  {
    private string name;
    public string Name
    {
      get { return name; }
      set
      {
        if (name != value)
        {
          name = value;
          RaisePropertyChanged(() => Name);
        }
      }
    }

    private MapCartographicMode cartographicMode;
    public MapCartographicMode CartographicMode
    {
      get { return cartographicMode; }
      set
      {
        if (cartographicMode != value)
        {
          cartographicMode = value;
          RaisePropertyChanged(() => CartographicMode);
        }
      }
    }
  }
}

The main view is basically some properties and a little bit of logic. First part handles the setup and the properties for displaying and selecting the cartographic map modes:

using System;
using System.Collections.ObjectModel;
using System.Device.Location;
using GalaSoft.MvvmLight;
using Microsoft.Phone.Maps.Controls;

namespace MvvmMapDemo1.ViewModels
{
  public class MapViewModel : ViewModelBase
  {
    public MapViewModel()
    {
      modes = new ObservableCollection<MapMode>
      {
        new MapMode 
          {CartographicMode = MapCartographicMode.Road, Name = "Road"},
        new MapMode 
          {CartographicMode = MapCartographicMode.Aerial, Name = "Aerial"},
        new MapMode 
         {CartographicMode = MapCartographicMode.Hybrid, Name = "Hybrid"},
        new MapMode
         {CartographicMode = MapCartographicMode.Terrain, Name = "Terrain"}
      };
      selectedMode = modes[0];
    }
    
    private MapMode selectedMode;
    public MapMode SelectedMode
    {
      get { return selectedMode; }
      set
      {
        if (selectedMode != value)
        {
          selectedMode = value;
          RaisePropertyChanged(() => SelectedMode);
        }
      }
    }

    private ObservableCollection<MapMode> modes;
    public ObservableCollection<MapMode> Modes
    {
      get { return modes; }
      set
      {
        if (modes != value)
        {
          modes = value;
          RaisePropertyChanged(() => Modes);
        }
      }
    }
  }
}

The only important part about this is that there must be an initially selected mode, as the control does not take it very well if the mode is forcibly set to null by the data binding.

At little bit more interesting are the next two properties of the view model, which control heading and pitch:

private double pitch;
public double Pitch
{
  get { return pitch; }
  set
  {
    if (Math.Abs(pitch - value) > 0.05)
    {
      pitch = value;
      RaisePropertyChanged(() => Pitch);
    }
  }
}

private double heading;
public double Heading
{
  get { return heading; }
  set
  {
    if (value > 180) value -= 360;
    if (value < -180) value += 360;
    if (Math.Abs(heading - value) > 0.05)
    {
      heading = value;
      RaisePropertyChanged(() => Heading);
    }
  }
}

The map seems to try to keep its heading between 0 and 360 degrees, but I like to have the slider in the middle for North position – that way you can use it to rotate the map left and right. So I want heading to be between –180 and +180, which should be functionally equivalent to between 0 and 360 - and apparently I get away with it. Since both values are doubles I don’t do the standard equals but use a threshold value to fire a PropertyChanged. Courtesy of ReSharper suggesting this.

Then there’s a MapCenter property, that doesn’t do very much in this solution apart from setting the initial map center. I have discovered that the center map does not like being set to null either – this beasty is a bit more picky than the Bing Maps control it seems so I take care to set an initial value:

private GeoCoordinate mapCenter = new GeoCoordinate(40.712923, -74.013292);
/// 
/// Stores the map center
/// 
public GeoCoordinate MapCenter
{
  get { return mapCenter; }
  set
  {
    if (mapCenter != value)
    {
      mapCenter = value;
      RaisePropertyChanged(() => MapCenter);
    }
  }
}
private double zoomLevel = 15;

public double ZoomLevel
{
  get { return zoomLevel; }
  set
  {
    if (zoomLevel != value)
    {
      zoomLevel = value;
      RaisePropertyChanged(() => ZoomLevel);
    }
  }
}

Together with the initial ZoomLevel set to 15, this will give you a nice view of Manhattan Island, New York City, USA. There's also a boolean property "Landmarks" that will enable or disable landmarks - you can look that up in the sources if you like.

Then I opened up Blend, plonked in a map, two sliders, a checkbox on the screen, did some fiddling with grids and stuff, and deleted a lot of auto-generated comments. That made me end up with quite a bit of XAML. I won’t show it all verbatim, but the most important thing is the map itself:

<maps:Map x:Name="map" 
          CartographicMode="{Binding SelectedMode.CartographicMode,Mode=TwoWay}"
          LandmarksEnabled="{Binding Landmarks,Mode=TwoWay}"
          Pitch="{Binding Pitch, Mode=TwoWay}"
          Heading="{Binding Heading, Mode=TwoWay}" 
          Center="{Binding MapCenter, Mode=TwoWay}"
          ZoomLevel="{Binding ZoomLevel, Mode=TwoWay}"
          Grid.ColumnSpan="2"/>

Does not look like exactly rocket science, right? It is not, as long as you make sure the maps namespace is declared as:

xmlns:maps="clr-namespace:Microsoft.Phone.Maps.Controls;assembly=Microsoft.Phone.Maps"

The horizontal slider, controlling the heading, is defined as follows:

<Slider Minimum ="-180" Maximum="180" Value="{Binding Heading, Mode=TwoWay}"/>

The vertical slider, controlling the pitch, looks like this:

<Slider Minimum="0" Maximum="75" Value="{Binding Pitch, Mode=TwoWay}" />

Sue me, I took the easy way out and declared the valid ranges in XAML in stead of in my (view) model. But the point of the latter is this: apparently you can only supply ranges between 0 and 75 for pitch. And the pitch is only effective from about level 7 and higher. If you zoom out further, the map just become orthogonal (i.e. viewed straight from above, as if the pitch is 0). This is actually animated if you zoom out using pinch zoom, a very nice visual effect.

Finally, the list picker controlling which kind of map you see, and the checkbox indicating if the map should show landmarks or not

<toolkit:ListPicker ItemsSource="{Binding Modes}" 
                    SelectedItem="{Binding SelectedMode, Mode=TwoWay}" 
                    DisplayMemberPath="Name"/>
<CheckBox Content="Landmarks" IsChecked="{Binding Landmarks, Mode=TwoWay}"/>

… only I haven’t been able to find any landmarks, not in my hometown Amersfoort, not Berlin nor New York so I suppose this is something that’s not implemented yet ;-)

If you fire up this application you will get an immediate error message indicating that you have asked for the map but that you have not selected the right capability for this in the manifest. So double click on “Properties/WMAppManifest.xml” and select ID_CAP_MAP (yeah, the manifest’s got a nice editor too now), and fire up your app.

And that’s all there is to your first spin with the new Windows Phone map control. It supports data binding – to an extent, and it’s easy to control and embed. Play with the sliders and scroll over the map – it’s amazingly fast and I can assure you it is even more so on actual hardware. Stay tuned: more is coming on this subject!

Note: I have not touched upon creating and adding map keys to the map in this solution. This procedure is described here.

As usual: download the sample solution here.

A WinRT behavior to start a storyboard on an event

noreply@blogger.com (Joost van Schaik) — Wed, 03 Oct 2012 05:36:00 PDT

Sometimes I get a bit distracted. In this article I mention a behavior that I wrote which starts a storyboard on an event, I even put in in the win8nl library – and then totally forget to blog about it, or even to announce it. So anyway, when Danny van Neyghem asked me about a problem that was almost solved by my behavior, I kinda remembered it, and that I totally forgot about it - and decided a) to improve it and b) to talk about it (well, write).

World, meet StartStoryboardBehavior. It’s a very simple behavior that has the following properties:

Storyboard	The name of the Storyboard to start. Mandatory.
StartImmediately	true = don’t wait for an event to start, just start the storyboard when the behavior is loaded. Optional; default is false
EventName	The event of the AttachedObject that will initiate the start of the storyboard (e.g. ‘Click’ on a button). Ignored when StartImmediately == true, mandatory otherwise
SearchTopDown	Optional, default is true. If true, the behavior will start to search for your storyboard from the top of the visual tree. This is the scenario in which for instance clicking a button will initiate a storyboard that sits somewhere in the top of the page. If this value is set to false, the behavior will search from the attached object up. Choose this setting when you use the behavior to start a storyboard that’s sitting inside a template.

“SearchTopDown” was added just yet, and I hope it solves Danny’s problem. For those who just want to use the behavior: Nuget Win8nl and you have the behavior armed and ready. I’ve updated the package with the improved behavior already. For those who want to learn – well, it’s not rocket science but read on.

The first part is not so very interesting – just your basic setting up of the behavior, the wiring up and a wiring down of the events. The only interesting things happen in AssociatedObjectLoaded:

using System;
using System.Linq;
using Windows.UI.Xaml;
using WinRtBehaviors;
using System.Reflection;
using Win8nl.External;
using Windows.UI.Xaml.Media.Animation;
using System.Reactive.Linq;

namespace Win8nl.Behaviors
{
  public class StartStoryboardBehavior : Behavior<FrameworkElement>
  {
    protected override void OnAttached()
    {
      base.OnAttached();
      AssociatedObject.Loaded += AssociatedObjectLoaded;
    }
    
    protected override void OnDetaching()
    {
      AssociatedObject.Loaded -= AssociatedObjectLoaded;
      base.OnDetaching();
    }

    private void AssociatedObjectLoaded(object sender, RoutedEventArgs e)
    {
      if (StartImmediately)
      {
        StartStoryboard();
      }

      if (!string.IsNullOrWhiteSpace(EventName))
      {
        var evt = AssociatedObject.GetType().GetRuntimeEvent(EventName);
        if (evt != null)
        {
          Observable.FromEventPattern<RoutedEventArgs>(AssociatedObject, EventName)
            .Subscribe(se => StartStoryboard());
        }
      }
    }
  }
}

If StartImmediately is true, the storyboard is fired immediately. If not, the behavior tries to find an event with the name supplied in the EventName property and tries to attach a dynamic handler to it using Rx. Nothing new here, I already described this technique earlier - in the article where I announced this forgotten behavior :-)

More interesting is this funny little method, that’s basically one big Linq statement:

private Storyboard GetStoryBoardInVisualDescendents(FrameworkElement f)
{
  return f.GetVisualDescendents()
    .Where(p => p.Resources.ContainsKey(Storyboard) && p.Resources[Storyboard] is Storyboard)
    .Select(p => p.Resources[Storyboard] as Storyboard).FirstOrDefault();
}

It checks in all visual children’s resources for a storyboard with the name supplied in “Storyboard”, and if so, it selects it. It uses the extension method GetVisualDescendents to generate a list of all the children – all the way to the bottom of the visual tree from the element in “f”.

As for the behavior’s default behavior (meh), it searches top-down for the storyboard, using this method:

private void StartStoryboardTopDown()
{
  var root = AssociatedObject.GetVisualAncestors().Last() ?? AssociatedObject;

  var storyboard = GetStoryBoardInVisualDescendents(root);
  if (storyboard != null)
  {
    storyboard.Begin();
  }
}

In a nutshell: find the very last top object in the visual tree – that is the root. If that’s null, apparently the current associated object already is the root. Then it starts to search downward for the storyboard and if it finds it, it will fire it.

For the bottom-up strategy, another method is employed, with a very original name:

private void StartStoryboardBottomUp()
{
  var root = AssociatedObject;
  Storyboard storyboard;
  do
  {
    storyboard = GetStoryBoardInVisualDescendents(root);
    if (storyboard == null)
    {
      root = root.GetVisualParent();
    }
  } while (root != null && storyboard == null);

  if (storyboard != null)
  {
    storyboard.Begin();
  }
}

This method starts by trying to find the storyboard in the visual tree below the current associated object. If it doesn’t find it, in moves one level up and tries again. And another one. Till it a) finds the storyboard or b) runs out of levels. If a storyboard is found, then it fires it. Okay, so that’s a little inefficient, but it only happens upon firing the event.

The final pieces of the puzzle is StartStoryboard, which simply selects the method based upon the SearchTopDown value.

private void StartStoryboard()
{
  if( SearchTopDown)
  {
    StartStoryboardTopDown();
  }
  else
  {
    StartStoryboardBottomUp();
  }
}

And that’s all there is to it. I’ve omitted the declaration of the four (attached dependency) properties as that only bulks up this post with no actual value, and the complete listing can be found here on CodePlex if that helps you to get overview.

For those who love to see the behavior in action I created a little sample app, which shows a few items in a ListBox. At the end of each row there’s a button, and if you click that the color of three texts to the left is animated from black to red in about a second. That’s a storyboard being fired by the behavior. Very exiting ;-) - but it proves the point.

Enjoy! I hope this helps you with your Windows 8 development! Global Availability is coming, get cracking to get your stuff in the store!

Repairing the Windows Phone 7 behavior to show an image background for a search string

noreply@blogger.com (Joost van Schaik) — Sun, 30 Sep 2012 10:25:00 PDT

On the last day of 2011 ago I made DynamicBackgroundBehavior - a quite bizarre behavior which plays a supporting role in my latest Windows Phone application “What’s cooking”. It basically shows a picture from a search string as a background, using Bing Image search. Quite neat. Until Microsoft decided to change the Bing Search API a bit. Up until then, it had been a free unlimited ride – since about August you have to buy a package of searches (anything below 5000 searches per month is free). And some more stuff has been changed.

Microsoft provides a nice little C# client library that should solve all of this using an OData protocol. The sad thing is that for the life of it I could not get it to compile on Windows Phone. So I ended up analyzing the PHP (*shudder*) sample in this document – a Word document no less – to see what I needed to do (see page 27 and further).

From a coding perspective, the following details have been changed:

The actual location of the API has been changed from http://api.bing.net/xml.aspx to https://api.datamarket.azure.com/Data.ashx/Bing/Search/v1/Image
The schema of the MediaUrl element where the actual image in is returned moved from name space http://schemas.microsoft.com/LiveSearch/2008/04/XML/multimedia to name space http://schemas.microsoft.com/ado/2007/08/dataservices
It uses an account key in stead of an App id.
The App Id must be send base 64 encoded in the header of the request in stead of in the url as plain text.

Okay. My cheese moved a little. First things first. I need base64 encoded text. Samples of this are on the internet a dime a dozen, I took this one:

/// <summary>
/// Converts string to base64
/// </summary>
/// <param name="data"></param>
/// <returns></returns>
private string Base64Encode(string data)
{
  try
  {
    var encData_byte = new byte[data.Length];
    encData_byte = System.Text.Encoding.UTF8.GetBytes(data);
    return Convert.ToBase64String(encData_byte);
  }
  catch (Exception e)
  {
    throw new Exception("Error in Base64Encode" + e.Message);
  }
}

Now the method that does the actual calling of the Bing Search API has changed a little, but not very much:

/// <summary>
/// Start the image request using Bing Serach
/// </summary>
/// <param name="searchString"></param>
protected void StartGetFirstImage(string searchString)
{
  if (!string.IsNullOrWhiteSpace(searchString))
  {
    var queryUri =
      string.Format(
        "https://api.datamarket.azure.com/Data.ashx/Bing/Search/v1/Image?Query=%27{0}%27&$top=1&$format=Atom",
         HttpUtility.UrlEncode(searchString));
    var request = WebRequest.Create(queryUri) as HttpWebRequest;
    request.Headers["Authorization"] = "Basic " + Base64Encode(string.Format("{0}:{0}", BingSearchKey));
    
    var response =
      Observable.FromAsyncPattern<WebResponse>(
        request.BeginGetResponse, request.EndGetResponse)();
    response.Subscribe(WebClientOpenReadCompleted, WebClientOpenReadError);
  }
}

Note the new url. It goes to a different location, the search term must be enclosed by %27 (i.e. the double quote “) and I have to specify a format (Atom). Really interesting is the thing I marked red, for a variety of reasons:

Windows Phone’s Response.Headers collection does not sport the Add method. That stopped me a little, until I realized you could poke directly a new key in the collection by using [“Autorization”] =.
Now the authentication is Basic, followed by a space, your account key, colon, your key again and that key:key sequence needs to base 64 encoded. Why this is implemented this way – no idea, but it gets your key across – and validated.

The final thing is that in the callback WebClientOpenReadCompleted I need to use “http://schemas.microsoft.com/ado/2007/08/dataservices” for a namespace,as I already stated.

And then my little Windows Phone behavior works again. The fixed version can be downloaded here. I will fix my #wp7nl library on codeplex ASAP.

Data binding shapes to the WinRT Bing Maps control – coming from Windows Phone

noreply@blogger.com (Joost van Schaik) — Wed, 26 Sep 2012 06:15:00 PDT

Disclaimer: this is not a 101 article. It requires understanding of the basic idea about MVVM, data binding, the MVVMLight messenger, and the use of behavior in Windows 8 XAML.

Updated for RTM Bing Maps Control October 3 2012

Introduction
Let me get this straight: I don’t want you to wean off Windows Phone development – far from it. It’s value proposition is great, and it will become much greater still. This article is yet another way to show you how to carry over code and architecture principles between Microsoft’s great tile based operating systems. It’s all about re-using skills and code. C# and XAML code that is.

Those who have attended my talks about this subject during this year, have seen the application to the right popping up. Basically it generates shapes (be it points, lines or polygons) by data binding from ‘business objects’ - using MVVMLight view models. If you tap any of those shapes, a “SelectCommand” on the bound view model will be fired, and the view model will put itself on the MVVMLight Messenger. Some other view model will listen for those messages, and pop up the info window. The app shows gas stations (points), roadblocks (lines) and buildings (shapes). Don’t go look for the gas stations, they are not there and the fuel prices a way bit behind the (expensive) times, the roadblock are all but one fictional as well. Only the buildings are real – location wise that is. Sources of the original Windows Phone (7) application can be found here:

Windows Phone map binding recap
A quick recap: if you want to data bind to a Bing Maps control in Windows Phone, you will go about like this – first, you would define a data template for a layer:

<DataTemplate x:Key="RoadBlockViewModelTemplate">
  <Microsoft_Phone_Controls_Maps:MapPolyline Locations="{Binding Geometry}"
                         Stroke="#FF71FF00"
                         StrokeThickness="5">
    <i:Interaction.Triggers>
      <i:EventTrigger EventName="Tap">
        <GalaSoft_MvvmLight_Command:EventToCommand 
             Command="{Binding SelectCommand}" />
      </i:EventTrigger>
    </i:Interaction.Triggers>
  </Microsoft_Phone_Controls_Maps:MapPolyline>
</DataTemplate>

This would be able to make a line geometry from a viewmodel containing a “Geometry” attribute containing a LocationCollection object, and an ICommand “SelectCommand” that is executed when the user taps the line. Second, you would make a Bing Maps control, and define a layer like this.

<Microsoft_Phone_Controls_Maps:Map x:Name="map"
    CredentialsProvider="Your-credentials-here">
  <Microsoft_Phone_Controls_Maps:MapLayer 
     x:Name="MapLayer_RoadBlocks">
    <Microsoft_Phone_Controls_Maps:MapItemsControl 
      ItemsSource="{Binding RoadBlocks}" 
      ItemTemplate="{StaticResource RoadBlockViewModelTemplate}"/>
  </Microsoft_Phone_Controls_Maps:MapLayer>
</Microsoft_Phone_Controls_Maps:Map>;

The roadblock view model would look like this:

using System.Windows.Input;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;
using GalaSoft.MvvmLight.Messaging;
using Microsoft.Phone.Controls.Maps;
using MvvmMaps.Logic.Models.GeoObjects;
using MvvmMaps.Logic.Models.Geometries;
using Wp7nl.Utilities;

namespace MvvmMaps.Logic.ViewModels
{
  public class RoadBlockViewModel : ViewModelBase
  {
    public RoadBlock Model { get; set; }

    // Some code omitted

    [DoNotSerialize]
    public LocationCollection Geometry
    {
      get
      {
        var modelGeom = Model.Location as LineGeometry;
        return modelGeom.GetLocationCollection();
      }

      set
      {
        var modelGeom = Model.Location as LineGeometry;
        modelGeom.SetLocationCollection(value);
      }
    }

    [DoNotSerialize]
    public ICommand SelectCommand
    {
      get
      {
        return new RelayCommand(
            () => Messenger.Default.Send(this),
            () => true);
      }
    }
  }
}

Basically it comes down to a Geometry view model property that converts a business object geometry to and from something the Bing Maps control understands – a LocationCollection. This is a named collection that contains objects of type GeoCoordinate – your basic Lat/Lon container. As said above, when you tap select the MVVMLight Messenger just sets off the selected viewmodel, and ‘something’ should capture that message and handle it.

Going to Windows 8 – challenges
Now let’s re-use our skills on Windows 8. Simply put – in its current state, the data binding support for the Bing Maps SDK for Windows Store apps is pretty easy to describe with one word – non-existent. Some developers immediately go into the ‘blame-and-flame-the-Microsoft-dev-team’ mode when they encounter things like this. I think ‘CodePlex library’. I always see things like this as an intellectual challenge, a chance to contribute to the community, and fortunately there are more people thinking that way. My very smart fellow Dutch developer community member Dave Smits has created BindableRTMaps, which is very useful for binding point objects – but its shape support is a bit limited. Being a GIS professional and an MVVMLight junkie, I want the control to be able to generate geographical elements directly from view models, just like I was able to do in Windows Phone. I solved the data binding issue for shapes using a Behavior based upon my WinRtBehaviors library. Not quite surprising for those who know me.

The result can be seen below:

In the center, next to the river, the Vicrea offices, where I work. Say cheese fellows! ;-) As you can see, the shapes are beautifully re-projected when Birds’ Eye View is selected. This is the stuff that makes a GIS buff tick.

Researching the control I quickly found the following:

There’s no data binding support at all (as stated)
The shapes the control draws cannot be templated. They are apparently just projections of something native (as is the map itself).
There are only two kinds of shapes: MapPolygon and MapPolyline, both descending from MapShape, which in turn descends from DependencyObject – which is very fortunate, as I hope will become clear over the course of this article.

So I had the challenge to create something that can be put into XAML to still give the designer an amount of control how things appear, without having to resort to code.

Introducing MapShapeDrawBehavior
The behavior I created is called MapShapeDrawBehavior (I’ve never been one for original catchy names) and can be used like this:

<Maps:Map Credentials="Your-credentials-here">
  <WinRtBehaviors:Interaction.Behaviors>
  
    <MapBinding:MapShapeDrawBehavior 
       LayerName="Roadblocks" 
       ItemsSource="{Binding RoadBlocks, Mode=TwoWay}" 
       TapCommand="SelectCommand" PathPropertyName="Geometry" >
         <MapBinding:MapShapeDrawBehavior.ShapeDrawer>
           <MapBinding:MapPolylineDrawer Color="Green" Width="10"/>
         </MapBinding:MapShapeDrawBehavior.ShapeDrawer>
    </MapBinding:MapShapeDrawBehavior>
  
  </WinRtBehaviors:Interaction.Behaviors>
</Maps:Map>

For every category of objects there’s a layer – which translates to one behavior per list of objects, in this case the road blocks (the green line on the app sceenshot above). Then you need to define three things per layer:

What command in the item view model (in this case, a RoadBlockViewModel) must be fired when a MapShape’s only event – Tap – is called.
Which property in the item view model contains the Path – this is the terminology for a MapShape’s collection of points. This is, once again, of type LocationCollection. Only that’s no longer a collection of GeoCoordinate but of Location.
Finally, you need to define a drawer. A drawer is a concept I sucked from my own thumb – it determines how a collection of points is supposed to be transformed to something on the map. It’s my way to make something that’s not templatable more or less configurable.

I created three drawers out of the box: MapPolylineDrawer, MapPolygonDrawer, and MapStarDrawer. The last one draws a configurable star shaped polygon around a point – since map shapes cannot be points by themselves. A drawer needs only to implement one method:

public override MapShape CreateShape(object viewModel, LocationCollection path)

The basic drawers don’t do anything with the view model: they just take the settings from XAML. But if you want for instance your shapes having different colors based upon some view model property – say you want to color urban areas based upon their crime rate (what we GIS buffs call a thematic map) – you can write a little custom drawer.

If you just want to use the behavior you are done with reading. You can download the demo solution with code (which, incidentally, shows off a lot of more things than just binding to a map) and start playing around with it. Be aware of the following issues/caveats:

You will need to install the Bing Maps SDK for Windows Store apps first
When I moved the solution from my Big Black Box to my slate I had to delete and redo all references to Bing.Maps and “Bing Maps for C#, C++, or Visual Basic” (this was using the Beta, I don’t know if that still applies to the RTM version)
The control apparently contains native code, so you cannot build it for Any CPU.
The designer only works when you build for x86 (this still the case in RTM)

For the technically interested I will continue with some gory details.

The inner guts
The behavior itself is actually pretty big, so I won’t repeat all code verbatim; I will concentrate on the interesting parts.

First of all, I already mentioned the fact MapShape descends from DependencyObject. That spells ‘Ahoy, Attached Dependency Property ahead!’ to me. So I created two of those, one holding the name of the layer (I use those to find out which shapes belong to a single layer) and one in which I store the view model from which the shape was created:

using Windows.UI.Xaml;

namespace Win8nl.MapBinding
{
  public static class MapElementProperties
  {
    public static readonly DependencyProperty ViewModelProperty =
         DependencyProperty.RegisterAttached("ViewModel",
         typeof(object),
         typeof(MapElementProperties),
         new PropertyMetadata(default(object)));

    // Called when Property is retrieved
    public static object GetViewModel(DependencyObject obj)
    {
      return obj.GetValue(ViewModelProperty) as object;
    }

    // Called when Property is set
    public static void SetViewModel(
       DependencyObject obj,
       object value)
    {
      obj.SetValue(ViewModelProperty, value);
    }

    public static readonly DependencyProperty LayerNameProperty =
         DependencyProperty.RegisterAttached("LayerName",
         typeof(string),
         typeof(MapElementProperties),
         new PropertyMetadata(default(string)));

    // Called when Property is retrieved
    public static string GetLayerName(DependencyObject obj)
    {
      return obj.GetValue(LayerNameProperty) as string;
    }

    // Called when Property is set
    public static void SetLayerName(
       DependencyObject obj,
       string value)
    {
      obj.SetValue(LayerNameProperty, value);
    }
  }
}

The core of the MapShapeDrawBehavior self consists out of just five little methods, and the VERY core method is CreateShape. The behavior iterates over the object list databound to ItemsSource, and calls CreateShape for every view model:

/// <summary>
/// Creates a new shape
/// </summary>
/// <param name="viewModel"></param>
/// <returns></returns>
private MapShape CreateShape(object viewModel)
{
  var path = GetPathValue(viewModel);
  if (path != null && path.Any())
  {
    var newShape = CreateDrawable(viewModel, path);
    newShape.Tapped += ShapeTapped;

    MapElementProperties.SetViewModel(newShape, viewModel);
    MapElementProperties.SetLayerName(newShape, LayerName);

    // Listen to property changed event of geometry property to check 
    // if the shape needs tobe redrawed
    var evt = viewModel.GetType().GetRuntimeEvent("PropertyChanged");
    if (evt != null)
    {
      Observable
        .FromEventPattern<PropertyChangedEventArgs>(viewModel, "PropertyChanged")
        .Subscribe(se =>
                     {
                       if (se.EventArgs.PropertyName == PathPropertyName)
                       {
                         ReplaceShape(se.Sender);
                       }
                     });
    }
    return newShape;
  }
  return null;
}

First, it reads the view model property that holds the geometry (or at least, it tries that)
It creates the actual shape
It attaches an event listener to the “Tapped” event
It puts the view model and the layer name in attached dependency properties for said shape
Finally it attaches a property changed listener so that when the property that’s holding the view model’s geometry changes, the ReplaceShape method is called (which replaces the shape on the map – duh)

GetPathValue is a simple method that retrieves the view model’s geometry using reflection. Nothing special there:

private LocationCollection GetPathValue(object viewModel)
{
  if (viewModel != null)
  {
    var dcType = viewModel.GetType();

    var methodInfo = dcType.GetRuntimeMethod("get_" + PathPropertyName, 
                     new Type[0]);
    if (methodInfo != null)
    {
      return methodInfo.Invoke(viewModel, null) as LocationCollection;
    }
  }
  return null;
}

CreateDrawable – well that’s VERY simple. Get the drawer and let it decide how the shape will look

protected virtual MapShape CreateDrawable(object viewModel, LocationCollection path )
{
  var newShape = ShapeDrawer.CreateShape(viewModel, path);
  return newShape;
}

And finally ShapeTapped and FireViewModelCommand:

private void ShapeTapped(object sender, TappedRoutedEventArgs e)
{
  var shape = sender as MapShape;
  if( shape != null )
  {
    var viewModel = MapElementProperties.GetViewModel(shape);
    if( viewModel != null )
    {
      FireViewmodelCommand(viewModel, TapCommand);
    }
  }
}

private void FireViewmodelCommand(object viewModel, string commandName)
{
  if (viewModel != null && !string.IsNullOrWhiteSpace(commandName))
  {
    var dcType = viewModel.GetType();
    var commandGetter = dcType.GetRuntimeMethod("get_" + commandName, new Type[0]);
    if (commandGetter != null)
    {
      var command = commandGetter.Invoke(viewModel, null) as ICommand;
      if (command != null)
      {
        command.Execute(viewModel);
      }
    }
  }
}

ShapeTapped checks if it the object sending the event is actually a shape, then tries to retrieve a view model from the attached dependency property, and calls FireViewModelCommand on it. Which basically is directly ripped from my earlier EventToCommandBehavior. And then the circle is round again – user taps, view model command is called (just as Laurent Bugnion’s EventToCommand trigger did for Windows Phone) and the view model takes it further just like before.

There’s more to this behavior, but mostly it’s just reacting to events that occur when the ObservableCollection ItemsSource changes.

Some concluding remarks
Of course this behavior was geared to make the code I already had as much reusable as possible, but I think the way WinRT XAML apps and Windows Phone apps can be put together are remarkably similar – provided you make good use of MVVM and keep your code as clean as possible. So what did I have to do to move over my business and view model code to get this working? Well not very much, actually.

A tiny thing in my model library because I was so clever to use a BackgroundWorker somewhere in my models – which is not supported in WinRt
The Gas station view model was changed to do the conversion form business object geometry to Bing Maps’ Location in stead of the converter I originally - because my solution does not support converters.
I had to change some name spaces and data types. Mainly GeoCoordinate was now called Location.
Oh yeah – in stead of "clr-namespace" I had to use "using" for declaring namespaces in XAML. I used ReSharper toalt-enter trough the errors and add the namespaces almost automatically.

And that was about it. Of course, the code in it was quite trivial, but still. On the XAML side things were a bit more complicated:

Converters and Attached Dependency Properties were carried over with minimal changes.
I had to trash my geometry templates and had to write the behavior to emulate the templates – in a way, which admittedly was no small feat. But that’s a hole that only needs to be plugged once, and can now act as a base for possible better solutions.
I had to do some fiddling around with the DataTemplateSelector – that works a wee bit different, and will be subject of a future blog post.
‘Tombstoning’ works a bit differently, but quite analogous. Been there, done that, wrote the blogpost.
The App Bar on Windows 8 has a lot more possibilities. And – thank Saint Sinofsky and his minions – it supports data binding out of the box. Moving from Windows Phone app bars to Windows 8 app bars is quite easy. Provided you used the BindableApplicationbar and MVVM of course ;-)
I kinda 1:1 copied the data window (the popup with alphanumeric data that appears when you tap a shape) – that worked remarkably well, but you might want to do something about the styling for a real-world application. The data window is a wee bit small now and does fit in styling wise ;-)

This is still a work in progress, but I think for basic shape data binding this is already very usable. The Bing Maps control is very fast, courtesy of native code, no doubt. I hope this will help people.

Once again, for those who don’t feel scrolling all the way up: the source code. Also updated for RTM. Enjoy!

A WinRT behavior to turn a FlipView into a kind of Windows 8 Panorama

noreply@blogger.com (Joost van Schaik) — Fri, 10 Aug 2012 13:50:00 PDT

(UPDATED for RTM August 18 2012)
One of the most beautiful controls of Windows Phone is the Panorama. It’s ideal for showing a lot related content on a small screen and enable the user to easily pan trough it. A visual cue for ‘there is more’ is provided by showing a little part of the next panel to the very right of the current data. A typical example is showed right.

It’s also one of the most abused controls (guilty as charged Your Honor), but still I wanted to port Catch’em Birds to Windows 8 – and I found out there was no ready-to-use control. After fighting with ScrollViewers and GridViewers and whatnot I came to this very simple behavior, which basically takes a FlipView and hammers it into a kind of Panorama.

Now the FlipView is designed to be a full-screen control so the behavior basically walks past all the items in the FlipView, shrinks them horizontally by a configurable percentage of the screen, and displaces the ‘next’ panel a little to the left (making it appear at the right side of the screen on the current panel). To make this look a little bit more fast and fluid, I have made the displacement itself animated, so that the ‘next’ screen not so much snaps as glides into view. The overall effect looks pretty nice to me. I hope Microsoft will think so as well, as my app is up for an App Excellence Lab soon ;-)

In my app it looks like this. I still lack a decent screen recorder for Windows 8, so I took out the video camera

So this behavior, most originally called “FlipViewPanoramaBehavior” is of course based upon my earlier WinRtBehaviors CodePlex project. It starts out like this, with the following dependency properties:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Win8nl.External;
using Win8nl.Utilities;
using WinRtBehaviors;
using Windows.Foundation;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Media;
using Windows.UI.Xaml.Media.Animation;

namespace Win8nl.Behaviors
{
  /// <summary>
  /// A behavior to turn a FlipView into a kind of panorama
  /// </summary>
  public class FlipViewPanoramaBehavior : Behavior<FlipView>
  {
    #region AnimationTime

    /// <summary>
    /// AnimationTime Property name
    /// </summary>
    public const string AnimationTimePropertyName = "AnimationTime";

    public int AnimationTime
    {
      get { return (int)GetValue(AnimationTimeProperty); }
      set { SetValue(AnimationTimeProperty, value); }
    }

    /// <summary>
    /// AnimationTime Property definition
    /// </summary>
    public static readonly DependencyProperty AnimationTimeProperty = 
      DependencyProperty.Register(
        AnimationTimePropertyName,
        typeof(int),
        typeof(FlipViewPanoramaBehavior),
        new PropertyMetadata(250));

    #endregion

    #region NextPanelScreenPercentage

    /// <summary>
    /// NextPanelScreenPercentage Property name
    /// </summary>
    public const string NextPanelScreenPercentagePropertyName = 
      "NextPanelScreenPercentage";

    public double NextPanelScreenPercentage
    {
      get { return (double)GetValue(NextPanelScreenPercentageProperty); }
      set { SetValue(NextPanelScreenPercentageProperty, value); }
    }

    /// <summary>
    /// NextPanelScreenPercentage Property definition
    /// </summary>
    public static readonly DependencyProperty NextPanelScreenPercentageProperty = 
      DependencyProperty.Register(
        NextPanelScreenPercentagePropertyName,
        typeof(double),
        typeof(FlipViewPanoramaBehavior),
        new PropertyMetadata(10.0));
    #endregion
  }
}

So “AnimationTime” is the number of milliseconds the behavior takes to glide the next panel into view, and NextPanelScreenPercentage is an indication of how much screen real estate the next panel will take. Nothing special here yet.

If I want to muck around with a FlipView contents, I first have to find these contents. With some breakpoints and watches I found out I could use the following code to find the FlipViewItems:

/// <summary>
/// Find all Flip view items
/// </summary>
/// <returns></returns>
private List<FlipViewItem> GetFlipViewItems()
{
  var grid = AssociatedObject.GetVisualChildren().FirstOrDefault();
  if (grid != null)
  {
    return grid.GetVisualDescendents().OfType<FlipViewItem>().ToList();
  }
  return null;
}

Attentive readers might observe that neither GetVisualChildren nor GetVisualDescendents are part of the WinRT api, which is perfectly correct – they come from the VisualTreeHelperExtensions I ported from Windows Phone some time ago. Don’t start to download this stuff and build it together yourself – wait till the end and I will show the lazy way to do this.

Anyway – I wanted to move the FlipView’s contents fluently. That means I will use some Storyboards to work on Translations. So we identify the contents of each FlipViewItem and set its fist visual child’s Rendertransform to CompositeTransform, if that’s not already present:

/// <summary>
/// At compositions transforms to every item within every flip view item
/// </summary>
private void AddTranslates()
{
  var items = GetFlipViewItems();
  if (items != null && items.Count > 1)
  {
    foreach (var item in items)
    {
      var firstChild = item.GetVisualChild(0);
      if (!(firstChild.RenderTransform is CompositeTransform))
      {
        firstChild.RenderTransform = new CompositeTransform();
        firstChild.RenderTransformOrigin = new Point(0.5, 0.5);
      }
    }
  }
}

This assumes every FlipViewItem contains just one child. You better make sure it does for this to work, so put a Grid around it if you need more than one thing to sit in there.

Now the core of the whole behavior is this one piece of code:

/// <summary>
/// Does the actual repositioning and sizing of the items displayed in the Flipview
/// </summary>
private void SizePosFlipViewItems()
{
  AddTranslates(); // <-- moved from AssociatedObjectLoaded for RTM
  var size = AssociatedObject.ActualWidth*(NextPanelScreenPercentage/100);
  var shift = size - 15;

  var items = GetFlipViewItems();
  if (items != null && items.Count > 1)
  {
    // Make all items a bit smaller and make sure they are aligned left
    foreach (var item in items)
    {
      item.GetVisualChild(0).HorizontalAlignment = HorizontalAlignment.Left;
      item.GetVisualChild(0).Width = items[0].ActualWidth - size;
    }

    var selectedIndex = AssociatedObject.SelectedIndex;

    if (selectedIndex > 0)
    {
      StartTranslateStoryBoard(0, 0, 
                               items[selectedIndex - 1].GetVisualChild(0), 0);
    }

    StartTranslateStoryBoard(0, 0, items[selectedIndex].GetVisualChild(0), 
                             AnimationTime);

    if (selectedIndex + 1 < items.Count)
    {
      StartTranslateStoryBoard(-shift, 0,
                                items[selectedIndex + 1].GetVisualChild(0), 
                                AnimationTime);
    }
  }
}

First it calculates the new size of the FlipViewItems, and then it calculates how much it can shift the ‘next panel’ – basically, how much room is there between this panel and the next. This is currently a hard coded number, but feel free to make that a property as well ;-).

Then, for every FlipViewItem it makes the first visual child “size” smaller, and makes sure it’s aligned to the left (so space comes free and the right side). Then:

It moves the panel that just disappeared to the left (if any) back to it’s normal position, in no time (i.e. not animated – it’s invisible to the leftanyway, so why bother).
It moves the current panel to its normal position, but it animates it. This is because if it’s moved in from the left, it moves a bit too far, as you might have noticed in the movie – so it glides back
It moves the next panel (if any) a little bit to the left – animated, so it glides into view on the right hand side of the screen.

Now of course there is the slight matter of the method that make the storyboards to make it happen:

private static void StartTranslateStoryBoard(double desiredX, double desiredY, 
                                             FrameworkElement fe, int time)
{
  var translatePoint = fe.GetTranslatePoint();
  var destinationPoint = new Point(desiredX, desiredY);
  if (destinationPoint.DistanceFrom(translatePoint) > 1)
  {
    var storyboard = new Storyboard { FillBehavior = FillBehavior.HoldEnd };
    storyboard.AddTranslationAnimation(
         fe, translatePoint, destinationPoint,
         new Duration(TimeSpan.FromMilliseconds(time)),
         new CubicEase { EasingMode = EasingMode.EaseOut });
    storyboard.Begin();
  }
}

Once again, I use some extension methods from code ported from Windows Phone in the article I mentioned before, I underlined them to make them distinguishable from the standard API. Basically: this method accepts a FrameworkElement and moves it to a desired position in a desired time, using a storyboard that animates a translation. That is to say, unless it is already in that desired position. I think I will make this into a separate extension method in a utilities library one day but for the moment it’s doing fine.

All that’s left now is some wiring up, I cobbled that all together in one code block:

protected override void OnAttached()
{
  AssociatedObject.Loaded += AssociatedObjectLoaded;
  base.OnAttached();
}
protected override void OnDetaching()
{
  AssociatedObject.Loaded -= AssociatedObjectLoaded;
  AssociatedObject.SelectionChanged -= AssociatedObjectSelectionChanged;
  AssociatedObject.SizeChanged -= AssociatedObjectSizeChanged;
}

private void AssociatedObjectLoaded(object sender, RoutedEventArgs e)
{
  //AddTranslates(); deleted for RTM
  SizePosFlipViewItems();
  AssociatedObject.SelectionChanged += AssociatedObjectSelectionChanged;
  AssociatedObject.SizeChanged += AssociatedObjectSizeChanged;
}

private async void AssociatedObjectSelectionChanged(object sender, 
                                                    SelectionChangedEventArgs e)
{
  await Task.Delay(250); // Updated after bug report from SCPRedMage
  SizePosFlipViewItems();
}

private async void AssociatedObjectSizeChanged(object sender, 
                                               SizeChangedEventArgs e)
{
  await Task.Delay(250);
  SizePosFlipViewItems();
}

OnAttached and OnDetaching do their usual basic wiring and unwiring of events.
When the AssociatedObject (i.e. the FlipView) is first loaded the FlipViewItems’ first child gets their CompositeTransforms, then the initial screen layout is created by calling SizePosFlipViewItems. Then two events are wired up:

SelectionChanged
SizeChanged

Now the first one is logical – when the user selects the next panel (i.e. he scrolls it in from the left or right) the panels need to be arrange again so that the newly selected panel stays in view (it scrolls too much to the right, remember) and the ‘new’ next panel comes into view at the left hand side of the screen.

The SizeChanged intercept is necessary for when the user rotates his screen or snaps the application. For then the size of the screen changes, and the portion of the screen that the next panel may use is considerably smaller – in pixels. In my app this is taken care of by a Visual State Manager that listens to page events – basically something stolen from the LayoutAwarePage that’s in every template project – but that takes a while. Now I know I am going to be lambasted for this (and I have a pretty good idea by whom), but to solve this the SizeChanged handler waits a bit for actually calling SizePosFlipViewItems. And to prevent UI blocking I interestingly abused Task.Delay for that. It’s crude, but it works. As you may have seen in the movie when I snapped the app.

So there you have it. The code works, you have seen it in action. Its usage is ridicilously simple: make a FlipView, add items, and add this behavior to the FlipView. Done. You can download the the behavior here but you will need quite some base libs to get it working – as it uses a lot of my win8nl library on CodePlex. If you want to go the easy and quick way: just use the Win8nl NuGet package. That will get you the behavior and all the prerequisites, including MVVMLight.

Be aware that win8nl now uses the Reactive extensions. They are included in the NuGet package and they will come with it as a dependency

UPDATE: Please note there is a tiny code change since original publication: due to Microsoft optimizing the FlipView not all elements are initially loaded, so the check if every FlipViewItem child has a CompositeTransform has to performed at every manipulation.

UPDATE 2: There's a tiny update to AssociatedObjectSelectionChanged. And those who want a simple working sample, download the sources from codeplex and fire up FlipViewTest.XAML as the start page.