A Windows Phone 7 multi touch pan/zoom behaviour for Multi Scale Images

Some may have read my foray into using Windows Phone 7 to view maps, utilizing a Multi Scale Image (msi), MVVM Light and some extension properties. This application works quite well, but being mainly a study in applied architecture, the user experience leaves much to be desired. Studying Laurent Bugnion’s Multi Touch Behaviour got me on the right track. Although Laurent’s behaviour is very good, it basically works by translating, resizing (and optionally rotating) the control(s) inside the FrameworkElement is is attached to. For various reasons this is not an ideal solution for a map viewer.

So I set out to make my own behaviour, the first one I ever made by the way, and it turned out to remarkably easy – less than 90 lines of code, including whitespace and comments:

using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Interactivity;

namespace LocalJoost.Behaviours
{
  /// <summary>
  /// A behaviour for zooming and panning around on a MultiScaleImage
  /// using manipulation events
  /// </summary>
  public class PanZoomBehaviour : Behavior<MultiScaleImage>
  {
    /// <summary>
    /// Initialize the behavior
    /// </summary>
    protected override void OnAttached()
    {
      base.OnAttached();
      AssociatedObject.ManipulationStarted += AssociatedObject_ManipulationStarted;
      AssociatedObject.ManipulationDelta += AssociatedObject_ManipulationDelta;
    }
    /// <summary>
    /// Shortcut for the Multiscale image
    /// </summary>
    public MultiScaleImage Msi { get { return AssociatedObject; } }

    /// <summary>
    /// Screen point where the manipulation started
    /// </summary>
    private Point ManipulationOrigin { get; set; }

    /// <summary>
    /// Multiscale view point origin on the moment the manipulation started
    /// </summary>
    private Point MsiOrigin { get; set; }

    void AssociatedObject_ManipulationStarted(object sender,
                                              ManipulationStartedEventArgs e)
    {
      // Save the current manipulation origin and MSI view point origin
      MsiOrigin = new Point(Msi.ViewportOrigin.X, Msi.ViewportOrigin.Y);
      ManipulationOrigin = e.ManipulationOrigin;
    }

    void AssociatedObject_ManipulationDelta(object sender, ManipulationDeltaEventArgs e)
    {      
      if (e.DeltaManipulation.Scale.X == 0 && e.DeltaManipulation.Scale.Y == 0)
      {
        // No scaling took place (i.e. no multi touch)
        // 'Simply' calculate a new view point origin
        Msi.ViewportOrigin =
          new Point
            {
              X = MsiOrigin.X - (e.CumulativeManipulation.Translation.X / 
                Msi.ActualWidth * Msi.ViewportWidth),
              Y = MsiOrigin.Y - (e.CumulativeManipulation.Translation.Y / 
                Msi.ActualHeight * Msi.ViewportWidth),
            };
      }
      else
      {
        // Multi touch - choose to interpretet this either as zoom or pinch
        var zoomscale = (e.DeltaManipulation.Scale.X + e.DeltaManipulation.Scale.Y) / 2;

        // Calculate a new 'logical point' - the MSI has its own 'coordinate system'
        var logicalPoint = Msi.ElementToLogicalPoint(
          new Point
            { X = ManipulationOrigin.X - e.CumulativeManipulation.Translation.X,
              Y = ManipulationOrigin.Y - e.CumulativeManipulation.Translation.Y }
          );
         Msi.ZoomAboutLogicalPoint(zoomscale, logicalPoint.X, logicalPoint.Y);
        if (Msi.ViewportWidth > 1) Msi.ViewportWidth = 1;
      }
    }
    
    /// <summary>
    /// Occurs when detaching the behavior
    /// </summary>
    protected override void OnDetaching()
    {
      AssociatedObject.ManipulationStarted -= AssociatedObject_ManipulationStarted;
      AssociatedObject.ManipulationDelta -= AssociatedObject_ManipulationDelta;
      base.OnDetaching();
    }
  }
}

Method AssociatedObject_ManipulationStarted just records where the user started the manipulation, as well as what the MSI ViewportOrigin was on that moment. Method AssociatedObject_ManipulationDelta then simply checks if the delta event sports a scaling in x or y direction – if it does, it calculates the properties for a new ‘logical point’ to be fed into the ZoomAboutLogicalPoint method of the MultiScaleImage. If there is no scaling, the user just panned, and a new ViewportOrigin is being calculated in the MSI’s own coordinate system which runs from 0,0 to 1,1. And that’s all there is to it.

If you download my sample mapviewer application it’s actually quite simple to test drive this

• Add a Windows Phone 7 class library LocalJoost.Behaviours to the projects
• Reference this project from WP7viewer
• Create the behaviour described above
• Open MainPage.xaml in WP7Viewer
• Find the MultiScaleImage called “msi” and remove all bindings except MapTileSource, so that only this remains:

<MultiScaleImage x:Name="msi" 
   MapMvvm:BindingHelpers.MapTileSource="{Binding CurrentTileSource.TileSource}">
</MultiScaleImage>

• Add the behaviour to the MultiScaleImage using Blend or follow the manual procedure below:
• Declare the namespace and the assembly in the phone:PhoneApplicationPage tag like this

xmlns:LJBehaviours="clr-namespace:LocalJoost.Behaviours;assembly=LocalJoost.Behaviours"

• Add the behaviour to the MSI like this

<MultiScaleImage x:Name="msi" 
   MapMvvm:BindingHelpers.MapTileSource="{Binding CurrentTileSource.TileSource}">
  <i:Interaction.Behaviors>
      <LJBehaviours:PanZoomBehaviour/>
  </i:Interaction.Behaviors>
</MultiScaleImage>

And there you go. You can now zoom in and out using two or more fingers. That is, if you have a touch screen. If you don’t have a touch screen and you were not deemed important enough to be assigned a preview Windows Phone 7 device then you are in good company, for neither have I, and neither was I ;-). But fortunately there is Multi Touch Vista on CodePlex. It needs two mice (or more, but I don’t see how you can operate those), and it’s a bit cumbersome to set up, but at least I was able to test things properly. So, don’t let the lack of hardware deter you getting on the Windows Phone 7 bandwagon!

What I learned from this: behaviours will give an interesting twist to design decisions. When is it proper to solve things into behaviours, and when in a model by binding? For me, it’s clear that in this case the behaviour wins from the model – it’s far easier to make, understand and – above all – apply! For now, just drag and drop the behaviour on top of a MultiScaleImage and bang – zoom and pan. No complex binding expressions. 

Incidentally, although this behaviour was created with maps in mind, in can be applied to any MultiScaleImage of course, showing ‘ordinary’ image data.

For those who are not very fond of typing: the sample map application with the behaviour  already added and configured can be downloaded here. For those lucky b******s in possession of a real live device: you will find the XAP here. I would very much appreciate feedback on how the thing works in real life.

Fixing CLSA property registration issues in child objects

AKA ‘avoiding the dreaded “Can not register property YourProperty after containing type (YourBaseType) has been instantiated” error message’

Somewhere between CSLA 3.0 en 3.6 a new way of registering properties has become into being:

// old skool CSLA
private string _oldProp = string.Empty;
public string OldProp
{
  get
  {return _oldProp;}	 
  set
  { if (value == null) value = string.Empty;
    if (!_oldProp.Equals(value))
    {
      _oldProp = value;
      PropertyHasChanged("OldProp");
    }
  }
}

//new skool CSLA
private static PropertyInfo NewPropProperty = 
  RegisterProperty(c => c.NewProp);
public string NewProp
{
	get { return GetProperty(NewPropProperty); }
	set { SetProperty(NewPropProperty, value); }
}

In CSLA 4.0 the last style is mandatory, so I started upgrading some objects (while currently using CSLA 3.8.3) in anticipation. So I upgraded my base object

using Csla;

namespace CslaInheritance
{
  public abstract class MyBaseClass : BusinessBase<MyBaseClass>
  {

    protected static PropertyInfo<string> MyProp1Property = 
        RegisterProperty<string>(c => c.MyProp1);
    public string MyProp1
    {
      get { return GetProperty(MyProp1Property); }
      set { SetProperty(MyProp1Property, value); }
    }

    protected static PropertyInfo<string> MyProp2Property = 
        RegisterProperty<string>(c => c.MyProp2);
    public string MyProp2
    {
      get { return GetProperty(MyProp2Property); }
      set { SetProperty(MyProp2Property, value); }
    }
  }
}

and then my child object

using Csla;

namespace CslaInheritance
{
  public abstract class MyConcreteClass1 : MyBaseClass
  {
    protected static PropertyInfo<string> ConcreteProp1Property = 
      RegisterProperty<string>(c => c.ConcreteProp1);
    public string ConcreteProp1
    {
      get { return GetProperty(ConcreteProp1Property); }
      set { SetProperty(ConcreteProp1Property, value); }
    }

    protected static PropertyInfo<string> ConcreteProp2Property =
      RegisterProperty<string>(c => c.ConcreteProp2);
    public string ConcreteProp2
    {
      get { return GetProperty(ConcreteProp2Property); }
      set { SetProperty(ConcreteProp2Property, value); }
    }
  }
}

And then I noticed something odd: according to the compiler, ConcreteProp1 and ConcreteProp2 were not defined. Even worse is the situation when you choose to upgrade your properties not using lambda expressions, but PropertyInfo objects, like this:

    protected static PropertyInfo<string> ConcreteProp3Property =
      new PropertyInfo<string>("ConcreteProp3Property");
    public string ConcreteProp3
    {
        get { return GetProperty(ConcreteProp3Property); }
        set { SetProperty(ConcreteProp3Property, value); }
    }

because this will compile - and run. Until you create a second child class MyConcreteClass2, instantiate it, then instantiate a MyConcreteClass1 – and then you will get a cryptical runtime error message saying “Can not register property ConcreteProp1Property after containing type MyBaseClass has been instantiated”.

Fortunately the CSLA framework comes with sources, and after some rooting around I found the culprit, if you can call it that, in Csla.BusinessBase:

protected static PropertyInfo<P> 
  RegisterProperty<P>(Expression<Func<T, object>> propertyLambdaExpression)
{
  PropertyInfo reflectedPropertyInfo = 
    Reflect<T>.GetProperty(propertyLambdaExpression);

  return RegisterProperty(Csla.Core.FieldManager.PropertyInfoFactory.Factory.Create<P>(
    typeof(T), reflectedPropertyInfo.Name));
}

Although MyConcreteClass1 inherits from MyBaseClass, MyBaseClass inherits in turn from templated class BusinessBase<MyBaseClass>. Therefore, in RegisterProperty called from MyConcreteClass1 T is still MyBaseClass. It does not matter that I actually called it from a child class. So what happens is that all the statics are defined in the base class MyBaseClass. If you are using the lambda variant to register, the compiler saves your *ss, but if you use the PropertyInfo method something weird happens. Remember, statics in a class are initialized as soon as you touch any one of statics. So what happens is: you instantiate your concrete child class, immediately the statics of both the concrete and the base class are initialized, and all the properties are registered in the base class. If you try to instantiate a second concrete child class, Csla finds that your base class properties are already initialized, and the dreaded “Can not register property ConcreteProp1Property after containing type MyBaseClass has been instantiated” error message appears.

Now you can of course change the way you implement classes. I might make MyBaseClass generic as well, then T changes along. But when upgrading an existing API out of a situation in which direct inheritance used to be perfectly legal, it’s a different story.

There are actually two ways out of this. The first one is: use PropertyInfo, but explicitly name the object type to which the property belongs

protected static PropertyInfo<string> ConcreteProp3Property =
  RegisterProperty(typeof(MyConcreteClass1), 
  new PropertyInfo<string>("ConcreteProp3Property"));
public string ConcreteProp3
{
    get { return GetProperty(ConcreteProp3Property); }
    set { SetProperty(ConcreteProp3Property, value); }
}

This works, but I like the solution below better, because that uses lambda expressions again and so your friend the compiler ;-) can help you catch typo’s. The only way I see to realize that is to add a static method at the bottom of your class

private static PropertyInfo<T> RegisterPropertyLocal<T>(
  Expression<Func<MyConcreteClass1, object>> propertyLambdaExpression)
{
  var reflectedPropertyInfo = 
  Reflect<MyConcreteClass1>.GetProperty(propertyLambdaExpression);
  return RegisterProperty(typeof(MyConcreteClass1),
    Csla.Core.FieldManager.PropertyInfoFactory.Factory.Create<T>(
    typeof(MyConcreteClass1),
    reflectedPropertyInfo.Name);
}

and then register your properties like this from now on:

protected static PropertyInfo<string> ConcreteProp1Property = 
  RegisterPropertyLocal<string>(c => c.ConcreteProp1);
public string ConcreteProp1
{
  get { return GetProperty(ConcreteProp1Property); }
  set { SetProperty(ConcreteProp1Property, value); }
}

The drawback of this solution is, of course, that you have to define a static RegisterPropertyLocal in every inherited class you define. But at least you will be saved from typos and weird runtime errors.

Now you are ready to upgrade, but I would recommend recording some macros to do the actual syntax change, unless you are very fond of very dull repetitive typing jobs ;-)