My colleague Developer Evangelist, Sam Stokes, in California has written a compelling article on dragging items in Windows Phone.

But I have a problem with Sam’s approach

Maybe\r\n it’s because I have a problem with Sam – but probably not; he’s \r\nactually one of my top 90,000 people @ Microsoft. So, let’s talk about \r\nmoving things in XAML!

Sam moves objects around by incrementing and decrementing an item’s top/left dependency property inside a Canvas.

Like this:

In\r\n the code above, Sam is using the ManipuationDelta event. This awesome \r\nevent allows an individual UI element to track the movement of finger \r\ngestures on it. It simplifies the typical events that have to handle and\r\n track.

MSDN:\r\n The ManipulationDelta event occurs multiple times when the user drags \r\nfingers over the screen during a manipulation and again when inertia \r\noccurs. You can use the IsInertial property to check whether the event is occurring during inertia.

The\r\n element on with ManipulationDelta event occurs is not affected in any \r\nway when the event occurs. You must provide the logic to the element \r\nthat is to be manipulated. The CumulativeManipulation and DeltaManipulation properties, which are of type ManipulationDelta,\r\n contain data about how the position of the manipulations change and \r\ninterpreted as moving, resizing, or rotating an object. You apply that \r\ninformation to the element that is to be manipulated.

But\r\n there’s more to that code. Sam might be using the coolest event, but \r\nhow is he relocating the ellipse? He’s incrementing and decrementing the\r\n Canvas.Top and Left dependency properties. When he does this, the \r\nellipse appears to move and track the finger on the touch panel.

What’s the problem?

The\r\n problem is deep. And I have to start by saying that Sam’s approach is \r\nnot necessarily wrong. There could be situations where position inside a\r\n canvas is the best choice. However, let’s talk about the downsides:

Canvas or Grid?

Changing\r\n the top/left of a child element will give the impression that it is \r\nmoving. But inside a grid you need to change the margin. If you want to \r\nmove two items you need to factor in the distance between them. What’s \r\nthe problem? Well, should you use canvas or grid or something else? It \r\nsimply means this approach is a potentially inconsistent approach.

Who’s your Neighbor

Changing\r\n the top/left of a child element will give the impression that it is \r\nmoving. Any peer elements whose layout is bound to the location of the \r\nmoving object must be redrawn with ever value change. What’s the \r\nproblem? Well, do you really know every potentially related element? It \r\nsimply means this approach is a potentially expensive approach.

GPU Acceleration

Transforms\r\n are a regimented approach to altering an element, even moving it. \r\nHardware acceleration can be attached to consistent, regimented \r\napproaches. What’s the problem? How can the GPU understand why you are \r\nchanging a dependency property’s value? It can’t. It simply means this \r\napproach cannot take advantage of GPU hardware acceleration.

Is there an alternative?

Yes. It’s TranslateTransform\r\n – a Silverlight class specifically designed to accommodate the task of \r\nmoving objects from one position to another. (TranslateTransform is also\r\n part of WPF). And get this, even in the documentation dips into this discussion:

MSDN: The local 0,0 for an object can be offset on a Canvas using Canvas.Left and Canvas.Top, but this does not count as a transform; the object retains its own local 0,0 in this case for transform purposes.

A\r\n TranslateTransform is easy to use. A TranslateTransform has an X and Y \r\nproperty which correlate to the relative position to the element’s \r\noriginal layout location. As you would expect, negative numbers move it \r\nin a reverse direction.

Apply a TranslateTransform like this:

And implement it like this:

In\r\n the code above, I handle the ManipulationDelta event to track the touch\r\n gestures by the user. In the handler, I increment and decrement the X \r\nand Y values of the TranslateTransform – just like Sam. And just like \r\nSam, my object tracks (or moves) with the user’s finger. But unlike Sam,\r\n my approach is hardware accelerated and a common, repeatable pattern.

Conclusion

Admittedly,\r\n I am sort of picking on my colleague to make a point. The reality is, \r\nSam’s approach works. In fact, it is a very common approach to moving \r\nelements in a XAML environment, but there are downsides – do those \r\ndownsides really matter? Maybe not enough for you to rewrite your \r\napplication, but then again maybe so.

You’re the developer, you \r\nneed to make the final call. Now you have a little more information. \r\nInformed decisions are usually better decisions. But I can’t tell you \r\nwhat is right for your application. What I can tell you is that \r\nTranslateTransform is easy to use, powerful, high performing, and a \r\nconsistent approach. Other than that, it’s up to you.

Special acknowledgement to Sam Stokes for starting a great discussion.