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

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

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

Tipos de contactos.

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

Dedos.

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

Etiquetas.

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

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

Un Byte Tag

Un Identity Tag

Objetos.

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

Reconocer contactos sobre un elemento.

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

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

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

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

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

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

    </Grid>
</s:SurfaceUserControl>

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

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

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

Obtener información útil sobre los contactos.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            case TagType.Identity:

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

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

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

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

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

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

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

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

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

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

            case TagType.Identity:

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

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

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

Reconocer el mismo contacto en diferentes eventos.

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

Conocer los diferentes contactos sobre un elemento.

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

Hemos acabado.

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

Deteccion de contactos (VS 2010)

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

El primero, pensar que con echar un simple vistazo a un código podemos determinar si es o no es un buen código.

El segundo, pensar que lo anterior es un error.

En realidad, la primera impresión de un código es bastante válida. Cuando un código no nos convence a primera vista, es por que despide un “olor” poco convincente. Lo que vengo a decir, es que esto del olor de código existe y está mas o menos documentado. Sin embargo, no he encontrado nada en español sobre el tema, así que vamos allá:

¿Qué cosas provocan mal olor en nuestro código y como solucionarlas?

• Código duplicado. A primera vista ya podemos ver trozos de código demasiado parecidos. Probablemente deberíamos encontrar una forma de compartir ese código para no repetirlo por todo nuestro programa.
• Métodos demasiado largos. Cuando un método es demasiado largo, lo más seguro es que debamos dividirlo en más métodos más básicos. Eso hará nuestro código más comprensible y más sencillo de arreglar cuando falle (porque creeme, fallará).
• Clases demasiado largas. Un poco en la misma linea que lo anterior, es posible que necesites abstraer un poco más tu código, y dividir una clase en varias clases pequeñas.
• Envidia de características. Lo mismo te digo una cosa que te digo otra. Si notamos que una de nuestras clases usa excesívamente los métodos de otra, merece la pena cosiderar si realmente esas dos clases deberían estar separadas.
• Intimidad inapropiada. Una clase no debería depender de otras clases en según que aspectos de implementación críticos. Las clases deberían ser reutilizables y independientes. En estas situaciones tambien deberíamos plantearnos la fusión de las dos clases.
• Rechazo del legado. Una clase que sobreescribe un método heredado debería respetar el propósito inicial del método. Con esto quiero decir que no es lógico ni aceptable que un método que calcule raízes cuadradas se sobreescriba con un método que elimine acentos en una cadena de texto. No tienen nada que ver el uno con el otro. La pregunta que deberíamos hacernos ahora es: ¿realmente esta clase debería tener este padre y no otro?. Recordemos que la composición siempre es una solución válida.
• Clases perezosas. Hemos hablado de clases demasiado largas, pero ¿y las clases demasiado cortas?. Puede que debamos integrar su funcionalidad en otra clase.
• Métodos duplicados. ¿Realmente necesitamos ese método para elevar al cubo teniendo este que eleva al cuadrado?. Mucho mejor si hacemos un método capaz de elevar a n. Debemos evitar tener varios métodos con funcionalidades parecidas y buscar más métodos configurables con parámetros.
• Complejidad artificial. ¿Estamos ante un problema complicado o nosotros lo hemos vuelto complicado?. No tiene sentido forzar, por ejemplo, el uso de complejos patrones de diseño en problemas que realmente son tan sencillos que no los requieren.

Estas son algunas fuentes potenciales de problemas que podemos llegar a tener y que son fáciles de ver con un vistazo simple al código. El código puede, y debe; ser bonito.

Concretamente, puedes dotar una clase de la habilidad de obtener o transformar (o obtener y transformar) datos, o puedes dotarla de la habilidad de aplicar esos datos en el nivel más superior del proyecto. Ejemplificando: Puedes hacer una clase que se encargue de obtener datos de una base de datos, pero se debería programar otra clase con la intención de mostrar esos datos en pantalla. He visto códigos donde las clases tienen métodos para obtener y tratar información, y métodos distintos para aplicarla. Tampoco es una mala opción. Quizás un poco incómoda, pero también funcional.

Pero lo que no debe suceder nunca, es que un único método se encargue de obtener la información y de aplicarla. Podría pensarse que es más cómodo, y ciertamente lo es, siempre que nunca en la vida, jamás de los jamases, vayas a usar esa clase en otro proyecto, o tengamos la seguridad de que ese proyecto no va a sufrir ninguna modificación. Por supuesto, esa situación no existe. El cliente nunca se va a conformar con la primera versión acabada del proyecto (nunca), y tu jefe siempre te sugerirá (quizás con una mirada amenazadora) que reutilices el código de un proyecto anterior.

Resumiendo: una clase bien hecha debe cumplir ciertos puntos:

• Debe ser fácil de ampliar.
• Debe ser traspasable a otras aplicaciones de forma íntegra.
• Debe poder ser pasada a un colega, publicada a la comunidad, etc.

Salgo hoy con estas historias, porque después de una semana en modo hardcore developer he conseguido acabar (bueno, prácticamente acabar) el nuevo y espectacular diseño del blog (espero que os guste, seáis quienes seáis los que pasáis por aquí xD). Y entre las funciones de wordpress hay cada cosa… Las funciones devuelven código HTML listo para publicar en el mejor de los casos, de hecho, lo más normal es que directamente impriman la información en la página. Un desastre.

Por ejemplo, si llamas a la función que te permite obtener el listado de categorías, en vez de devolver los datos íntegros, o en su defecto el html ya montado; simplemente imprime el código en pantalla sin dar opción al programador de tratar los datos antes de publicarlos. Vamos, no tiene pies ni cabeza.

La intención no es mala, porque simplifica mucho el trabajo para diseñadores con pocos conocimientos de programación, pero el problema real es que no existe la posibilidad de obtener los datos íntegros antes de mostrarlos en pantalla.

Después de algunos meses con este blog, estoy viendo que wordpress es una maravilla, pero en este aspecto hay que suspenderlos y darles una colleja, para que se espabilen en nuevas versiones.