Juanma Santoyo » .net

Introducción a Entity framework Code First

Juanma — Sat, 22 Oct 2011 19:17:07 +0000

En general, para usar Entity Framework; debemos tomar como punto de partida una base de datos existente. Por lo tanto, sin base de datos no podemos crear el modelo de persistencia.

Pero todo eso ha cambiado ya que desde hace unos pocos meses disponemos de Entity framework Code First. EFCF nos permite crear el modelo de base de datos tomando como punto de partida una serie de clases. Estas clases, serán nuestro modelo de persistencia, y también serán el punto de partida desde el cual EFCF creará el esquema de la base de datos.

Convención sobre configuración

Una de las grandes cosas de EFCF es que sigue una pauta de “Convención sobre configuración”. Esto es, que nosotros no debemos configurar todas las cosas que programamos en nuestro modelo de persistencia, si no que EFCF lo hará por nosotros siempre que sigamos las convenciones de EFCF. Por lo tanto, cuando programemos nuestro modelo de persistencia deberemos conocer y aplicar dichas convenciones.

Las convenciones de las que hablo en realidad son muy pocas y muy coherentes. Ahora puede parecer que son un inconveniente por tener que conocerlas todas, pero nada más lejos de la realidad: veremos cómo gracias a esta política el desarrollo de un modelo de persistencia se vuelve un proceso simple y muy rápido.

Por supuesto, todas las convenciones son configurables. Si quieres complicarte la vida, tú mismo con tu mecanismo…

Por ejemplo, supongamos que estamos creando la clase de persistencia para la tabla Producto. Lo primero que deberíamos hacer, es crear un campo que sea la clave primaria. ¿Cómo determinamos cuál es ese campo?. Fácil: Por convención, la clave primaria será aquel campo numérico llamado Id. Cabe destacar que nada en EFCF es case-sensitive (aunque el modelo de persistencia sí lo es).

Ejemplo práctico

Vamos a hacer un pequeño ejemplo para ilustrar el funcionamiento de EFCF. Crearemos un pequeño modelo de persistencia para dos tablas: Producto y Categoría.

Ya podemos imaginar el resto de la historia: ambas tablas tendrán un identificador y un nombre. Además, la tabla producto estará relacionada con la tabla categoría; de forma que un producto tenga una categoría asociada y desde una categoría se pueda acceder a la colección de todos los productos asociados.

Instalando Entity framework Code First

Deberemos descargar e instalar EFCF para poder dotar a Visual Studio de las nuevas características. Descarga Entity Framework Code First aquí.

El orden de instalación es:

EF_JUNE_2011_CTP.msi
DS_JUNE_2011_CTP.msi
EFTools.msi

Las entidades

Crearemos un proyecto de tipo Librería de clases donde programaremos las clases que representarán las entidades. Atención aquí: debemos crear el proyecto bajo el framework Microsoft Entity Framework June 2011 CTP. El proyecto se llamará EFCFTest.Entities.

Crearemos una clase llamada Categoria.cs. En esta clase crearemos dos campos: uno será el identificador y el otro el nombre de la categoría.

namespace EFCFTest.Entities
{
    public class Categoria
    {
        public long Id {get; set;}
        public string Nombre { get; set; }
    }
}

Como veis, el campo Id es numérico. Un campo que se llame Id y sea numérico se convierte por convención en la clave primaria de la entidad. Además, es autoincrementable.

Vamos a crear ahora la clase Producto.cs.

namespace EFCFTest.Entities
{
    public class Producto
    {
        public long Id { get; set; }
        public string Nombre { get; set; }
        public int Stock { get; set; }
    }
}

Esta clase se parece mucho a la anterior, pero le he añadido un campo de Stock.

Solo nos queda un pequeño pero importantísimo detalle: Tenemos que programar la relación entre las entidades. Lo lógico aquí es que un producto se clasifique en una categoría y que una categoría tenga asociada una colección de productos. Pues no se hable más, vamos allá:

Empecemos por la clase Producto. Por convención, para asociar una entidad Categoría a la clase producto lo haremos añadiendo estos campos a la clase Producto.

public long CategoriaId { get; set; }
public virtual Categoria Categoria { get; set; }

Voy a explicar primero la segunda de estas dos propiedades: cumple dos características muy importantes:

Es del tipo Categoria. Esto es así porque su valor será la entidad categoría con en la que está clasificado el producto.
Es virtual. Esto es importante, ya que determina que es una propiedad de navegación.

La primera propiedad también cumple dos características:

Es del mismo tipo que la clave primaria de Categoria. Esto tiene que ser así porque almacenará dicho valor.
El nombre de la propiedad es la concatenación de el nombre de la propiedad de navegación Categoria y el nombre de la clave primaria en la entidad Categoria, que es Id.

Ahora vamos a crear la relación desde la clase Categoria. Aquí lo que queremos es una colección de productos, por lo que añadiremos la siguiente propiedad:

public virtual ICollection Productos { get; set; }

Los aspectos a destacar en esta propiedad son:

Al igual que la propiedad Categoria de la entidad Producto, es una propiedad de navegación y por lo tanto debe ser virtual.
Lógicamente, el tipo de la colección es Producto.

Las colecciones merecen un tratamiento un poco especial, ya que por defecto las colecciones son referencias vacías. Podemos modificar el objeto para que las colecciones vengan siempre inicializadas. Es sencillo, sólo deberemos añadir un constructor en nuestra clase. Realmente, en el constructor podríamos inicializar cualquier valor que queramos:

public Categoria()
{
	Productos = new List();
}

Con esto ya hemos acabado con las entidades. Como veis, el principio de convención sobre configuración nos obliga a hacer las cosas de una determinada manera, pero las convenciones son sencillas de aprender y nos ahorrarán mucho tiempo.

El contexto.

El contexto es el entorno que nos permitirá trabajar con las Entidades. Se trata de un objeto que usaremos para acceder a la capa de persistencia.

Vamos a crear un nuevo proyecto tipo Librería de clases donde programaremos el contexto de nuestra aplicación. Al igual que el anterior, este proyecto debe crearse bajo el framework Microsoft Entity Framework June 2011 CTP.

Este nuevo proyecto, extenderá de clases propias de EFCF, por lo que deberemos añadir una referencia a su DLL. Si has instalado EFCF tal y como indica este artículo, deberías encontrar la DLL en C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.2\System.Data.Entity.dll. Esto no tiene porqué ser así en tu entorno, ya que hay otras formas de instalar EFCF. También habrá que añadir una referencia al proyecto EFCFTest.Entities para poder hacer uso de las entidades que hemos creado previamente.

De momento, sólo vamos a añadir una clase. Quizás parezca absurdo crear un proyecto que va a contener una única clase, pero es más una cuestión de concepto y de escalabilidad: El contexto y las entidades no son exactamente lo mismo, por lo que no deberían estar juntos. El día de mañana, podríamos necesitar más contextos, o quizás necesitemos añadir lógica adicional a nuestro contexto.

La clase se llamará EFCFTestContext. Este nombre es importante, ya que por convención, es el nombre que recibirá el esquema de la base de datos que cree el contexto (el contexto es el encargado de crear la base de datos si no existe).

La clase es sencilla, sólo necesitará el siguiente código:

using System.Data.Entity;
using VoyAlCine.Entities;
namespace EFCFTest.Context
{
    public class EFCFTestContext : DbContext
    {
        public DbSet Categorias { get; set; }
        public DbSet Productos { get; set; }
    }
}

Como se puede ver, también he indicado los using que vamos a necesitar para importar las referencias que acabamos de añadir.

Las cosas a destacar de éste código son:

La clase contexto hereda de DbContext. Esta es una clase de la DLL de EFCF.
Crearemos un DbSet por cada entidad que hayamos creado. La clase DbSet también es parte de EFCF.

Sólo queda una cosa por decir sobre la clase contexto: sería lógico querer cambiar el nombre del esquema de la base de datos. Esto es sencillo, solo debemos añadir un constructor que sobre escriba la llamada al constructor de DbContext. Como parámetro, le pasaremos el nombre que deseamos darle a la base de datos:

public EFCFTestContext() : base("EFCFTest")
{
}

Creamos una aplicación de prueba

Por último, vamos a crear una aplicación que nos sirva para realizar algunas pruebas sobre nuestro nuevo modelo de persistencia.

Vamos a crear una aplicación de consola llamada EFCFTest.ConsoleApp. No hay que olvidar que debemos seleccionar el framework Microsoft Entity Framework June 2011 CTP.

Lo primero que haremos será agregar a las referencias los proyectos de entidades y contexto. También debemos añadir una referencia a la DLL System.Data.Entity.dll, tal y como hicimos en el proyecto de contexto.

Otra cosa importante que debemos hacer, es añadir la cadena de conexión a la base de datos. Esta cadena de conexión se debe añadir al app.config del proyecto, en el nodo configuration/connectionStrings. La cadena de conexión deberá ser algo como:

Data Source=;Initial catalog=EFCFTest;Integrated Security=True;MultipleActiveResultSets=True

Atención al parámetro Data Source. Este debe ser el servidor donde esté la base de datos. He puesto las marcas < y > por legibilidad, pero debéis quitarlas cuando pongáis el servidor.

Al final, vuestro app.config debe quedar más o menos así:

El parámetro providerName es muy importante.

Crear registros

Vamos a crear algunos registros. Lo primero que debemos hacer es crear una instancia del contexto al cual queramos acceder:

EFCFTestContext context = new EFCFTestContext();

Vamos a crear una categoría y le vamos a asociar dos productos:

Categoria Quesos = new Categoria();
Quesos.Nombre = "Quesos";

Quesos.Productos.Add(new Producto()
{
  Nombre = "Queso Edam"
  , Stock = 10
});

Quesos.Productos.Add(new Producto()
{
  Nombre = "Queso Havarti"
  , Stock = 5
});

context.Categorias.Add(quesos);

context.SaveChanges();

Lo que he hecho es lo siguiente: He creado un objeto Categoria, le he inicializado la propiedad Nombre, y después le he incluido en la colección de productos dos objetos Producto. Por último, lo más importante: he añadido la categoría al contexto, y he persistido los cambios con el método SaveChanges. Este último paso es esencial, ya que es lo que guarda en base de datos todos los objetos que hemos añadido al contexto.

Para tener un conjunto de datos más decente, voy a crear un par de categorías más, con sus respectivos productos. Haré algunas modificaciones sobre el código anterior que no voy a reflejar en este artículo por cuestiones de legibilidad. Como siempre, al final encontraréis una versión descargable de este ejemplo donde podréis consultar todo el código fuente.

Si ahora ejecutamos nuestra aplicación de consola, veremos cómo se crea nuestra base de datos y se inicializa con unos cuantos datos. Vamos a añadir un poco de código más al programa. Este código sólo servirá para monitorizar lo que está ocurriendo, y para evitar que la aplicación se cierre automáticamente (todas las aplicaciones de consola se cierran al acabar, a no ser que nosotros programemos que no sea así).

El código que añadiremos será:

Después de añadir una categoría al contexto añadiremos ésta línea:
```
Console.WriteLine("Se ha creado la categoría {0}", Quesos.Nombre);
```
Al final de nuestro programa, forzaremos que la aplicación espere la introducción de la tecla enter, de forma que no se cerrará hasta que se pulse enter:
```
Console.WriteLine("Operación finalizada. Pulsa ENTER para salir...");
Console.ReadLine();
```

Por último, antes de ejecutar la aplicación. Hay que tener en cuenta que se deba establecer la aplicación de consola como el proyecto de inicio:

Lo que ocurra en nuestra pantalla debería parecerse a esto:

Seguramente habréis notado un tiempo de inactividad excesivo al ejecutar la aplicación por primera vez. Esto se debe a que la base de datos no existía y se ha creado. Si accedéis a la base de datos con un gestor como el Microsoft SQL Management Studio o similar, podréis ver cómo se ha creado la base de datos:

Por supuesto, también se habrán creado los registros que hemos programado.

Seleccionar registros

Ahora vamos a ver cómo podemos seleccionar registros de la base de datos.

Lo primero que haremos será comentar el código anterior, ya que no queremos que se vuelvan a crear más registros. Sólo dejaremos sin comentar las líneas que crean el objeto Context y las que pausan la ejecución del programa. Comentaremos incluso la llamada al método SaveChanges, ya que no queremos modificar el contenido de la base de datos.

Hay varias maneras de acceder al contenido. Por ejemplo, desde el objeto Context podríamos obtener un listado con todas las categorías:

Console.WriteLine("nTodas las categorías:");
List Categorias = Context.Categorias.ToList();
foreach (Categoria Categoria in Categorias)
{
    Console.WriteLine("{0}t{1}", Categoria.Id, Categoria.Nombre);
}

Podríamos usar linq, personalmente es el método que más me gusta:

var ProductosQueso = from p in Context.Productos
where p.Nombre.ToLower().Contains("queso")
      select p;

Console.WriteLine("nProductos cuyo nombre contiene la subcadena "queso":");
foreach (Producto Producto in ProductosQueso)
{
    Console.WriteLine("t{0}.", Producto.Nombre);
}

Linq nos permitiría incluso hacer joins entre tablas:

ProductosQueso = from p in Context.Productos
join c in Context.Categorias on p.Categoria equals c
where c.Nombre.ToLower() == "Quesos"
select p;

Console.WriteLine("nProductos en la categoría "Quesos":");
foreach (Producto Producto in ProductosQueso)
{
    Console.WriteLine("t{0}.", Producto.Nombre);
}

También podríamos usar las lambda expressions de linq. Hacen el uso de linq más simple, pero no son tan potentes como usar linq directamente, y complican la lectura del código:

List ProductosFrutosSecos = Context.Productos.Where(
p => p.Categoria == Context.Categorias.FirstOrDefault(c => c.Nombre.ToLower() == "frutos secos"))
.ToList();

Console.WriteLine("nProductos en la categoría "Frutos secos":");
foreach (Producto Producto in ProductosFrutosSecos)
{
    Console.WriteLine("t{0}.", Producto.Nombre);
}

Por último, podríamos acceder a los elementos según el valor de su clave primaria. Es el método más simple de todos ya que permite seleccionar contenidos sin el uso de linq, pero sólo podríamos usarlo sabiendo la clave primaria del elemento que necesitamos, y no permite seleccionar conjuntos (solo elementos aislados):

Categoria CategoriaRefrescos = Context.Categorias.Find(2);
Console.WriteLine("nProductos en la categoría "Refrescos":");
foreach (Producto Producto in CategoriaRefrescos.Productos)
{
    Console.WriteLine("t{0}.", Producto.Nombre);
}

Borrar registros

Borrar los registros existentes no puede ser más sencillo:

Categoria CategoriaFrutosSecos = (from c in Context.Categorias
    where c.Nombre.ToLower() == "frutos secos"
    select c).First();

Context.Categorias.Remove(CategoriaFrutosSecos);

Console.WriteLine("nSe ha borrado la categoría {0}", (CategoriaFrutosSecos).Nombre);

Cómo veis, tan solo hay que localizar el registro a borrar y usar el método Remove.

Descarga el ejemplo

Como intento hacer siempre, os dejo la descarga del ejemplo.

¡Hemos terminado!

En éste artículo hemos explicado cómo crear una base de datos y su modelo de persistencia con Entity framework Code First y también hemos añadido varios ejemplos de cómo usarla. Ha sido un artículo muy completo que espero que os resulte útil.

Instalar el entorno de desarrollo de Surface 2

Juanma — Mon, 01 Aug 2011 15:34:04 +0000

Instalar el entorno de desarrollo para la Surface 2 es relatívamente sencillo, ya que el proceso es similar a la instalación del entorno para Surface 1. De hecho es más sencillo si cabe, ya que en ésta ocasión la instalación es totalmente compatible con Windows 7 y Visual Studio 2010, por lo que nos ahorraremos problemas.

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.

Crear eventos propios en aplicaciones de Surface

Juanma — Sat, 02 Oct 2010 08:34:41 +0000

En las aplicaciones de Surface, los eventos son básicos.

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:

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:

La variable MaxMilis sólo define el tiempo máximo entre ContactDown. Únicamente cuando el tiempo es inferior o igual, se considera un DoubleTap.
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).
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:

El evento.
Las gestión de los manejadores que quieran escuchar el evento.
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:

El nombre del evento.
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.
El tipo del manejador. No es casualidad que coincida con lo declarado en la línea 1.
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:

Recibir por parámetro los valores que hay que enviar como argumentos del evento.
Montar un objeto EventArgs que contenga los valores a enviar.
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:

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.

Arquitectura de capas en aplicaciones para Microsoft Surface

Juanma — Thu, 30 Sep 2010 19:10:46 +0000

En la primera aplicación que hice para Surface, cometí un gran error de arquitectura que bajo mi punto de vista estropeó un poco lo que yo considero que fue un buen trabajo. Ahora que estoy trabajando en otra aplicación para Surface, me propuse desde el primer día no repetirlo. A la solución que he encontrado la he llamado arquitectura de capas. No estoy inventando nada, pues en la programación gráfica dividir la interfaz en capas es muy común. Este artículo realmente sólo propone una forma de hacerlo en una aplicación WPF orientada a Surface.

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:

Diferentes controles de usuario que serán las capas.
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.

LayerB.

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:

Identifica la capa que llama al método.
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:

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:

Añadimos el namespace self, para poder incluír controles de usuario de nuestro proyecto.
Añadimos las dos capas.
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.

Detección y gestión de contactos en una Surface

Juanma — Wed, 22 Sep 2010 17:55:16 +0000

A estas alturas de la película, uno ya debería tener claro que la base de las entradas de usuario en una Surface son los contactos.

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:

Tipos de contactos.
Reconocimiento de contactos.
Diferenciación de contactos.
Reconocer el mismo contacto en diferentes eventos.
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:

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í.

Navegador basado en Chromium para integrar en aplicaciones WPF

Juanma — Fri, 03 Sep 2010 18:32:53 +0000

Desde hace semanas, intento encontrar la manera de identificar un usuario en Facebook desde una aplicación de Surface (WPF)… sin mucho éxito por el momento (de conseguir algo, será seguro una gran guarrería, que por supuesto publicaré en el blog).

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.

Introducción al componente ScatterView de Surface (2: ScatterViews con C#)

Juanma — Tue, 03 Aug 2010 05:27:06 +0000

Ya hemos visto como podemos usar los ScatterView a base de XAML, pero muchas veces vamos a tener la necesidad de tratarlos desde C#.

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.

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 images = new List();

        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#

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.

Animar transformaciones en WPF con el método BeginAnimation

Juanma — Tue, 06 Jul 2010 22:17:31 +0000

Me preguntaron hace poco cómo animar elementos en Microsoft Surface. En esencia se haría como en cualquier entorno basado en WPF.

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:

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.

Charla sobre Microsoft Surface

Juanma — Fri, 28 May 2010 15:15:12 +0000

Ayer dí una charla sobre Microsoft Surface en el centro de Innovación de Microsoft de Palma para el grupo de desarrolladores de .Net en Baleares.

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.

ScatterViewItem invisibles en Microsoft Surface

Juanma — Tue, 18 May 2010 06:00:57 +0000

Cuando empecé a desarrollar para Microsoft Surface, me di cuenta de tres cosas:

El control ScatterViewItem es la base de toda aplicación.
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”.
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:

Espero que os sirva tanto como a mí.

Introducción al componente ScatterView de Surface (1: ScatterViews con XAML)

Juanma — Thu, 08 Apr 2010 12:30:16 +0000

El multitouch es probablemente una de las características más atractivas de Surface. Esto se debe a que plantea una serie de posibilidades al usuario que convierte su experiencia en algo mucho más intuitivo y sencillo.

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:

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:

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:

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.

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:

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

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.

Enrutamiento Seo Friendly con asp.Net

Juanma — Tue, 06 Apr 2010 21:55:48 +0000

En los últimos años se ha ido estableciendo en los sitios web una buena práctica: las Seo Friendly URL. Friendly de amistoso, por que hace que nuestras rutas sean fáciles de indexar por los buscadores (los parámetros GET nunca les han gustado demasiado) y, mucho más importante; fáciles de comprender por los usuarios.

Es de sentido común que la URL de una página tenga que tener cierta relación con lo que contiene. A nadie le dice nada una URL de tipo http://www.dominio.com?seccion=5, pero la cosa es más interesante si es algo del tipo http://www.dominio.com/contacto. La propia URL de este artículo es un buen ejemplo.

En este artículo veremos un pequeño ejemplo de como podemos crear Friendly URLs en asp.Net

¿En que consisten técnicamente las Friendly URL?

La idea es interceptar las peticiones por URL que se realizan a nuestro sitio web antes de que se sirva ningún contenido, de forma que podamos analizar la ruta y servir un archivo u otro en consecuencia. También podemos considerar que parte de la URL es un parámetro de entrada.

Por ejemplo, la URL de este artículo podría ser una como http://www.dominio.com/articulos/enrutamiento-friendly-url/, donde la parte “enrutamiento-friendly-url” es la que determina qué artículo se está mostrando.

¿Cómo montamos el nuevo sistema de direccionamiento?

Cada tecnología de servidor tiene su forma de hacerlo. En este artículo veremos un ejemplo sobre asp.Net.

La clave es el archivo Global.asax. Este es un archivo que proporciona manejadores para una serie de eventos producidos por la aplicación. A nosotros nos interesará el evento Application_BeginRequest: es ahí donde podemos interceptar las peticiones antes de que se sirva ningún contenido, y donde analizaremos las URL para reprogramar el direccionamiento a donde nos interese. Obviamente, el archivo Global.asax tiene más utilidades que el enrutamiento, pero de momento no nos interesan.

Un ejemplo

Vamos a programar un pequeño ejemplo que nos serviría para gestionar los direccionamientos de una red social.

Haremos una dirección para las secciones principales, y una dirección que será dinámica para cada usuario miembro de la red social.

Diseñamos el nuevo enrutamiento

Como siempre, antes de empezar a hacer nada; necesitamos tener claro qué queremos hacer. Vamos a considerar todas las rutas que tendremos.

/inicio/
Todos los sitios web, las redes sociales también; necesitan una página de inicio.
/buscar/
Toda red social necesita un buscador.
/usuarios/
Lo más importante de una red social son los usuarios. Esta es la página genérica de usuarios, que podría ser por ejemplo un formulario de Login.
/usuarios//
Todos los usuarios tienen un perfil con su nombre, su foto, las cosas que hacen los domingos… Fijaos en que ya incluímos un parámetro, el nombre del usuario.
/usuarios//contacto/
La gracia de una red social es poder contactar con los usuarios. Esta página proporcionaría funcionalidad a una red de mensajería interna. Tambien tenemos el parámetro de nombre de usuario.

Creamos el proyecto

Vamos a crear un proyecto web normal y corrente desde el Visual Studio.

Crearemos cuatro .aspx, uno para cada una de nuestras rutas, excepto para /inicio/, que será el Default.aspx que se ha creado por defecto. Tambien crearemos una clase .cs para simular el origen de datos de los usuarios.

Buscar.aspx
Usuarios.aspx
UsuariosPerfil.aspx
UsuariosContacto.aspx
Datos/Usuarios.cs

Algo de código para los .aspx

Vamos a añadir algo de código en los .aspx. Para diferenciarlos, más que nada; y para probar unos links.

Default.aspx

	
		Inicio
	
	
		
		
			Inicio

			
				Buscar
				Usuarios

Buscar.aspx

	
		Buscar
	
	
		
		
			Buscar

			
				Inicio
				Usuarios

Usuarios.aspx

	
		Usuarios
	
	
		
		
			Usuarios

			
				Inicio
				Buscar

UsuariosPerfil.aspx

	
		Perfil de 
	
	
		
		
			

			
				Inicio
				Perfíl de

UsuariosContacto.aspx

	
		Contactar con 
	
	
		
		
			Contactar con 

			
				Inicio
				Perfíl de <%= getUserName() %>

Debemos considerar, además, un poco de código en los .cs:

Datos/Usuarios.cs

Este será nuestro origen de datos. Normalmente será una tabla en base de datos, un xml, o algo por el estilo; pero para nuestro ejemplo nos basta una clase que extienda de List. Le hemos programado además dos nuevos métodos: uno para convertir un valor de la lista al formato que usamos en las URL, y otro para encontrar valores. Destacar que el algoritmo de búsqueda podría ser bastante mejor, pero para el caso ya nos sirve.

	using System;
	using System.Collections.Generic;

	namespace JuanmaSantoyoSeoFriendly.Datos
	{
		public class Usuarios : List
		{
			public Usuarios()
			{
				this.Add("John Travolta");
				this.Add("Samuel L Jackson");
				this.Add("Bruce Willis");
				this.Add("Uma Thurman");
				this.Add("Quentin Tarantino");
			}
		}

		private string urlFormat(string str)
        {
            return str.ToLowerInvariant().Replace(" ", "-");
        }

        public int search(string username)
        {
            int userid = -1;
            int i = 0;

            while(this.Count > i)
            {
                if (urlFormat(this[i]) == username)
                {
                    userid = i;
                    break;
                }

                i  ;
            }

            return userid;
        }
	}

UsuariosPerfil.aspx.cs

En este .cs daremos valores a algunos elementos del .aspx, y además proporcionaremos métodos que rescatarán de sesión el ID del usuario y devolverán su nombre. Hay dos versiones para este método, uno devolverá el nombre tal cual, y el otro nos dará la posiblidad de devolver el nombre formateado para URL.

	protected void Page_Load(object sender, EventArgs e)
	{
		this.hTitle.InnerText = this.getUserName();

		Page.Title  = this.getUserName();

		lbUsuariosContacto.PostBackUrl = "~/usuarios/"   this.getUserName(true)   "/contacto/";
		lbUsuariosContacto.Text  = this.getUserName();
	}

	public string getUserName()
	{
		Datos.Usuarios usu = new Datos.Usuarios();

		if (HttpContext.Current.Items.Contains("userid") && HttpContext.Current.Items["userid"].ToString() != "-1")
		{
			return usu[Convert.ToInt32(HttpContext.Current.Items["userid"])];
		}
		else
		{
			return "user not found";
		}
	}

	public string getUserName(bool encode)
	{
		Datos.Usuarios usu = new Datos.Usuarios();

		if (HttpContext.Current.Items.Contains("userid"))
		{
			return usu[Convert.ToInt32(HttpContext.Current.Items["userid"])].ToLowerInvariant().Replace(" ", "-");
		}
		else
		{
			return "user not found";
		}
	}

UsuariosContacto.cs

Este .cs es bastante similar al anterior, así que no merece demasiados comentarios:

	protected void Page_Load(object sender, EventArgs e)
	{
		hTitle.InnerHtml  = getUserName();

		Page.Title  = this.getUserName();

		lbUsuariosPerfil.PostBackUrl = "~/usuarios/"   getUserName(true)   "/";
		lbUsuariosPerfil.Text  = getUserName();
	}

	public string getUserName()
	{
		Datos.Usuarios usu = new Datos.Usuarios();

		if (HttpContext.Current.Items.Contains("userid"))
		{
			return usu[Convert.ToInt32(HttpContext.Current.Items["userid"])];
		}
		else
		{
			return "user not found";
		}
	}

	public string getUserName(bool encode)
	{
		Datos.Usuarios usu = new Datos.Usuarios();

		if (HttpContext.Current.Items.Contains("userid") && HttpContext.Current.Items["userid"].ToString() != "-1")
		{
			return usu[Convert.ToInt32(HttpContext.Current.Items["userid"])].ToLowerInvariant().Replace(" ", "-");
		}
		else
		{
			return "user not found";
		}
	}

Añadimos el Global.asax

Añadimos un nuevo elemento en el proyecto. El nuevo elemento será un Artchivo de aplicación global. No le cambiaremos el nombre: lo dejaremos como “Global.asax”.

Configuramos las nuevas rutas

Antes que nada, debemos agregar la librería “System.Web.Routing”.

Programaremos nuestra propia función para aplicar el enrutamiento. La llamaremos “ApplyRouting”:

	private void ApplyRouting(RouteCollection Routes)
	{
		Routes.Add(new Route("", new RouteHandler("~/Default.aspx")));
		Routes.Add(new Route("inicio/", new RouteHandler("~/Default.aspx")));
		Routes.Add(new Route("buscar/", new RouteHandler("~/Buscar.aspx")));
		Routes.Add(new Route("usuarios/", new RouteHandler("~/Usuarios.aspx")));
		Routes.Add(new Route("usuarios/{username}/", new RouteHandler("~/UsuariosPerfil.aspx")));
		Routes.Add(new Route("usuarios/{username}/contacto/", new RouteHandler("~/UsuariosContacto.aspx")));
	}

Y la llamaremos desde el evento Application_BeginRequest:

	protected void Application_BeginRequest(object sender, EventArgs e)
	{
		ApplyRouting(RouteTable.Routes);
	}

Lo que hacemos es, básicamente; añadir nuevas rutas creadas por nosotros a la tabla de rutas de nuestra aplicación. Hay varias cosas destacables:

El primer parámetro es la nueva ruta. Si escribimos el valor entre llaves, será un parámetro. Los parámetros que antes enviábamos por GET deberían ser sustituídos por estos.
Estamos creando instancias de RouteHandler. Esta clase no existe en la Api de C#, la tenemos que programar nosotros y será donde añadiremos toda la lógica de redireccionamiento.
Como la clase RouteHandler la programamos nosotros, tenemos ciertas ventajas. En este caso, pasamos como parámetro del constructor el archivo al cual redirigimos. No tendría por qué ser así, pero como una de las características de nuestras URL es que siempre redirigen a un único archivo; este sistema nos viene bastante bien.

Programamos la lógica de redireccionamiento

Vamos a crear ahora la clase Routing/RouteHandler.cs. Esta clase, deberá heredar de IRouteHandler y por tanto deberá incorporar un método público llamado GetHttpHandler, que recibirá un único parámetro que es un RequestContext y que retornará un IHttpHandler.

En este método pasaran escencialmente dos cosas: por una parte, se meterán los parámetros recibidos en sesión. Por otra, se retornará un IHttpHandler que construiremos usando la ruta del .aspx al que queremos redirigir.

	public IHttpHandler GetHttpHandler(RequestContext requestContext)
	{
		/*
		 * Tratamos los parámetros de la URL:
		 * Si es el nombre de usuario, buscamos su ID y lo metemos en sesión.
		 * Si no, símplemente lo metemos en sesión
		 */
		foreach (KeyValuePair val in requestContext.RouteData.Values)
		{
			if (val.Key == "username")
			{
				Datos.Usuarios usu = new Datos.Usuarios();
				int userid = usu.search(val.Value.ToString());
				requestContext.HttpContext.Items["userid"] = userid;
			}

			requestContext.HttpContext.Items[val.Key] = val.Value;
		}

		return (Page) BuildManager.CreateInstanceFromVirtualPath(VirtualPath, typeof(Page));
	}

Añadimos además un constructor y una variable global para el parámetro que indica el archivo al que redirigimos.

	string VirtualPath = string.Empty;

	public RouteHandler(string path)
	{
		this.VirtualPath = path;
	}

Hecho esto, nuestras nuevas rutas ya deberían estar funcionando. Sólo nos queda un detalle.

Ignorando rutas

Generalmente, no sólo nos va a interesar añadir rutas a nuestra aplicación, sino tambien quitarlas. Por ejemplo, no es una mala idea que se ignoren las rutas directas a un .aspx, o aquellas rutas que no acaben con el carácter “/” (para tener un sistema de rutas uniforme). Vamos a programar una función en Global.asax, a la cual llamaremos justo antes de ApplyRouting y que se encargará de comprobar si nuestra ruta debe ser ignorada y, en ese caso, redirigir a /inicio/.

El método Application_BeginRequest en Global.asax queraría de la siguiente forma:

	protected void Application_BeginRequest(object sender, EventArgs e)
	{
		Redirect();
		ApplyRouting(RouteTable.Routes);
	}

El método Redirect:

	private void Redirect()
	{
		string url = Request.Url.ToString();

		if (url.Contains(".aspx"))
		{
			Response.Redirect("~/inicio/");
		}

		if (url[url.Length - 1] != '/' && !url.Contains("?"))
		{
			Response.Redirect(url + "/");
		}
	}

Descarga el código fuente

Sé que me odias por no haber puesto este archivo al principio, pero más vale tarde que nunca ¿no?.

Código fuente.

¡Hemos acabado!

Como véis, en asp.Net el enrutamiento Seo Friendly se reduce a dos clases: Global.asax y el manejador de rutas. Es bastante simple, y no requiere demasiado tiempo de implementación. Los beneficios de usar este tipo de enrutamiento son múltiples, desde aspectos de seguridad, hasta aspectos de usuabilidad y posicionamiento en buscadores. ¡Ya no hay excusa para no implementarlo!.

Introducción al desarrollo sobre Microsoft Surface

Juanma — Tue, 06 Apr 2010 06:15:28 +0000

Microsoft Surface (Surface a partir de ahora) es sin duda un desafío para los programadores. Acostumbrados a entornos gráficos basados en respuestas al ratón, una interfaz de usuario multitáctil nos plantea un nuevo reto a la mayoría de nosotros.

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.

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.

XML dinámicos con asp.Net

Juanma — Tue, 16 Mar 2010 19:04:33 +0000

Desde que me inicié en el asp.Net (no hace demasiado de eso) me he estado preguntando cómo se podría hacer una llamada al servidor que devolviese un contenido XML dinámico. Dicho de otra forma, lo que yo quería era generar un contenido XML en base a un parámetro enviado por GET o POST. Estos XML son necesarios para cualquier aplicación basada en Ajax que se precie, además de ser especialmente útiles para otras situaciones (como por ejemplo, compartir contenido interno a un consumidor externo).

Pues bien, hace un par de días me surgió la necesidad y investigué un poco al respecto. En realidad, la solución que nos propone .Net no está nada mal: un archivo .asmx que actúa como WebService.

Sobre los .asmx

De la misma forma que podemos añadir archivos .aspx a un proyecto web, también podemos añadir archivos .asmx. Estos archivos son la base de cualquier proyecto de WebService que desarrollemos en .Net, pero también podemos usarlos en los proyectos web normales.

¿Cómo se usan los .asmx?

El uso de los .asmx es simple: básicamente, lo que debemos hacer es crear un método, que devuelva un valor y que tenga la etiqueta [WebMethod]. Al final, la llamada a servidor: “http:////” nos devolverá el resultado devuelto por el método.

Por supuesto, el método puede tener parámetros, que enviaremos por GET o por POST; en cuyo caso, al hacer la llamada los parámetros enviados deberán tener el mismo nombre que el parámetro en el método.

Es importante destacar que si queremos enviar parámetros por GET o POST, deberemos activar ambos protocolos en el Web.config de nuestra aplicación.

Un ejemplo

La mejor forma de ver cómo funciona un .asmx es viendo un pequeño ejemplo. Con poco esfuerzo podremos hacer algunas pruebas.

Crear el proyecto

Sólo necesitaremos crear un nuevo proyecto web en nuestro Visual Studio. Nos creará por defecto un .aspx, pero no nos interesa demasiado.

Crear el asmx

Añadiremos en el proyecto web un nuevo elemento, que será un Servicio web. Lo encontrarás entre los posibles elementos de la categoría “Web”. Lo llamaremos “test.asmx“.

Cuando tengamos nuestro .asmx creado, lo estableceremos como la página inicial de nuestro proyecto (es una opción que aparecerá si clicamos con el botón derecho en el .asmx).

Un nuevo método en el .asmx

En el .asmx ya tenemos un método creado: HelloWorld. Es muy ilustrativo, ya que nos indica dos cosas: la primera, que nuestros métodos deberán tener al principio la etiqueta [WebMethod]. La segunda, que el valor retornado será lo que mostrará nuestro WebService al realizar una petición al método.

Vamos a programar un método más bien absurdo, pero que nos permitirá ver cómo funciona el envío de parámetros:

	[WebMethod]
	public string ReturnThisString(string str)
	{
		return str;

	}

Hay dos cosas a destacar:

El parámetro que recibe este método se llama str.
El resultado que genera este método, es un string.

Activamos los protocolos GET y POST

Como dije unas líneas más arriba, debemos activar los protocolos de envío GET y POST si queremos usarlos en nuestro WebService. Todo lo que debemos hacer es incluir dentro del nodo de nuestro Web.config las siguientes líneas:

Probamos el WebService

Y toca inicar una depuración. La primera vez que lo hagamos nos pedirá que activemos el modo debug. Le decimos que sí, y arrancará el .asmx.

Lo que veremos, será un resumen de los métodos que tiene el .asmx (esto no se vería en un entorno de producción). Podemos clicar en el nombre de nuestro método “ReturnThisString” para que nos muestre un pequeño formulario donde indicaremos el valor del parámetro “str“. Al enviarlo, veremos el resultado de nuestro método de WebService.

Hay varias cosas interesantes en las que fijarse ahora:

El resultado devuelto es un XML.

Sea cual sea el resultado, el asmx siempre nos dará una respuesta XML.
La ruta de la página.

Como ves, la url de este xml es: “http:////”. Esta es la dirección a la que accederemos para obtener resultados de nuestro WebService, ya sea con Ajax o con otra tecnología.
El nodo string.

El resultado del método viene, en realidad, dentro de un nodo llamado string. Esto es, efectívamente, el tipo del dato devuelto. ¿imaginas lo que pasaría si en vez de un string, devolvemos una lista de strings? Efectivamente, el XML resultante sería una lista de nodos string.

Generamos un XML como respuesta del método

Como ves, los WebServices .asmx no son demasiado complicados, aunque por el momento seguimos teniendo un pequeño problema: los XML que generamos como resultado son generados automáticamente y no tenemos control sobre ellos. Vamos a poner solución a esto.

La cuestión es que si en lugar de un string, devolvemos un objeto XmlDocument, el resultado devuelto por el WebService será el contenido del XmlDocument tal cual. Por lo tanto, se podría decir que el proceso para generar respuestas XML personalizadas (la razón de este artículo) es el siguiente:

Creamos un método en el .asmx que devuelva un objeto XmlDocument.
Obtenemos todos los datos que queramos devolver.
Los metemos en un XmlDocument.
Retornamos el XmlDocument.

Un último ejemplo

Vamos a crear un último ejemplo: un pequeño método que nos introducirá en la creación de XML dinámicos:

	[WebMethod]
	public XmlDocument ReturnXml()
	{
		XmlDocument xml = new XmlDocument();

		XmlNode rootNode = xml.CreateElement("RespuestaXml");
		XmlNode txtNode = xml.CreateTextNode("Xml generado automáticamente");
		XmlNode subNode = xml.CreateElement("HolaMundo");
		XmlNode commentNode = xml.CreateComment("Esto es un comentario");

		subNode.AppendChild(commentNode);
		rootNode.AppendChild(txtNode);
		rootNode.AppendChild(subNode);
		xml.AppendChild(rootNode);

		return xml;
	}

Esto generaría el siguiente resultado:

Descargar el ejemplo

Puedes descargar el ejemplo si algo no te ha quedado claro. Recuerda también que puedes dejar comentarios.

JuanmaSantoyoXmlDinamicos

¡Hemos terminado!

Y de momento no hay mucho más que decir. Con este ejemplo, hemos tocado un tema especialmente importante para la mayoría de proyectos web, ya que los XML dinámicos son importantes para las funcionalidades Ajax y para comunicarnos con otras aplicaciones externas. ¿Aún no tienes RSS en tu sitio web? ¡A qué esperas!.

Clase para acceso avanzado a las AppSettings del WebConfig

Juanma — Mon, 08 Feb 2010 17:41:54 +0000

Para quien no lo sepa, el WebConfig de asp.Net es un archivo XML que contiene todos los aspectos de configuración de nuestra aplicación. Entre los distintos parámetros, hay un nodo llamado AppSettings que nos permite definir pares clave / valor para después acceder a ellas desde cualquier punto de la aplicación.

Pero, a pesar de que el api proporciona dos métodos diferentes de acceso a las AppSettings, ambos tienen algunos inconvenientes. Lo que haremos, es crear una pequeña clase que nos permitirá tratar las AppSettings de una forma más simple y con una funcionalidad mejorada.

Clase AppSettings

Los inconvenientes

Los inconvenientes a la hora de trabajar con las variables de AppSettings son varios. Se podría decir que hay dos formas de acceder. Comentemos las dos formas:

Primera forma: la clase ConfigurationManager

La clase ConfigurationManager nos proporciona un diccionario estático que contiene los valores definidos en AppSettings:

ConfigurationManager.AppSettings["clave"];

A mi modo de ver, más largo de lo necesario y poco intuitivo (escribid “Configuration” en un VisualStudio y mirad cuantas entradas muestra el intellisense). Prometo que me costó un par de intentos memorizar esta línea.

Por otra parte, lo más grave es que el dato devuelto es siempre un string, lo cual nos obliga a hacer una conversión del dato inmediatamente después si queremos otro formato.

Segunda forma: la clase AppSettingsReader

Esta segunda clase, tiene algunas ventajas respecto a la anterior, pero también es mejorable.

Por una parte, su uso requiere de una instancia de AppSettingsReader y la posterior invocación a un método:

AppSettingsReader settings = new AppSettingsReader();
string valor = (string) settings.GetValue("clave", typeof(string));

Por no mencionar el casting obligatorio.

Por otra parte, aunque en principio se puede especificar el tipo del dato devuelto, hay poco control sobre él. ¿Qué pasa si es una fecha? Sinceramente, ni lo he probado.

Una posible solución

Yendo al grano, lo cierto es que el acceso a las AppSettings es mejorable. Vamos a considerar y a anotar algunas cosas sobre una posible alternativa que nos solucione los inconvenientes comentados:

Se accede desde una clase estática, pero más simple que la vista en la primera forma de acceder. No debería ser mucho más complejo que AppSettings.GetValue(“clave”).
Se ofrecen varios tipos básicos (pocos, pero controlados) como posibles retornos. Nuestra clase se encarga de hacer la conversión.
Además, la clase será capaz de realizar un tratamiento avanzado del contenido de las AppSettings: podrá retornar listas y diccionarios de los tipos básicos.

Definimos los diferentes tipos básicos de AppSettings

Serán solamente cuatro, pero a cambio ganaremos el control absoluto sobre los valores que retornamos.

Los tipos serán:

string
int
bool
DateTime

Definimos los diferentes formatos de las claves del AppSettings

Vamos a estipular como deberán ser escritos los datos en el WebConfig. A partir de ahora, deberemos escribir los valores en AppSettings siguiendo uno de los formatos siguientes. aunque ante cualquier excepción, siempre podremos obtener los datos como un tipo básico string (que será como si no aplicásemos ninguna conversión).

Datos básicos

No consideraremos un formato para los datos básicos porque no lo necesitan (excepto las fechas, que las vemos ahora mismo). Las cadenas se escribirán como cadenas, los números como números, y los booleanos como “true” y “false”.

Fechas

Las fechas seguirán un formato típicamente español:

dia/mes/año

Donde los días van del 1 al 31, los meses del 1 al 12, y los años tienen cuatro cifras.

Listas

Separaremos los diferentes elementos con comas.

valor1, valor2, valor3, valor4

Los espacios en blanco entre los valores y las comas serán indiferentes.

Diccionarios

Separaremos los pares con comas, y los clave valor con dos puntos.

clave1: valor1, clave2: valor2, clave3: valor3

Al igual que antes, los espacios en blanco entre los separadores y los valores son indiferentes.

Programamos la clase AppSettings

Ya sabemos que formatos tenemos que considerar. Ahora vamos a programar nuestra clase.

Antes que nada, debemos tener más o menos claro cómo queremos hacerlo. Lo haremos así:

Tendremos un método privado, llamado Get; que se encargará simplemente de obtener el dato de WebConfig como un string.
Tendremos tres métodos privados que se encargarán de convertir un string al resto de formatos. Se llamarán ToInt, ToBool y ToDate.
Tendremos varios métodos públicos, cada uno devolverá un tipo de dato. Los métodos se llamarán GetAsString, GetAsStringList, GetAsStringDict, GetAsInt, etc.

El método Get

private static string Get(string key)
{
	AppSettingsReader settings = new AppSettingsReader();            

	return (string) settings.GetValue(key, typeof(string));
}

En este método tenemos la única instancia de AppSettingsReader que vamos a usar. El resto de métodos de la clase se apoyarán en este para obtener la información del WebConfig.

Los métodos conversores

Serán tres. Uno convertirá un string a int, otro a bool y el último a DateTime.

private static int ToInt(string value)
{
	int v = 0;

	if (int.TryParse(value, out v))
	{
		return v;
	}

	return 0;
}

private static bool ToBool(string value)
{
	bool v = false;

	if (bool.TryParse(value, out v))
	{
		return v;
	}

	return false;
}

private static DateTime ToDateTime(string value)
{
	DateTime v = DateTime.Today;

	if (DateTime.TryParseExact(value, "dd/MM/yyyy", new CultureInfo("es-ES"), DateTimeStyles.None, out v))
	{
		return v;
	}

	else return new DateTime();
}

Los métodos que retornarán los datos

Estos métodos se apoyarán en los anteriores para obtener los valores, darles un formato de salida y devolverlos. Hay uno por tipo de dato y tipo de salida (normal, lista o diccionario).

Además, a los métodos que requieran de un separador (los que devuelven listas y diccionarios) les haremos una sobrecarga que permita indicar un separador distinto. De esta forma podremos reaccionar ante posibles conflictos entre nuestros separadores por defecto y los valores que contengan las AppSettings.

public static string GetAsString(string key)
{
	string value = Get(key);

	return value;
}

public static int GetAsInt(string key)
{
	string value = Get(key);

	return ToInt(value);
}

public static bool GetAsBool(string key)
{
	string value = Get(key);

	return ToBool(value);
}

public static DateTime GetAsDateTime(string key)
{
	string value = Get(key);

	return ToDateTime(value);
}

public static List GetAsStringList(string key, char sep)
{
	string value = Get(key);
	List list = new List();

	foreach (string s in value.Split(new char[] { sep }))
	{
		list.Add(s.Trim());
	}

	return list;
}

public static List GetAsStringList(string key)
{
	return GetAsStringList(key, '|');
}

public static List GetAsIntList(string key, char sep)
{
	string value = Get(key);
	List list = new List();

	foreach (string s in value.Split(new char[] { sep }))
	{
		list.Add(ToInt(s.Trim()));
	}

	return list;
}

public static List GetAsIntList(string key)
{
	return GetAsIntList(key, '|');
}

public static List GetAsBoolList(string key, char sep)
{
	string value = Get(key);
	List list = new List();

	foreach (string s in value.Split(new char[] { sep }))
	{
		list.Add(ToBool(s.Trim()));
	}

	return list;
}

public static List GetAsBoolList(string key)
{
	return GetAsBoolList(key, '|');
}

public static List GetAsDateTimeList(string key, char sep)
{
	string value = Get(key);
	List list = new List();

	foreach (string s in value.Split(new char[] { sep }))
	{
		list.Add(ToDateTime(s.Trim()));
	}

	return list;
}

public static List GetAsDateTimeList(string key)
{
	return GetAsDateTimeList(key, '|');
}

public static Dictionary GetAsStringDict(string key, char itemSep, char valueSep)
{
	string raw = Get(key);
	Dictionary dict = new Dictionary();

	foreach(string i in raw.Split(itemSep))
	{
		string item = i.Trim();

		string[] value = item.Split(valueSep);
		value[0] = value[0].Trim();
		value[1] = value[1].Trim();

		if (!dict.ContainsKey(value[0]))
		{
			dict.Add(value[0], value[1]);
		}
	}

	return dict;
}

public static Dictionary GetAsStringDict(string key)
{
	return GetAsStringDict(key, ';', '|');
}

public static Dictionary GetAsIntDict(string key, char itemSep, char valueSep)
{
	string raw = Get(key);
	Dictionary dict = new Dictionary();

	foreach (string i in raw.Split(itemSep))
	{
		string item = i.Trim();

		string[] value = item.Split(valueSep);
		value[0] = value[0].Trim();
		value[1] = value[1].Trim();

		if (!dict.ContainsKey(value[0]))
		{
			dict.Add(value[0], ToInt(value[1]));
		}
	}

	return dict;
}

public static Dictionary GetAsIntDict(string key)
{
	return GetAsIntDict(key, ';', '|');
}

public static Dictionary GetAsBoolDict(string key, char itemSep, char valueSep)
{
	string raw = Get(key);
	Dictionary dict = new Dictionary();

	foreach (string i in raw.Split(itemSep))
	{
		string item = i.Trim();

		string[] value = item.Split(valueSep);
		value[0] = value[0].Trim();
		value[1] = value[1].Trim();

		if (!dict.ContainsKey(value[0]))
		{
			dict.Add(value[0], ToBool(value[1]));
		}
	}

	return dict;
}

public static Dictionary GetAsBoolDict(string key)
{
	return GetAsBoolDict(key, ';', '|');
}

public static Dictionary GetAsDateTimeDict(string key, char itemSep, char valueSep)
{
	string raw = Get(key);
	Dictionary dict = new Dictionary();

	foreach (string i in raw.Split(itemSep))
	{
		string item = i.Trim();

		string[] value = item.Split(valueSep);
		value[0] = value[0].Trim();
		value[1] = value[1].Trim();

		if (!dict.ContainsKey(value[0]))
		{
			dict.Add(value[0], ToDateTime(value[1]));
		}
	}

	return dict;
}

public static Dictionary GetAsDateTimeDict(string key)
{
	return GetAsDateTimeDict(key, ';', '|');
}

¡Hemos terminado!

Ahora ya tenemos una clase que, además de ser fácilmente utilizable desde cualquier parte del programa, nos proporciona los valores de AppSettings en el formato que necesitemos. Además hemos extendido la funcionalidad respecto al api de asp.Net por que también es capaz de obtener los datos en forma de listas y diccionarios.