Paso a comentar qué hace falta instalar con sus respectivos enlaces de descarga.
Visual Studio 2010

Obviamente, lo primero es contar con un buen entorno de programación. Los que aún no tengáis un Visual Studio 2010 en vuestras manos, sabed que se pueden obtener licencias gratuitas desde el programa para estudiantes Deamspark. Si no sois estudiantes, podéis haceros con una versión de Visual C# 2010 Express, que no tiene tantas funcionalidades como un Visual Studio; pero es gratiíto y sigue siendo un bien IDE.

Mi recomendación es que os hagáis con las versiones en inglés.

XNA Framework redistributable 4.0

Al igual que el SDK de Surface 1 requería del XNA Framework redistributable 2.0, para el SDK de Surface 2 necesitaremos el XNA Framework redistributable 4.0. Se puede descargar fácilmente desde el centro de descargas de Microsoft.

SDK de Surface 2

Ahora ya tenemos todo lo que necesitamos para instalar el SDK de Surface 2. También se puede bajar desde el centro de descargas de Microsoft.

Empezar a programar con el nuevo SDK

Para empezar a tocar, podéis echarle un ojo a la nueva documentación de MSDN.

¡A Programar!. Hay que hacer una mención especial a la nueva interfaz metro, y las nuevas herramientas de desarrollo. Ahora el emulador está totalmente integrado en Windows 7 y es mucho más agradable para los desarrolladores. Sobre todo si contamos con una pantalla táctil.

La mayoría de las veces, nos bastará con los eventos que nos proporciona el SDK, pero en ocasiones necesitamos algo más específico, o incluso reaccionar a una combinación de eventos. Necesitamos eventos propios: poder disparar el evento cuando queramos, pasar la información que queramos; y que otra clase que esté escuchando el evento realice una acción.

De eso hablaré en este artículo. Comentaré un pequeño ejemplo donde veremos cómo podemos implementar un evento de doble tap (lo llamaremos DoubleTap). Este evento no viene implementado en el SDK de Surface, y como análogo al por todos conocido “Doble Click” de los PC, puede resultar muy útil.

Implementación de un evento DoubleTap.

Vamos a organizarnos un poco: ¿cómo vamos a implementar el DoubleTap?. Pues bien, en esencia un DoubleTap no es más que dos ContactDown en un periodo corto de tiempo. El ContactDown es un evento que sí que viene implementado en el SDK, así que sólo necesitamos almacenar el instante en el que se realizó el primer ContactDown para comprobar si el tiempo entre dos ContactDown es lo suficientemente corto. De serlo, se dispararía el DoubleTap. Es decir, que necesitamos:

• Un manejador para el evento ContactDown.
• Una propiedad global de tipo DateTime que almacenará el momento del último ContactDown.

Todo esto lo programaríamos dentro del objeto al que queremos dotar de la capacidad de lanzar DoubleTap. En nuestro caso, será un control de usuario (lo normal).

Programamos el control de usuario.

Gráficamente lo haremos fácil: un rectángulo. Este es el XAML:

<s:SurfaceUserControl x:Class="ProgramarEventosPropios.DoubleTapUserControl"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008">
    <Grid>
        <Rectangle Fill="Red" Width="100" Height="100" />
    </Grid>
</s:SurfaceUserControl>

Y ahora, el C#. Aquí es donde programaremos el evento DoubleTap, pero primero, vayamos a lo principal: gestionar el evento ContactDown y el tiempo entre dos ContactDown:

DateTime LastContactDown = DateTime.MinValue;
TimeSpan MaxMilis = TimeSpan.FromMilliseconds(700);

protected override void OnContactDown(ContactEventArgs e)
{
    base.OnContactDown(e);

    if (this.LastContactDown == DateTime.MinValue)
    {
        this.LastContactDown = DateTime.Now;
    }
    else
    {
        TimeSpan time = DateTime.Now - this.LastContactDown;

         if (time <= this.MaxMilis)
         {
             RaiseDoubleTapEvent(time);
         }

         this.LastContactDown = DateTime.MinValue;
    }
}

Varias cosas a comentar de este código:

1. La variable MaxMilis sólo define el tiempo máximo entre ContactDown. Únicamente cuando el tiempo es inferior o igual, se considera un DoubleTap.
2. Por otra parte, mirad cómo asigno el evento ContactDown. Lo normal es asignar un manejador, pero en este caso hago una sobreescritura del método OnContactDown. Los eventos también se pueden asignar así, aunque sinceramente, yo prefiero añadir un manejador en el XAML (en esta ocasión lo hago con sobreescritura a modo ilustrativo).
3. Por último, fijaos que en caso de cumplirse el DoubleTap, ejecuto el método RaiseDoubleTapEvent con el parámetro time. El método lo veremos ahora, se trata del disparador del evento. Los disparadores no son necesarios, pero sí muy recomendables. El parámetro time lo paso por que es la información que quiero enviar con el evento (en un objeto EventArgs). De esta forma, los manejadores del evento DoubleTap pueden saber cuánto tiempo pasó entre los dos ContactDown (no es una información demasiado útil, pero para ilustrar como funcionan los objetos EventArgs nos viene de perlas).

Y ahora empieza lo bueno: programamos el evento.

En realidad, hay que programar varias cosas:

1. El evento.
2. Las gestión de los manejadores que quieran escuchar el evento.
3. Un disparador para el evento.

Programamos el evento.

En realidad lo único complejo es el registro del evento. Y no es que sea complejo, es sólo que es muy configurable (y requiere muchos parámetros).

public delegate void DoubleTapEventHandler(object sender, DoubleTapEventArgs e);

public static readonly RoutedEvent DoubleTapEvent = EventManager.RegisterRoutedEvent(
	"DoubleTap",
	RoutingStrategy.Direct,
	typeof(DoubleTapEventHandler),
	typeof(DoubleTapUserControl));

Lo primero, definimos el manejador del evento. Le damos nombre, y; sobre todo; determinamos que los argumentos vienen como un objeto DoubleTapEventArgs. Este objeto lo crearemos luego, y tiene la particularidad de tener una propiedad para almacenar el tiempo entre los dos ContactDown ¿recordáis que al disparador le pasábamos un parámetro time?.

En cuanto al registro del evento, le pasamos cuatro parámetros:

1. El nombre del evento.
2. La estrategia del evento. Puede ser Direct, Tunnel o Bubble. Sirve para determinar la dirección de propagación. En este caso, Direct no se propaga.
3. El tipo del manejador. No es casualidad que coincida con lo declarado en la línea 1.
4. El tipo del objeto que dispara el evento. En este caso, el nombre de nuestro control de usuario.

La gestión de manejadores.

Esto se parece a los típicos getters / setters de .Net. Se trata simplemente de gestionar lo que ocurre cuando se añaden o se quitan manejadores de los eventos.

public event DoubleTapEventHandler DoubleTap
{
    add
    {
        AddHandler(DoubleTapEvent, value);
    }
    remove
    {
        RemoveHandler(DoubleTapEvent, value);
    }
}

El disparador.

Este método se encarga de lanzar el evento. Un disparador debería hacer tres cosas:

1. Recibir por parámetro los valores que hay que enviar como argumentos del evento.
2. Montar un objeto EventArgs que contenga los valores a enviar.
3. Lanzar el evento.

Es muy sencillo:

private void RaiseDoubleTapEvent(TimeSpan TimeBetweenTaps)
{
    DoubleTapEventArgs Args = new DoubleTapEventArgs(TimeBetweenTaps);
    Args.RoutedEvent = DoubleTapUserControl.DoubleTapEvent;

    RaiseEvent(Args);
}

Y este sería el objeto DoubleTapEventArgs. La idea es que es una extensión del objeto RoutedEventArgs.

public class DoubleTapEventArgs : RoutedEventArgs
{
	TimeSpan timeBetweenTaps = TimeSpan.MinValue;
	public TimeSpan TimeBetweenTaps
	{
	  get { return timeBetweenTaps; }
	}

	public DoubleTapEventArgs(TimeSpan TimeBetweenTaps) : base()
	{
		this.timeBetweenTaps = TimeBetweenTaps;
	}
}

Con esto ya hemos programado un control de usuario capaz de detectar y disparar un evento DoubleTap. ¿Cómo lo usamos?. Vamos a añadir este objeto a la ventana inicial de la aplicación y lo vemos. En realidad, como si fuese un evento normal y corriente.

Este es el XAML de la ventana:

<s:SurfaceWindow x:Class="ProgramarEventosPropios.SurfaceWindow1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008"
    xmlns:self="clr-namespace:ProgramarEventosPropios"
    Title="ProgramarEventosPropios"
>
    <s:SurfaceWindow.Resources>
        <ImageBrush x:Key="WindowBackground" Stretch="None" Opacity="0.6" ImageSource="pack://application:,,,/Resources/WindowBackground.jpg"/>
    </s:SurfaceWindow.Resources>

    <Grid Background="{StaticResource WindowBackground}" >
        <self:DoubleTapUserControl x:Name="DoubleTapUC" DoubleTap="DoubleTapUC_DoubleTap" />
    </Grid>

Y desde el C# programamos el manejador del evento:

void DoubleTapUC_DoubleTap(object sender, DoubleTapEventArgs e)
{
    Debug.WriteLine("Double Tap. Tiempo: {0}", e.TimeBetweenTaps.TotalMilliseconds);
}

Descarga del ejemplo.

Y como no podía ser de otra forma, os dejo aquí la descarga a un pequeño proyecto que es el que programé para redactar este artículo.

Crear eventos propios.

¡Hemos acabado!.

Con esto ya tenemos un evento propio funcionando. Este tipo de eventos nos serán muy útiles en nuestras aplicaciones, y nos solucionarán la vida en muchas ocasiones. No está de más decir que realmente este tipo de eventos se pueden implementar en cualquier aplicación WPF, no sólo en las aplicaciones de Surface.

Espero que hayáis encontrado útil este artículo.

Mi gran error.

Me dí cuenta de que era realmente complicado gestionar las cosas que había en el ScatterView. Si veis el vídeo, comprobaréis que básicamente estoy hablando de tres tipos de elementos: los controles de usuario, el coche, y las imágenes del interior del coche. La solución por la que opté en aquel momento se basaba en usar métodos para introducir y eliminar cada elemento en el ScatterView, y registrar la existencia de cada uno en tres listas globales (una lista para cada tipo de elemento). De esa forma ponía y quitaba los elementos de cada tipo.

Era una mala solución, por que no permitía una gran modularización del código y sobrecargaba la clase principal del programa de funcionalidades que realmente no eran de su competencia. Todo se complicaba mucho más si tenemos en cuenta que no pude encapsular el ScatterView en un control de usuario como me hubiese gustado y lo tenía todo en la ventana inicial de la aplicación. En pocas palabras, aunque creo que algunos aspectos de la aplicación quedaron bastante bien, la ventana inicial era sucia y desordenada. El tiempo y la falta de experiencia me impidieron mejorar ese aspecto. Se podría decir que esa aplicación tiene un serio problema de arquitectura.

La solución: Arquitectura de capas.

Sin embargo, cuando inicié el desarrollo de la aplicación que tengo ahora entre manos, decidí desde el primer momento plantear las cosas de otro modo. No quería repetir el mismo error, sobre todo por que esta aplicación es aún más compleja en lo que respecta a los elementos libres por la pantalla y un error de esas características hubiese tenido un impacto negativo en la aplicación mucho más devastador.

El principal error que cometí inicialmente fue pensar que un ScatterView no puede posicionarse sobre otro. En realidad, sí es posible, y ambos ScatterViews son totalmente funcionales. Esto nos permite organizar los elementos en varios ScatterViews, uno sobre otro; como si fuesen capas.

Básicamente, para implementar esta arquitectura sólo necesitaremos:

1. Diferentes controles de usuario que serán las capas.
2. Una clase estática o Singleton que se encargará de gestionar las interacciones entre capas.

Cada capa se preocupa únicamente de sus competencias, mientras que para cualquier tipo de interacción con los elementos de las otras capas se usarán funcionalidades implementadas en la clase estática.

Un ejemplo sencillo.

No voy a complicarlo, ya que realmente sólo nos interesa ver cómo funcionaría esta arquitectura.

El ejemplo en cuestión será el siguiente: vamos a hacer dos capas en forma de controles de usuario. En cada capa vamos a poner un ScatterView y un ScatterViewItem.

La idea es que cuando un ScatterViewItem se mueva, el otro se posicionará en una posición reflejada. Es decir, reflejará las coordenadas X e Y del ScatterViewItem que hemos movido.

Obviamente, la comunicación entre controles de usuario que necesitamos se implementará con una clase estática.

Las capas.

Vamos a programar las dos capas. Serán dos controles prácticamente idénticos, sólo cambiaremos un par de características del ScatterViewItem (para que no se confundan). Los ScatterViewItems tendrán colores diferentes y ubicaciones diferentes (obviamente). Uno estará situado en el punto (100, 100) y el otro en su punto simétrico (924, 668). Para simplificar el asunto, haremos que los ScatterViewItems no se puedan rotar ni escalar.

Los controles de usuario se llamarán LayerA y LayerB, este es su XAML:

LayerA.

<s:SurfaceUserControl x:Class="ArquitecturaDeCapas.LayerA"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008">
    <Grid>
        <s:ScatterView>
            <s:ScatterViewItem x:Name="Svi"
                Orientation="0" Center="100,100"
                Width="50" Height="50"
                CanScale="False" CanRotate="False"
                ScatterManipulationDelta="ScatterViewItem_ScatterManipulationDelta"
            >
                <Rectangle Fill="Yellow" />
            </s:ScatterViewItem>
        </s:ScatterView>
    </Grid>
</s:SurfaceUserControl>

LayerB.

<s:SurfaceUserControl x:Class="ArquitecturaDeCapas.LayerB"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008">
    <Grid>
        <s:ScatterView>
            <s:ScatterViewItem x:Name="Svi"
                Orientation="0" Center="924,668"
                Width="50" Height="50"
                CanScale="False" CanRotate="False"
                ScatterManipulationDelta="ScatterViewItem_ScatterManipulationDelta"
            >
                <Rectangle Fill="Red" />
            </s:ScatterViewItem>
        </s:ScatterView>
    </Grid>
</s:SurfaceUserControl>

Como veis en ambos controles, los ScatterViewItems tienen asignado un manejador para el evento “ScatterManipilationDelta“. Este evento se lanza cada vez que una manipulación provoca un cambio en el ScatterViewItem, así que lo usaremos para notificar a la clase estática que el ScatterViewItem tiene una nueva posición (y la clase estática lo notificará a su vez a la otra capa).

Vamos pues a ver ese manejador. En ambas capas será igual, ya que será el método de la clase estática quien diferencie entre una capa o otra (esto no tendría por qué ser así).

El manejador de ScatterManipilationDelta.

private void ScatterViewItem_ScatterManipulationDelta(object sender, ScatterManipulationDeltaEventArgs e)
{
    ScatterViewItem svi = (ScatterViewItem) sender;
    Layers.NotifyNewPosition(this, svi.Center);
}

Fijaos en el método Layers.NotifyNewPosition. Este método será el método que comunicará ambas capas. La idea es que haga dos cosas:

1. Identifica la capa que llama al método.
2. Notifica a la otra capa la nueva posición respecto a la que debe reflejar su ScatterViewItem.

Para identificar la capa que llama al método, vemos que se envía el parámetro this. Para saber la nueva posición del ScatterViewItem, envía el parámetro svi.Center.

Por otra parte, la clase estática informará a la otra capa de la nueva posición mediante un método público en la capa que deba ser notificada. En este caso, como la posición se refleja; también se harán los cálculos necesarios. El método público de cada capa, sería una cosa así:

public void ReflexSviPosition(Point Position)
{
    this.Svi.Center = new Point(1024 - Position.X, 768 - Position.Y);
}

Ahora que ya sabemos como son las capas, vamos a ver que forma tiene esa clase estática que nos comunicará ambas capas.

Una clase estática para comunicar las distintas capas.

A la capa en cuestión la llamaremos Layers. Como he dicho, puede ser estática o Singletone. Aunque seamos francos, realmente el único requisito que debe cumplir esta clase es que tiene que ser accesible por todas las capas que queramos relacionar.

public static class Layers
{
	private static LayerA layerA = null;
	public static LayerA LayerA
	{
		get { return layerA; }
		set { layerA = value; }
	}

	private static LayerB layerB = null;
	public static LayerB LayerB
	{
		get { return Layers.layerB; }
		set { Layers.layerB = value; }
	}

	public static void NotifyNewPosition(SurfaceUserControl Layer, Point Position)
	{
		if(Layer.GetType() == typeof(LayerA))
		{
			layerB.ReflexSviPosition(Position);
		}
		else if(Layer.GetType() == typeof(LayerB))
		{
			layerA.ReflexSviPosition(Position);
		}
	}
}

Podéis ver el método “NotifyNewPosition” y cómo hace la distinción de capas.

Otro aspecto muy importante de esta clase, son las propiedades LayerA y LayerB. No son más que referencias a las capas, para poder acceder posteriormente a ellas. ¿Dónde se inician estas propiedades? Pues allí donde estén las propias capas. En este caso es la ventana inicial de mi programa, que se llama Main.xaml.

El contenedor de las capas.

Este sería el xaml:

<s:SurfaceWindow x:Class="ArquitecturaDeCapas.Main"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008"
    xmlns:self="clr-namespace:ArquitecturaDeCapas"

    Title="ArquitecturaDeCapas"
>
    <s:SurfaceWindow.Resources>
        <ImageBrush x:Key="WindowBackground" Stretch="None" Opacity="0.6" ImageSource="pack://application:,,,/Resources/MainBackground.jpg"/>
    </s:SurfaceWindow.Resources>

    <Grid Background="{StaticResource WindowBackground}">
        <self:LayerA x:Name="LayerA" />
        <self:LayerB x:Name="LayerB" />
    </Grid>
</s:SurfaceWindow>

Y también se necesita un poco de C# para guardar en la clase Layers las referencias a cada capa. En mi caso, he añadido estas dos líneas de código al final del constructor de Main.

Layers.LayerA = this.LayerA;
Layers.LayerB = this.LayerB;

De esta clase Main destacar tres cosas:

1. Añadimos el namespace self, para poder incluír controles de usuario de nuestro proyecto.
2. Añadimos las dos capas.
3. Guardamos en Layers las referencias a nuestras capas. Yo lo he hecho al final del constructor, pero se podría hacer en el evento Loaded, por ejemplo.

Hemos acabado.

Pues no hay mucho más que decir, ya tenemos dos ScatterViews sincronizados. Rápido, sencillo, y para toda la familia; espero que os ayude.

Da igual si tocamos la pantalla con un dedo o con toda la mano, con un trozo de madera; o si hemos colocado un elemento etiquetado: Todo se reduce a detectar un contacto y gestionarlo.

Por lo tanto, se podría decir que hay varios tipos de contactos. En este artículo vamos a ver qué tipos de contactos hay, cómo podemos detectarlos, y cómo podemos obtener información relevante sobre los mismos. No es un asunto complicado, pero sí es bastante amplio. A modo de resumen, en el artículo vamos a tratar los siguientes puntos:

1. Tipos de contactos.
2. Reconocimiento de contactos.
3. Diferenciación de contactos.
4. Reconocer el mismo contacto en diferentes eventos.
5. Conocer los diferentes contactos que existen sobre un elemento.

Tipos de contactos.

Básicamente, podemos considerar tres tipos diferentes de contactos:

Dedos.

La mayoría de contactos son dedos, ya que para el usuario, lo más natural y intuitivo casi siempre será hacer algo con el dedo sobre la pantalla.

Etiquetas.

Una de las características más interesantes de una Surface es la detección de etiquetas. Las etiquetas son unos gráficos que al entrar en contacto con la pantalla son reconocidos como tales y tienen un valor numérico determinado.

Existen dos tipos de etiquetas: Las Byte Tags y las Identity Tags. La principal diferencia entre ambas es que las Byte Tags pueden tomar 2⁸ valores distintos, y los Identity Tags pueden tomar 2¹²⁸ valores diferentes (separados en dos campos de 2⁶⁴ y 2⁶⁴).

Un Byte Tag

Un Identity Tag

Objetos.

En realidad, la Surface reacciona ante cualquier contacto sobre la pantalla, sea lo que sea. Puede ser el dorso de la mano, un trozo de madera, etc. Por lo tanto, catalogaremos como un “objeto” cualquier contacto que no sea ni un dedo ni una etiqueta.

Reconocer contactos sobre un elemento.

Reconocer los contactos sobre un elemento es relativamente sencillo. El propio SDK nos aporta eventos como “ContactDown“, “ContactUp” o “ContactTapGesture” que nos realizaran dicha tarea. De hecho, “ContactDown” nos servirá en la mayoría de las ocasiones.

Lo que sí requiere más conocimiento del tema es cómo diferenciar los diferentes tipos de contactos, y cómo obtener información relevante sobre cada uno.

Veamos un ejemplo sencillo de “ContactDown“. Por ejemplo, sobre un control de usuario que tengamos en pantalla.

Añadiremos la gestión del evento en el XAML del Control de usuario:

<s:SurfaceUserControl x:Class="DeteccionDeContactos.MyUserControl"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008"

    ContactDown="SurfaceUserControl_ContactDown"
    Width="100" Height="100"
>
    <Grid Background="Red">

    </Grid>
</s:SurfaceUserControl>

Y esto nos generará en el código C# un método como este:

private void SurfaceUserControl_ContactDown(object sender, ContactEventArgs e)
{
}

Podéis ver que por parámetro nos llegan dos objetos. Uno es el objeto sender, que no es más que el control de usuario que ha recogido el evento “ContactDown“. Por otra parte, nos llega el objeto e. Es un objeto del tipo “ContactEventArgs“, y contiene mucha información que nos puede interesar.

Obtener información útil sobre los contactos.

Antes de nada, vamos a ver cómo podemos saber qué tipo de contacto es. En realidad es sencillo, ya que las propiedades e.Contact.IsContactRecognized y e.Contact.IsTagRecognized nos lo revelarán:

private void SurfaceUserControl_ContactDown(object sender, ContactEventArgs e)
{
    if (e.Contact.IsFingerRecognized)
    {
        Debug.WriteLine("Es un dedo.");
    }
    else if (e.Contact.IsTagRecognized)
    {
        Debug.WriteLine("Es un elemento etiquetado.");
    }
    else
    {
        Debug.WriteLine("Es un objeto.");
    }
}

Ahora bien: ¿Más cosas que nos puedan interesar? Pues dependerá del tipo de contacto, obviamente. En general, algo que tienen en común todos los contactos es una posición en pantalla y una orientación (recordemos que una de las más geniales características de una Surface es poder detectar la orientación de un contacto). Nos lo dirán los métodos e.Contact.GetPosition y e.Contact.GetOrientation. Ambos métodos reciben por parámetro un elemento respecto al que orientarse. Lo más común es orientarse respecto al objeto que capturó el método, así que el parámetro sender que mencioné antes nos viene de perlas. El objeto sender en principio viene tipado como un objeto genérico, así que habrá que hacerle un casting. No debería ser un problema si tenemos claro quien lanzó el evento.

private void SurfaceUserControl_ContactDown(object sender, ContactEventArgs e)
{
    MyUserControl uc = (MyUserControl) sender;

    Point position = e.GetPosition(uc);
    Double orientation = e.Contact.GetOrientation(uc);

    Debug.WriteLine("El contacto se ha producido en la posición: {0}, {1}.", position.X, position.Y);
    Debug.WriteLine("La orientación del contacto es de {0} grados.", orientation);

    if (e.Contact.IsFingerRecognized)
    {
        Debug.WriteLine("Es un dedo.");
    }
    else if (e.Contact.IsTagRecognized)
    {
        Debug.WriteLine("Es un elemento etiquetado.");
    }
    else
    {
        Debug.WriteLine("Es un objeto.");
    }
}

Bueno, ya sabemos dónde se produjo el contacto, y sabemos también su orientación. Si el contacto fuese un dedo, no necesitamos saber más. Pero ¿Y si es un objeto etiquetado? Hay dos parámetros importantísimos que nos interesará conocer: el tipo de etiqueta y su valor. Conviene anticipar que si el contacto es de tipo Identity, el valor se separa en dos campos: la serie y el valor. La serie son los primeros 2⁶⁴ bits, el valor son los últimos 2⁶⁴ bits. Debemos considerar el objeto e.Contacts.Tag y sus propiedades.

private void SurfaceUserControl_ContactDown(object sender, ContactEventArgs e)
{
    MyUserControl uc = (MyUserControl) sender;

    Point position = e.GetPosition(uc);
    Double orientation = e.Contact.GetOrientation(uc);

    Debug.WriteLine("El contacto se ha producido en la posición: {0}, {1}.", position.X, position.Y);
    Debug.WriteLine("La orientación del contacto es de {0} grados.", orientation);

    if (e.Contact.IsFingerRecognized)
    {
        Debug.WriteLine("Es un dedo.");
    }
    else if (e.Contact.IsTagRecognized)
    {
        Debug.WriteLine("Es un elemento etiquetado.");

        switch (e.Contact.Tag.Type)
        {
            case TagType.Byte:

                Byte byteTagValue = e.Contact.Tag.Byte.Value;

                Debug.WriteLine("Es un Byte Tag. Su valor es {0}.", byteTagValue);
                break;

            case TagType.Identity:

                long serie = e.Contact.Tag.Identity.Series;
                long identityTagValue = e.Contact.Tag.Identity.Value;

                Debug.WriteLine("Es un Identity Tag. Su serie es: {0}. Su valor es {1}.", serie, identityTagValue);
                break;
        }
    }
    else
    {
        Debug.WriteLine("Es un objeto.");
    }
}

Por último, si el contacto es un objeto cualquiera, nos interesará saber su forma y el área que ocupa. El propio SDK nos ayuda creando un objeto Ellipse que tiene la forma aproximada del contacto. Nosotros podemos saber dónde está el centro del elipse, cuál es su tamaño y incluso el área exacta del objeto que toca la pantalla. Debemos observar los métodos e.Contact.GetEllipse,  e.Contact.GetCenterPosition, y la propiedad e.Contact.PhysicalArea. Los métodos para obtener los valores de la elipse también reciben por parámetro el objeto respecto al que deben calcularse. Igual que antes, lo normal sería usar el parámetro sender.

private void SurfaceUserControl_ContactDown(object sender, ContactEventArgs e)
{
    MyUserControl uc = (MyUserControl) sender;

    Point position = e.GetPosition(uc);
    Double orientation = e.Contact.GetOrientation(uc);

    Debug.WriteLine("El contacto se ha producido en la posición: {0}, {1}.", position.X, position.Y);
    Debug.WriteLine("La orientación del contacto es de {0} grados.", orientation);

    if (e.Contact.IsFingerRecognized)
    {
        Debug.WriteLine("Es un dedo.");
    }
    else if (e.Contact.IsTagRecognized)
    {
        Debug.WriteLine("Es un elemento etiquetado.");

        switch (e.Contact.Tag.Type)
        {
            case TagType.Byte:

                Byte byteTagValue = e.Contact.Tag.Byte.Value;

                Debug.WriteLine("Es un Byte Tag. Su valor es {0}.", byteTagValue);
                break;

            case TagType.Identity:

                long serie = e.Contact.Tag.Identity.Series;
                long identityTagValue = e.Contact.Tag.Identity.Value;

                Debug.WriteLine("Es un Identity Tag. Su serie es: {0}. Su valor es {1}.", serie, identityTagValue);
                break;
        }
    }
    else
    {
        Double area = e.Contact.PhysicalArea;
        Ellipse ellipse = e.Contact.GetEllipse(uc);
        Point ellipseCenter = e.Contact.GetCenterPosition(uc);

        Debug.WriteLine("Es un objeto.");
        Debug.WriteLine("La elipse aproximada que contiene el contacto es ancho: {0}, alto: {1}", ellipse.Width, ellipse.Height);
        Debug.WriteLine("El punto central de la elipse es: {0}, {1}", ellipseCenter.X, ellipseCenter.Y);
    }
}

Reconocer el mismo contacto en diferentes eventos.

Los contactos en realidad disparan más de un evento. Por ejemplo, un mismo contacto primero genera un “ContactDown” y por último generará un “ContactUp“. Entonces, ¿Cómo saber que son el mismo?. Para ello usaremos la propiedad e.Contact.Id. El mismo contacto, en diferentes eventos; conservará el mismo Id.

Conocer los diferentes contactos sobre un elemento.

Y para acabar, algo que también nos puede ser de utilidad es conocer los diferentes contactos que hay sobre un elemento. Para ello, podemos usar la propiedad ContactsOver que nos proporcionan los controles de usuario. Esto es una lista de objetos Contact, por lo que a cada elemento se le podrían aplicar todas las propiedades y métodos vistos en este artículo.

Hemos acabado.

Bueno, acabamos de pegar un buen repaso a los contactos de Surface. Dejo la descarga a un ejemplo que desarrollé para escribir este artículo.

Deteccion de contactos (VS 2010)

El contenido de este artículo debería ser suficiente para que cualquier hombre de bien desarrolle aplicaciones bastante decentes para Microsoft Surface, pero el que tenga dudas o necesite más información sobre algún aspecto que no dude en comentarlo por aquí. Yo mismo sigo aprendiendo sobre el tema, así que cualquier ayuda que os pueda prestar también me ayuda a mí.

No obstante, hice algunas preguntas por el blog de desarrolladores de Surface en MSDN USA, y es ahí donde me recomendaron este navegador para integrar en aplicaciones WPF:

http://chriscavanagh.wordpress.com/2009/08/25/a-real-wpf-webbrowser/

El proyecto es muy interesante: han aprovechado que el código de Chromium es libre para hacer una adaptación del mismo en WPF. Para que quede más claro, estoy hablando de un control de usuario 100% funcional, que puede ser integrado en aplicaciones WPF y que es una alternativa al control WebBrowser (el problema de este es que no es más que el Internet Explorer integrado en la aplicación).

En realidad este navegador no es exáctamente lo que necesito para mi aplicación y no lo he probado, pero como después de semanas de investigación esto es lo más interesante que me he encontrado, quería comentarlo.

En este artículo, veremos cómo podemos trabajar con ScatterViews de forma dinámica.

Preparamos el proyecto

Antes de iniciar el Visual Studio, debemos haber iniciado el emulador de Surface que viene con el SDK. Si no lo has hecho así, cierra el Visual Studio y inícialo todo en el orden correcto.

Usaremos el proyecto HelloScatterView que creamos en el primer artículo, y crearemos una nueva ventana XAML llamada “CSharpSample“. Tendremos que modificar el archivo App.xml (atrubito StartupUri) para que inicie la aplicación en la nueva ventana.

ScatterViews simples con C#

Vamos a considerar un XAML muy básico, sin ScatterViewItems. Sí que vamos a añadir tres botones que nos proporcionarán un mínimo de funcionalidad.

	<s:SurfaceWindow
		x:Class="HelloScatterView.SurfaceWindow1"
		xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
		xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
		xmlns:s="http://schemas.microsoft.com/surface/2008"
		Title="HelloScatterView">

		<s:SurfaceWindow.Resources>
			<ImageBrush x:Key="WindowBackground"
					  Stretch="None" Opacity="0.6"
					  ImageSource="pack://application:,,,/Resources/WindowBackground.jpg"/>
		</s:SurfaceWindow.Resources>

		<DockPanel>
			<UniformGrid Background="Black" Height="50" DockPanel.Dock="Top" Columns="3">
				<s:SurfaceButton Content="Add" Click="Add" Foreground="White"/>
				<s:SurfaceButton Content="Remove" Click="Remove" Foreground="White"/>
				<s:SurfaceButton Content="Clear" Click="Clear" Foreground="White"/>
			</UniformGrid>
			<s:ScatterView x:Name="Scatter"/>
		</DockPanel>
	</s:SurfaceWindow>

Por ahora esto es todo el XAML que vamos a usar. La parte importante del código, la hacemos desde C#, en el archivo CSharpSample.xaml.cs.

Antes de continuar vamos a dejar claro que hará cada botón:

• El botón Add añadirá un ScatterViewItem con una de las imágenes (se seguirá un orden cíclico).
• El botón Remove quitará el último ScatterViewItem añadido.
• El botón Clear quitará todos los ScatterViewItems.

Inicializamos

Creamos en el .cs una propiedad global que será una lista con los nombres de las imágenes, y otra propiedad que será un String con la ruta del directorio que las contiene, de forma que al concatenar el directorio con nombre de imagen tengamos la ruta completa. Daremos los correspondientes valores a ambas propiedades.

namespace HelloScatterView
{
    public partial class CSharpSample : SurfaceWindow
    {
        string folder = string.Empty;
        List<string> images = new List<string>();

        public CSharpSample()
        {
            this.folder = "Resources/Img/";

            images.Add("fuente_tres_chorros.jpg");
            images.Add("kiyoumizu_dera.jpg");
            images.Add("laputa_robot.jpg");

            InitializeComponent();

            // Add handlers for Application activation events
            AddActivationHandlers();
        }
	}
}

Eventos de los botones

El evento click del botón añadir creará un ScatterViewItem, le asignará la imagen y lo añadirá al contenedor ScatterView. Para saber que imagen añadir, se basará en el total de imágenes añadidas.

private void Add(object sender, RoutedEventArgs e)
{
	// Calculamos el indice de la imagen a mostrar en función de la cantidad de elementos en el ScatterView
	int index = this.Scatter.Items.Count % this.images.Count;

	// Creamos el ScatterViewItem que vamos a añadir
	BitmapImage bmp = new BitmapImage(new Uri(this.folder + this.images[index], UriKind.Relative));
	Image img = new Image();
	img.Source = bmp;

	ScatterViewItem svi = new ScatterViewItem();
	svi.Content = img;

	Scatter.Items.Add(svi);
}

El evento click del botón eliminar, accederá a la última imagen añadida en el contenedor ScatterView y la eliminará:

private void Remove(object sender, RoutedEventArgs e)
{
	// Averiguamos el índice del último elemento añadido
	int index = this.Scatter.Items.Count - 1;

	if (index >= 0)
	{
		this.Scatter.Items.Remove(this.Scatter.Items[index]);
	}
}

El evento click del botón borrar limpiará complétamente el contenedor ScatterView:

private void Clear(object sender, RoutedEventArgs e)
{
	this.Scatter.Items.Clear();
}

Añadir ScatterViews con Data Binding

Pero vamos a aprovechar las características de .Net para añadir los ScatterViewItems de una forma más potente. En realidad, podemos definir un origen de datos de forma que .Net añadirá todas las imágenes que contenga al contenedor ScatterView.

Dicho de otra forma, en pocas líneas de código podemos conseguir añadir al ScatterView todas las imágenes que haya, por ejemplo; en un directorio determinado. Vamos a hacer un ajuste en el constructor de CSharpSample y en el nodo s:ScatterView del XAML:

En el C#

public CSharpSample()
{
	this.folder = "Resources/Img/";

	images.Add("fuente_tres_chorros.jpg");
	images.Add("kiyoumizu_dera.jpg");
	images.Add("laputa_robot.jpg");

	InitializeComponent();

	// Add handlers for Application activation events
	AddActivationHandlers();

	String[] files = System.IO.Directory.GetFiles("Resources/Img", "*.jpg");
	this.Scatter.ItemsSource = files;
}

Lo importante son las últimas lineas: obtienen la lista de imágenes en un directorio y la establecen como el origen de datos del ScatterView.

En el XAML#

<s:ScatterView x:Name="Scatter">
	<s:ScatterView.ItemTemplate>
		<DataTemplate>
			<s:ScatterViewItem>
				<Image Source="{Binding}" />
			</s:ScatterViewItem>
		</DataTemplate>
	</s:ScatterView.ItemTemplate>
</s:ScatterView>

Lo importante es el nodo ItemTemplate: hemos establecido una plantilla que es la que usarán los elementos en el origen de datos.

Es todo por hoy

Ahora ya sabemos crear ScatterVirews desde XAML y desde C#, pero esto es sólo el principio. Como comenté en el primer artículo, un ScatterViewItem es mucho más que una imagen; y eso es lo que veremos en el próximo artículo sobre ScatterViews.

Hay varias formas de animar, pero quizás una de las más sencilla y potente sea la animación de transformaciones con el método BeginAnimation.

Las transformaciones.

En WPF existen varios tipos de transformaciones:

• RotateTransform. Cambia la orientación de un elemento.
• ScaleTransform. Cambia el tamaño de un elemento.
• TranslateTransform. Cambia la posición de un elemento.
• TransformGroup. Es un tipo de transformación especial, ya que consiste en una combinación de las tres anteriores.

Animar transformaciones.

La idea es simple: Una animación consiste en modificar progresivamente el valor de una propiedad durante un periodo de tiempo. En principio, se puede animar cualquier propiedad de dependencia del API de WPF.

Concretamente, las transformaciones usan propiedades de dependencia para modificar el aspecto del elemento en el que se aplican; así que si aplicamos una animación sobre una propiedad de una transformación de cualquier tipo, el resultado será una animación sobre el elemento.

El código para aplicar una transformación es sencillo. Se puede aplicar desde XAML o desde C#, pero en lo personal prefiero hacerlo en XAML:

	<Image x:Name="MyImage" Source="images/myimage.png" Width="100" Height="100">
		<Image.RenderTransform>
			<TransformGroup>
				<TranslateTransform x:Name="Translacion" X="85" />
				<RotateTransform x:Name="Rotacion" Angle="0" CenterX="15" CenterY="15" />
			</TransformGroup>
		</Image.RenderTransform>
	</Image>

Fijaos que al usar el nodo “TransformGroup” podemos aplicar más de una transformación. De no usarlo sólo podríamos aplicar una, ya que el nodo “Image.RenderTransform” sólo admite un nodo hijo. Notad también que las transformaciones se aplican desde la última a la primera. No es lo mismo mover y rotar, que rotar y mover.

Las animaciones y el método BeginAnimation.

A nivel práctico, una animación es un objeto con una serie de propiedades configuradas, como por ejemplo la duración de la animación, la aceleración, el valor inicial y final de la propiedad, etc. Dependiendo del tipo de dato que queramos animar, el objeto de animación cambia. No es lo mismo animar un color (ColorAnimation) que una orientación (DoubleAnimation). Se pueden ver todos los tipos de animación posible en la especificación de la clase madre: AnimationTimeLine.

Para aplicar una animación sobre una transformación, contamos con un potente aliado: el método BeginAnimation, presente en todas las transformaciones. Al método BeginAnimation se le pasan dos parámetros: la propiedad de dependencia a animar, y la animación. La animación deberemos construirla en base a lo que queremos animar, la propiedad de dependencia es una propiedad estática de la clase a la que pertenece el elemento que queremos animar. Por ejemplo, si queremos animar el ángulo de un RotateTransform, tendremos una propiedad estática “RotateTransform.AngleProperty“. Más fácil con un poco de código C#:

	DoubleAnimation animacion = new DoubleAnimation();

	animacion.To = 180;
	animacion.Duration = new Duration(TimeSpan.FromMilliseconds(1000));

	Rotacion.BeginAnimation(RotateTransform.AngleProperty, animacion);

Es todo por el momento.

Y en realidad no hay mucho más que decir sobre animaciones. Sólo destacar que, como imagináis, el objeto animación tiene eventos que informarán del estado del proceso, y que no son bloqueantes (es decir, mientras una animación se ejecuta, el flujo del programa no se detiene, por lo que necesitan una gestión asíncrona). También destacar que la animación se iniciará en el instante en que se ejecute el método BeginAnimation.

Si queréis aprender sobre animaciones más complejas, os recomiendo que miréis el objeto StoryBoard.

La aplicación fue principalmente desarrollada por un servidor (me refiero al que escribe, no a un servidor de aplicaciones ), y fue un reto muy bonito. La verdad es que ha sido una experiencia profesional muy interesante y divertida.

Bueno, al tema: Mi compañero en esta aventura, Carlos García; ha realizado un vídeo donde se puede ver cómo es la aplicación y su funcionamiento. Me llena de orgullo y satisfacción compartirlo con todos vosotros:

Hablamos un poco de todo lo que implica la Surface y el desarrollo de aplicaciones para este dispositivo. Fue una experiencia muy gratificante.

Dejo la descarga del Power Point que redacté para la ocasión, por si os interesa.

Microsoft Surface.

1. El control ScatterViewItem es la base de toda aplicación.
2. La mayoría de las veces, no queremos que el ScatterViewItem tenga la apariencia tan horrible que tiene por defecto, es más, nos interesará que sea “invisible”.
3. El control ScatterViewItem no proporciona ningun sistema simple para volverse invisible.

Así que despues de trastear un poco con Microsoft Expression Blend, conseguí montar un pequeño estilo que podemos aplicar a nuestros ScatterViewItem para que estos sean invisibles. Esto es, inapreciables para el usuario. Por lo tanto, el contenido se verá perfectamente, pero las sombras, reflejos, destellos y demás tonterías, no.

Este es el estilo en cuestión:

<Style x:Key="InvisibleScatterViewItem" TargetType="{x:Type s:ScatterViewItem}">
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type s:ScatterViewItem}">
                <ContentPresenter />
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Espero que os sirva tanto como a mí.

El componente ScatterView es quizás uno de los mejores ejemplos de esto. Este es el primero de varios artículos en el que veremos cómo se usan y qué posiblides nos ofrecen.

Sobre el componente ScatterView

Un ScatterView representa un elemento que reacciona a los contactos sobre Surface y que se puede mover, rotar o redimensionar.

El ejemplo más clásico sería un puñado de fotografías. Cada una de esas fotografías puede ser un ScatterView.

Preparamos el proyecto

Antes de iniciar el Visual Studio, debemos haber iniciado el emulador de Surface que viene con el SDK. Si no lo has hecho así, cierra el Visual Studio y inícialo todo en el orden correcto.

Creamos el proyecto

Nuestro proyecto va a ser una aplicación para Surface basada en WPF. Lo llamaremos HelloScatterView.

Al crear nuestro proyecto se nos ha creado una ventana por defecto: SurfaceWindow1. La renombraremos, y le pondremos el nombre de “XamlSample“.

Añadimos unas imágenes

Para poder trabajar con los ScatterViews, necesitaremos algunas imágenes.

Dentro de nuestro proyecto Surface tenemos una carpeta llamada Resources. Crearemos otra carpeta en su interior llamada Img y ubicaremos ahí nuestras imágenes.

Añadir ScatterViews desde XAML

ScatterView simple con XAML

Comenzaremos usando los ScatterViews desde XAML. En realidad añadir un ScatterView es muy simple:

<s:ScatterView>
    <Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
</s:ScatterView>

Este es el código que añade un ScatterView. Fijaos en un detalle: añadir un ScatterView no es sólo añadir el nodo ScatterView, también es añadir el recurso que se manejará, en este caso la imagen. Y es que un ScatterView no es una imagen, sino la capacidad que tiene un elemento (en este caso una imagen) de ser rotado, redimensionado y movido.

El XAML completo de la ventana es este:

<s:SurfaceWindow
    x:Class="HelloScatterView.SurfaceWindow1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:s="http://schemas.microsoft.com/surface/2008"
    Title="HelloScatterView">
    <s:SurfaceWindow.Resources>
        <ImageBrush x:Key="WindowBackground"
                  Stretch="None" Opacity="0.6"
                  ImageSource="pack://application:,,,/Resources/WindowBackground.jpg"/>
    </s:SurfaceWindow.Resources>
    <s:ScatterView>
        <Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
    </s:ScatterView>
</s:SurfaceWindow>

Si ahora compilamos nuestro proyecto, podremos jugar un poco con nuestra foto sobre el emulador de Surface. Incluso, si conectas dos ratones por USB puedes simular multitouch.

Vamos a hacerlo un poco más espectacular añadiendo varias imágenes:

<s:ScatterView>
    <Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
    <Image Source="Resources/Img/kiyoumizu_dera.jpg"/>
    <Image Source="Resources/Img/laputa_robot.jpg"/>
    <Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
    <Image Source="Resources/Img/kiyoumizu_dera.jpg"/>
    <Image Source="Resources/Img/laputa_robot.jpg"/>
</s:ScatterView>

Scatterviews complejos con XAML

Probablemente ya te estés preguntando lo siguiente: ¿cómo determinar los parámetros por defecto de nuestro ScatterView? Vamos a ello.

La clave está en que la estructura que hemos usado ahora no acaba de ser la mejor. En realidad, nos está faltando crear un ScatterViewItem, que hasta el momento se estaba creando de forma automática para cada elemento en el ScatterView.

<s:ScatterView>
	<s:ScatterViewItem>
		<Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
	</s:ScatterViewItem>
</s:ScatterView>

En el nodo ScatterViewItem podemos establecer muchas propiedades que afectarán al comportamiento de nuestro ScatterView.

Algunas de esas propiedades son:

• MinWidth, MaxWidth, MinHeight, MaxHeight: Máximos y mínimos de anchura y altura.
• CanMove, CanRotate, CanScale: Activan o desactivan las capacidades de mover, rotar y redimensionar.
• Width, Height, Center, Orientation: Valores iniciales para el ancho, el alto, la posición, y la rotación.
• BorderBrush, BorderThikness: Color y grosor del borde.

Un ejemplo sencillo:

<s:ScatterView>
	<s:ScatterViewItem Center="512,384" Orientation="0">
		<Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Center="512,384" Orientation="60">
		<Image Source="Resources/Img/kiyoumizu_dera.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Center="512,384" Orientation="180">
		<Image Source="Resources/Img/laputa_robot.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Center="512,384" Orientation="240">
		<Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Center="512,384" Orientation="300">
		<Image Source="Resources/Img/kiyoumizu_dera.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Center="512,384" Orientation="360">
		<Image Source="Resources/Img/laputa_robot.jpg"/>
	</s:ScatterViewItem>
</s:ScatterView>

Aunque de hecho, podemos centralizar la mayoría de estas propiedades en un único nodo, como un estilo:

<s:ScatterView>
	<s:ScatterView.ItemContainerStyle>
		<Style TargetType="{x:Type s:ScatterViewItem}">
			<Setter Property="Center" Value="512,384"/>
			<Setter Property="BorderBrush" Value="Black"/>
			<Setter Property="BorderThickness" Value="3"/>
		</Style>
	</s:ScatterView.ItemContainerStyle>

	<s:ScatterViewItem Orientation="0">
		<Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Orientation="60">
		<Image Source="Resources/Img/kiyoumizu_dera.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Orientation="180">
		<Image Source="Resources/Img/laputa_robot.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Orientation="240">
		<Image Source="Resources/Img/fuente_tres_chorros.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Orientation="300">
		<Image Source="Resources/Img/kiyoumizu_dera.jpg"/>
	</s:ScatterViewItem>

	<s:ScatterViewItem Orientation="360">
		<Image Source="Resources/Img/laputa_robot.jpg"/>
	</s:ScatterViewItem>
</s:ScatterView>

Es todo por hoy

El componente ScatterView es sencillo de usar y proporciona una característica muy interesante a nuestras aplicaciones.

Cuando se trabaja para Surface, hay que tener muy en cuenta que los diversos usuarios se colocan alrededor de la mesa, por lo que no existe el derecho ni el revés. Los ScatterViews nos solucionarán este problema más de una vez.

En la siguiente parte del artículo, veremos cómo trabajar con ScatterViews desde C#.

Editado 7/5/2010:

Me comentaron que los códigos fuente en XAML tenían mal la sintaxis, y efectívamente; cuando he pasado a revisarlo así era. Ni idea de que pudo pasar… Bueno, ya están arreglados.

En este artículo, pretendo dos cosas: por una parte, informarte de qué necesitas para comenzar a desarrollar y cómo obtenerlo. Por otra parte, facilitarte esa documentación que a todos nos va tan bien para empezar con una nueva tecnología. Así que vamos a ello.

Lo primero que debes saber, es que una aplicación para Surface no es más que una aplicación WPF o XNA. Por si no lo sabías, WPF es un entorno muy potente para desarrollar aplicaciones de escritorio orientadas a los nuevos entornos gráficos de Windows Vista y Windows 7. XNA es un entorno para desarrollo de videojuegos también facilitado por Microsoft. Si has jugado con la Xbox 360 te habrás preguntado ¿de dónde salen los tantísimos juegos del bazar? Pues bien, la mayoría están desarrollados por compañías independientes con XNA.

Obviamente, optar por WPF o XNA dependerá de nuestra aplicación. Si necesitamos un motor rico en controles de usuario, optaríamos por WPF. Si necesitamos un motor potente en la renderización de gráficos 3D, optaríamos por XNA. Depende de las necesidades de nuestra aplicación.

En este artículo, pretendo dos cosas: por una parte, informarte de qué necesitas para comenzar a desarrollar y cómo obtenerlo. Por otra parte, facilitarte esa documentación que a todos nos va tan bien para empezar con una nueva tecnología. Así que vamos a ello.

Lo primero que debes saber, es que una aplicación para Surface no es más que una aplicación WPF o XNA. Por si no lo sabías, WPF es un entorno muy potente para desarrollar aplicaciones de escritorio orientadas a los nuevos entornos gráficos de Windows Vista y Windows 7. XNA es un entorno para desarrollo de videojuegos también facilitado por Microsoft. Si has jugado con la Xbox 360 te habrás preguntado ¿de dónde salen los tantísimos juegos del bazar? Pues bien, la mayoría están desarrollados por compañías independientes con XNA.Obviamente, optar por WPF o XNA dependerá de nuestra aplicación. Si necesitamos un motor rico en controles de usuario, optaríamos por WPF. Si necesitamos un motor potente en la renderización de gráficos 3D, optaríamos por XNA. Depende de las necesidades de nuestra aplicación.

Instalación del entorno de desarrollo

Para empezar, un detalle importante es nuestro sistema operativo: El SDK de Surface no funcionará en Windows XP, necesitaremos Windows Vista o superior.

Bien, empecemos a instalar los programas necesarios. Antes de empezar, no estaría mal asegurarse de que tenemos instalada la última versión del .Net Framework (3.5 SP1 en estos momentos).

La primera herramienta que debemos conseguir es un Visual Studio. Como sabrás, Visual Studio es un IDE desarrollado por Microsoft y orientado al desarrollo de aplicaciones en .Net. Si no lo tienes y eres estudiante universitario, puedes hacerte con una licencia de estudiante. Esta licencia es totalmente gratuita y sólo necesitaras proporcionar tu identificación como estudiante. Puedes obtenerla aquí: Microsoft Visual Studio.

Cuando tengamos el Visual Studio instalado, deberemos instalar el Framework de XNA (independientemente de que queramos desarrollar con WPF). Lo podemos obtener de aquí: Microsoft XNA Framework.

Finalmente, instalamos el SDK de Surface. Lo encontramos aquí: Microsoft Surface SDK.

Con este software instalado, ya estamos listos para abrir el Visual Studio y crear un nuevo proyecto de Surface, no sin antes ejecutar el emulador de Surface que viene con el SDK. De esta forma, al depurar proyectos desde Visual Studio, se ejecutarán en el emulador.

Debes saber, además; que si conectas más de un ratón por USB el emulador los considerará dedos diferentes. ¡Eso es, soporte multitáctil en tu ordenador!.

Recursos de documentación para empezar

Ya tenemos todo lo necesario para empezar a desarrollar aplicaciones de Surface. Ahora, sólo nos falta algo de documentación que nos oriente para empezar a hacer cosas.

Developing for Microsoft Surface

Pero ¿dónde nos estamos metiendo realmente? En esta conferencia de Microsoft se ilustra cómo es el desarrollo de aplicaciones en Surface.
Developing for Microsoft Surface.

Hola Mundo Surface con WPF

Siguiendo en la línea anterior, este artículo me ha aclarado algunos conceptos generales más a la hora de afrontar el desarrollo con Surface. Interesante sobre todo porque habla algo de los nuevos eventos de contacto de Surface.
Hola Mundo Surface con WPF.

MSDN .Net Framework Developer Center

Pero vamos, ya está bien de conceptos generales, ¿verdad? Seguro que ya tienes ganas de meterle mano a Surface.

En MSDN nos facilitan información y ejemplos varios para empezar a programar algunas cosas. ¡Suerte!.
MSDN .Net Framework Developer Center.