Juanma Santoyo

JSFiffle, consola Javascript para agilizar tus desarrollos

Juanma — Fri, 18 May 2012 06:06:08 +0000

Mi buen compañero Jaime Rosselló me hablaba hace un par de días de JSFiddle, una herramienta online que nos permitirá codificar nuestros Javascripts de forma mucho más productiva.

Se trata de una consola sobre la cual podremos definir nuestro un entorno HTML y CSS sencillo para poder empezar a codificar Javascript como locos.

Como no tengo tiempo, no me enrollo más. Espero que esta herramienta os sea de utilidad: JSFiddle.

El objeto RegExp de JavaScript. Las dos cosas que van a cubrir la mayoría de tus necesidades.

Juanma — Thu, 19 Jan 2012 06:31:42 +0000

Las expresiones regulares tienen muchos usos, pero la mayoría de las veces sólo vas a hacer dos cosas:

Comprobar si una cadena cumple el patrón
Extraer subcadenas de la cadena de origen

Voy a ilustrar en un par de ejemplos cómo se usa el objeto RegExp de JavaScript, el cual nos permite usar expresiones regulares.

Crear un objeto RegExp

Veamos primero cómo se construye un objeto RegExp. Hay dos formas:

Forma tradicional

El RegExp se puede crear mediante un constructor, como cualquier otro objeto. Los argumentos del constructor son dos strings: el patrón y los modificadores. Un ejemplo:

var expression = new RegExp('^.* prueba$', 'i');

El modificador usado es el case insensitive.

La gran ventaja de este sistema es que el patrón se crea con un string, lo cual permite crear el patrón de forma dinámica.

Forma simplificada

Otra forma de crear un objeto RegExp es mediante una estructura del tipo: /patrón/modificadores. Por ejemplo:

var expression = /^.* prueba$/i;

Comprobar si una cadena cumple el patrón

La mayoría de las veces sólo queremos saber si una cadena cumple un patrón. Para ello, contamos con el método Test de RegExp, que devolerá true o false según se cumpla el patrón o no:

var expression = /^.* prueba$/i;
var str = 'Esto es una prueba';
expression.test(str); // true

Extraer subcadenas de la cadena de origen

Con las expresiones regulares también es posible extraer trozos de la cadena original. Para ello, se deben definir grupos en el patrón mediante el uso de paréntesis.

El método exec de RegExp nos retornará un array con todos los valores extraídos, y es nuestra responsabilidad saber qué índice del array ocupará el valor que buscamos. Hay que tener en cuenta que el índice 0 siempre será la cadena original.

var expression = /^.* (.*)$/i;
var str = 'Esto es una prueba';
expression.exec(str); // ['Esto es una prueba', 'prueba']

Una mención especial al método Replace

Con lo anterior ya he cubierto los usos más interesantes de RegExp, pero el método Replace del objeto String merece una mención especial, ya que se vuelve mucho más potente si lo usamos con objetos RegExp. Podéis consultarlo aquí: Metodo Replace.

Formatear cadenas con placeholders en JavaScript (II)

Juanma — Mon, 16 Jan 2012 21:48:44 +0000

Esta mañana comentaba una función que estoy utilizando para construir cadenas con placeholders en JavaScript. Mientras acababa el post, consideré la opción de hacerle una pequeña mejora, pero no tenía tiempo. Así que publico ahora dicha mejora.

La idea es poder usar la misma técnica sin la necesidad de que los placeholders sean identificadores numéricos. Es decir, un placeholder podría identificarse con una cadena de texto cualquiera. Por ejemplo, esto es lo que teníamos antes:

var precioFinal = stringFormat('El precio final es de {0} {1}', precio, moneda);

La idea es poder hacer algo como esto:

var precioFinal = stringFormat('El precio final es de {precio} {moneda}'
    , {
        'precio' : precio
        , 'moneda' : moneda
    }
);

Esto es mucho más simple de usar ya que nos elimina la complejidad de tener que conocer el identificador numérico de cada argumento que usamos, lo cual es fácil si tenemos pocos parámetros, pero se complica si usamos varios.

Ésta es la función:

function stringFormat(string, values)
{
    for(var i in values)
    {
        var expresion = new RegExp('\\{' + (i) + '\\}', 'ig');
        string = string.replace(expresion, values[i]);
    }

    return string;
}

En realidad, el algoritmo se basa en un for in, eso quiere decir que si queremos usar la función con placeholders numéricos también podríamos hacer algo como:

var precioFinal = stringFormat('El precio final es de {0} {1}'
    , [
        precio
        , moneda
    ]
);

¡Espero que esta función os sea de utilidad!

Formatear cadenas con placeholders en JavaScript

Juanma — Mon, 16 Jan 2012 10:38:04 +0000

Normalmente, intento evitar lo máximo posible la concatenación de valores en una cadena. Por ejemplo, no me gusta hacer cosas como esta:

var precioFinal = 'El precio final es de ' + precio + ' ' + moneda;

El motivo es que con este tipo de estructura es fácil cometer un error. No soy muy bueno probando mi código, así que para compensar intento programar siempre de forma que sea difícil cometer errores.

Por lo tanto, cuando se trata de montar cadenas de texto en Java Script solía hacer algo como esto para imitar la funcionalidad String.Format de .Net:

var precioFinal = 'El precio final es de {0} {1}'
     .replace('\{0\}', precio)
     .replace('\{1\}', moneda)

Cuando lo hice dos veces me di cuenta de que necesitaba una función. Cuando lo hice veinte veces, hice la maldita función de una vez… ya sabéis cómo es esto.

La idea era simple: usar el array arguments de Javascript para implementar una especie de String.Format. Allá va:

function stringFormat(string)
{
    if(arguments.length > 1)
    {
        for(var i = 1; i < arguments.length; i++)
        {
            var expresion = new RegExp('\\{' + (i - 1) + '\\}', 'ig');
            string = string.replace(expresion, arguments[i]);
        }
    }

    return string;
}

La función es tan simple como parece. Tan solo busca los placeholders y los reemplaza por su valor correspondiente. Se usaría así:

var precioFinal = stringFormat('El precio final es de {0} {1}', precio, moneda);

Parece una tontería, pero sabiendo que la tengo en el blog ya no me volverá a dar pereza implementarla .

Felicidades Windows Phone. Algunos enlaces de interés.

Juanma — Mon, 24 Oct 2011 18:43:55 +0000

La semana pasada Windows Phone cumplió un añito y hay que celebrarlo.

Me gustaría compartir algunos enlaces que ayudarán a los que aún no se han iniciado en esta tecnología, y que también nos serán útiles a los que ya hemos hecho algunas cositas.

Instalación del entorno de desarrollo

Nada más fácil, instalar el entorno de desarrollo es tan sencillo como descargar el instalador.

Cursos online

Microsoft publicó no hace mucho un curso online muy decente, que incluso contempla algunas sesiones programadas de tutorías con gente que sabe de esto: Curso Online de Desarrollo de Aplicaciones en Silverlight para Windows Phone.

Tampoco podemos olvidar esa gran fuente de sabiduría que es msdn: Windows Phone Development.

Ejemplos

Por último, siempre viene bien tener a mano una buena fuente de ejemplos. Me gusta mucho la que compartían hoy mismo los chicos de Speaking in .NET: Windows Phone Development QuickStarts.

Y, de nuevo una vez más, volvemos a msdn: Code Samples for Windows Phone.

Espero que estos enlaces os sean de utilidad. ¿Qué hacéis aún leyendo? ¡Empezad a programar!.

Automatizar acciones entre redes sociales con ifttt

Juanma — Sat, 22 Oct 2011 20:54:35 +0000

Llevo toda la tarde trabajando en el blog, y lo último que me quedaba por hacer era vincular la cuenta de twitter con la página de facebook.

Facebook provee una aplicación con la que es muy sencillo configurarlo, de forma que publicando en el muro de mi página en Facebook se reflejase en twitter, pero a mí me interesaba hacerlo alrevés; que publicando en twitter se reflejase en facebook. Eso no es tan simple.

Lo mejor que he encontrado es ifttt, un servicio que, dándole permisos; permite automatizar diversos tipos de tareas entre distintas redes sociales.

La idea es montar disparadores, y configurarlos mediante la regla “si ocurre esto, haz aquello”. La potencia es brutal, y permite simplificar y centralizar todas las acciones que queramos automatizar entre distintas redes sociales.

Os recomiendo que le echéis un ojo: ifttt.

Cambios

Juanma — Sat, 22 Oct 2011 19:25:43 +0000

He aprovechado las vacaciones para hacer algunos cambios en el blog.

Básicamente, he renovado el diseño y he abierto una cuenta de twitter donde se reflejarán las nuevas entradas, y además iré poniendo cosillas interesantes de vez en cuando. A partir de ahora, me podréis encontrar también por @juanmasantoyoes.

¡Saludos!

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.

Surface Shell dejó de funcionar

Juanma — Sat, 18 Jun 2011 19:08:24 +0000

Me he pasado meses sin poder codificar una línea de código surface por un error que me traía de cabeza.

Tal y como encabeza éste artículo, el error reza tal que así: “Surface Shell dejó de funcionar”, y se produce cada vez que el emulador de surface se intenta arrancar.

Como suele ocurrir en estos casos, la solución es obvia y absurda. Tan sólo es cuestión de instalar el Microsoft XNA Framework Redistributable 2.0.

En mi caso, tenía instalada la versión 3.1. Como soy un fenómeno, había asumido que la 3.1 sería tan válida como la 2.0 y cuando instalé el entorno de desarrollo de Surface instalé la versión equivocada.

Lo cierto es que ambas versiones pueden coexistir sin problemas en el sistema, así que si te ocurre éste error, sólo tienes que instalar el Microsoft XNA Framework Redistributable 2.0, no importa ni que desinstales el resto de versiones si no quieres.

Reaccionar a los objetos etiquetados en Microsoft Surface: el control TagVisualization.

Juanma — Sat, 18 Jun 2011 18:19:17 +0000

Hace unos meses, hablaba por aquí sobre los contactos en pantalla (Detección y gestión de contactos en una Surface).

Aunque hay otra forma de reaccionar a los contactos etiquetados: En Surface es muy común posicionar un gráfico justo bajo el objeto etiquetado. Algo como esto:

Este gráfico debe posicionarse siempre bajo nuestro objeto y orientarse según lo haga el objeto. Además, dependiendo del tipo de etiqueta o su valor, este gráfico puede tener comportamientos distintos. Para los casos en los que queremos responder a un objeto etiquetado de esta forma, tenemos dos objetos que nos facilitarán la vida: El TagVisualizer y el TagVisualization.

El control TagVisualization.

El objeto TagVisualization nos proporciona rápidamente un control de usuario que tiene como único objetivo posicionarse bajo los elementos etiquetados que toquen la pantalla. Como todos los controles de usuario, se basa en una parte XAML, donde especificamos la parte gráfica del control de usuario, y una parte en C#, donde especificamos la funcionalidad (por ejemplo, podemos programar un método que lance una animación en el TagVisualization, o un método para mostrar un mensaje).

Los objetos TagVisualization se pueden crear desde el menú de añadir elementos de Visual Studio:

Abrir la pantalla de "Añadir nuevo elemento"

Añadir el control de usuario "Tag Visualization"

Pero en realidad, un control TagVisualization son sirve de poco sin su respectivo TagVisualizer.

El control TagVisualizer.

Si un TagVisualization es el control de usuario que se posiciona bajo un contacto etiquetado, un TagVisualizer es el control que gestiona todos los TagVisualization que tenemos. Tiene varias funciones:

Determina el área de la pantalla que será sensible al posicionamiento de objetos etiquetados.
Discrimina entre los diferentes tipos de etiquetas, de forma que según indiquemos, muestra un TagVisualization o otro en función de la etiqueta del objeto.
Detecta los eventos de entrada y salida de los contactos. Estos eventos son especialmente útiles porque desde ellos podemos ejecutar funcionalidades del TagVisualization.

Mejor con un ejemplo.

Vamos a programar un pequeño ejemplo para ver más cláramente cómo funcionan ambos objetos. El ejemplo consistirá en una región de pantalla donde podremos posicionar un objeto etiquetado. Al posicionarlo aparecerá debajo un círculo, el cual se mostrará con una animación sencilla.

Creamos el proyecto y la pantalla principal.

Crearemos un proyecto de Surface con Visual Studio. Lo llamaremos “ContactosEtiquetados”. En lo particular, a mi me gusta cargarme la pantalla que viene por defecto y crearme la mía “Main.xaml”. Recordad que si hacéis esto, tenéis que cambiar el valor del atributo StartupUri en el archivo App.config.

En la pantalla inicial, no nos complicamos. Únicamente meteremos el TagVisualizer, y le daremos algun detalle gráfico para poder visualizarlo en pantalla:

Sólo destacar que al TagVisualizer le he asignado dos eventos: VisualizationAdded y VisualizationRemoved. Efectívamente, se lanzarán cuando entre y salga un contacto respectívamente. Tambien he asignado el evento Loaded a la SurfaceWindow.

Creamos el objeto TagVisualization.

Crear un objeto TagVisualization es sencillo: el propio Visual Studio lo hace desde la ventana de “Añadir nuevo elemento” (lo hemos visto antes).

En el nuevo control introduciremos dos gráficos y una grid. Los gráficos estarán dentro de la grid, y serán un círculo grande sin relleno y otro más pequeño con relleno. Éste último lo posicionaremos sobre el contorno del más grande. Por último, añadiremos un RotateTransform a la grid que contiene ambos círculos:

Gestión de los contactos etiquetados.

La gestión de los contactos que recibe el TagVisualizer se basa en objetos TagVisualizationDefinition. A un TagVisualizer se le añaden una o varias definiciones. Cada definición asociará el TagVisualizer con un TagVisualization y además nos permitirá discriminar los contactos según el valor de la etiqueta. Lo normal es crear las definiciones que necesitemos extendiendo la clase TagVisualizationDefinition. Por ejemplo, en nuestro caso sólo reaccionaremos a los contactos de tipo Identity. Creamos la clase ContactosEtiquetadosVisualizationDefinition.cs.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Surface.Presentation.Controls;
using Microsoft.Surface.Presentation;
using System.Windows;

namespace ContactosEtiquetados
{
    class ContactosEtiquetadosVisualizationDefinition : TagVisualizationDefinition
    {
        protected override bool Matches(TagData tag)
        {
            if (tag.Type == TagType.Identity) return true;
            else return false;
        }

        protected override Freezable CreateInstanceCore()
        {
            return new ContactosEtiquetadosVisualizationDefinition();
        }
    }
}

El método Matches es la clave para determinar qué contactos hay que tener en cuenta.

Ahora añadimos la definición al objeto TagVisualizer. Lo haremos en el evento Load de la ventana inicial:

        private void SurfaceWindow_Loaded(object sender, RoutedEventArgs e)
        {
            TagVisualizationDefinition definition = new ContactosEtiquetadosVisualizationDefinition();
            definition.Source = new Uri("TagVisualization.xaml", UriKind.Relative);
            definition.LostTagTimeout = 1000;
            Visualizer.Definitions.Add(definition);
        }

Comentamos un poco: La propiedad Source símplemente hace referencia al XAML del objeto TagVisualization. La propiead LostTagTimeOut define un tiempo de espera antes de “matar” al TagVisualization, en caso de que el contacto deje de estar en contacto con la pantalla. Dicho de otra forma, el TagVisualization no desaparecería hasta que el contacto no lleve más de un segundo perdido.

Programamos la animación del TagVisualization.

Para animar el control TagVisualization rescataremos un artículo que escribí sobre el tema hace un tiempo: Animar transformaciones en WPF con el método BeginAnimation. Aplicar la animación al TagVisualization es simple:

Primero, vamos a crear un método en el TagVisualization que inicie la animación:

private void StartAnimation()
{
    DoubleAnimation animacion = new DoubleAnimation();

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

    // La animaciÃ³n se repite continuamente
    animacion.RepeatBehavior = RepeatBehavior.Forever;

    this.Rotacion.BeginAnimation(RotateTransform.AngleProperty, animacion);
}

Ésta animación puede ser iniciada en el evento Loaded:

private void Visualization_Loaded(object sender, RoutedEventArgs e)
{
    this.StartAnimation();
}

¡Hemos acabado!

Con ésto ya podemos programar muchas respuestas interesantes a nuestros contactos etiquetados.

El ejemplo descargable lo tenéis aquí: Contactos etiquetados.

¡Nos vemos por Facebook!

Juanma — Thu, 21 Oct 2010 22:46:57 +0000

He creado una página en Facebook para darle un poco más de difusión al blog, así que desde hoy ya podéis ser fans y esas historias.

Realmente creo que no hacía falta, ya que el posicionamiento en Google no es malo y bueno, creo que los contenidos se propagan adecuadamente, pero tenía ganas de trastear un poco con el asunto.

Arriba a la izquierda, sobre el cuadro de búsqueda; he colocado el botón de Facebook para compartir los artículos. El desgraciado ha sido más difícil de posicionar de lo que esperaba.

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.

Vídeo de Rent a Car Surface by Bizzit

Juanma — Tue, 06 Jul 2010 21:28:47 +0000

Ya he hablado en mi blog algúna vez sobre la demo para Microsoft Surface que estábamos realizando en Bizzit.

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

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

Ocultar el texto de un input submit

Juanma — Fri, 11 Jun 2010 05:17:35 +0000

Ayer me surgió la necesidad de ocultar el texto de un Input Submit con CSS.

¿Es una locura?. No, porque mi botón tenía una imagen de fondo lo suficientemente descriptiva como para no tener texto.

Una opción podría ser dejar el atributo value vacío, pero necesitaba el value para poder discriminar después en el servidor (tenía más de un botón, y necesitaba saber cual se había pulsado). Además, siendo estrictos, el value no debería ser la solución a un problema gráfico.

En definitiva, la solución que encontré en esta entrada y que posteriormente apliqué consiste en este código CSS:

	input.hidden_text
	{
		/* Imagen de fondo */
		background: transparent url(“imagen.jpg”) left center no-repeat;   

		/* Tamaño de la imagen */
		width: 20px;
		height: 20px;

		text-indent: -9999px;
		border: none;
		color: transparent;

		/* Parche para IE  */
		text-transform: capitalize;
	}

Espero que os resulte útil.