Almacenar credenciales de forma segura con PasswordVault

Un problema al que nos enfrentamos cuando tenemos que almacenar credenciales de nuestros usuarios en una aplicación móvil, es el como hacerlo de forma segura. Por muy seguro que un sistema afirme ser, siempre lo será tanto como su parte menos segura. Por lo que guardar el nombre y password de un usuario en los settings o en el almacenamiento local de nuestra aplicación sin cifrado de ningún tipo, es una negligencia gravísima. Bastará tener acceso al sistema de archivos por parte de un atacante para obtener esos datos.

Existen muchas formas de evitar esto. Y todas pasan de alguna forma por encriptar los datos almacenados. Quizás podríamos pensar que nos podríamos proteger simplemente calculando un hash del password y usar este hash para autentificar a nuestro usuario en el backend. Esto uede funcionar si el servicio de backend que usamos está bajo nuestro control o siendo de terceros admite esta opción. Pero en la gran mayoría de casos el backend nos pedirá un usuario y password. Incluso en el caso de poder usar el hash de un password, almacenarlo en texto plano junto al nombre de usuario es ya una información muy valiosa para un atacante.

En Windows 8.1 y Windows Phone 8.1 (Tanto Windows XAML como Silverlight) disponemos de un API llamada PasswordVault, que representa un almacén seguro para credenciales de usuario. Una aplicación solo podrá acceder a las credenciales almacenadas por ella misma y no a los de otras aplicaciones. Usarla además es realmente sencillo.

PasswordVault nos permite guardar las credenciales de un usuario mediante el método Add, pasándole una instancia de la clase PasswordCredential. El constructor de PasswordCredential nos permite indicar tres valores:

  • Resource, un nombre que identifica la credencial que se está creando.
  • UserName, el nombre del usuario… lógico no?
  • Password, el password.
PasswordCredential
var credential = new PasswordCredential(“AppName_userCredentials”, userEmail, userPassword);

Una vez creado, solo tenemos que pasarlo al método Add de nuestra instancia de PasswordVault:

PasswordVault Add method
PasswordVault pVault = new PasswordVault();
pVault.Add(credential);

Y ya hemos guardado nuestras credenciales de forma segura. Para recuperar los datos cuando los necesitemos de nuevo, podemos usar el método FindAllByResource. Este método recibe un parámetro con el nombre de recurso que indicamos al crear la credencial y devuelve una lista con todas las credenciales que coincidan con ese nombre:

FindAllByResource
PasswordVault pVault = new PasswordVault();
var credentials = pVault.FindAllByResource(resourceName);
return credentials.FirstOrDefault();

Es muy importante que, si existe la posibilidad de que al pedir las credenciales, estas no existan, envolvamos la llamada a FindAllByResource en un bloque Try/Catch. En vez de simplemente devolver nulo, el método falla con una excepción si no existen.

Tras obtener la credencial, podremos obtener directamente el nombre de usuario pero para poder acceder al password tendremos primero que usar el método RetrievePassword de la instancia de PasswordCredential con la que estemos trabajando.

RetrievePassword
var credential = credentials.First();
credential.RetrievePassword();

Tras esto podremos acceder al password almacenado usando la propiedad Password de PasswordCredential.

Por último, puede que en algún momento el usuario quiera que dejemos de almacenar sus credenciales, por lo que podremos usar el método Remove, para eliminarlas del PasswordVault.

PasswordVault Remove
var credentials = this.pVault.FindAllByResource(resourceName);
var credential = credentials.First();
if (credential != null)
    this.pVault.Remove(credential);

En este sentido es interesante tener en cuenta algo. Cuando desinstalemos la aplicación, las credenciales guardadas en el PasswordVault no serán eliminadas. Cuando guardamos algo en los settings o el almacenamiento local de nuestra aplicación, al desinstalar se elimina todo. Esto no ocurre con las credenciales guardadas en el PasswordVault, pues usan un almacenamiento central del sistema.

Y esto es todo! Usar PasswordVault es muy fácil y añade un extra de seguridad a nuestra aplicación, así que no hay excusa para no usarlo. Aquí os dejo una aplicación universal de ejemplo con el código MVVM y el servicio de credenciales compartido. Espero que os sea de utilidad.

Un saludo y Happy Coding!

[MATERIALES] Windows phone 8.1, MVVM, behaviors, animations y visual states.

El viernes 20 de Junio estuve con los chicos de RiojaDotNet en Logroño, dando una charla con Asier Tarancon sobre apps universales. Asier hizo una gran introducción a la plataforma y me allanó el terreno para hablar sobre como implementar MVVM en nuestras apps universales y como enriquecerlas con behaviors, animations y visual states.

Aquí os traigo los materiales de la misma. En primer lugar la presentación que usé. Es muy pequeña porque quise sobre todo usar Visual Studio para explicar las cosas:

 

Y a continuación los ejemplos de behaviors, animations y visual states.

Espero que os sean útiles.

Un saludo y Happy Coding!

[Windows Phone 8.1] Trio de ases: Behaviors, Animations y VisualStates (3)

Y llegamos al último artículo de esta serie, tras ver como trabajar con behaviors y animaciones, en esta ocasión vamos a hablar de los estados visuales.

Los VisualStates nos permiten definir diferentes estados para nuestra página o control para cambiar su apariencia e incluso su funcionalidad. Por ejemplo en una página donde el usuario puede ver un resumen de datos y tiene la opción de editarlos, podemos crear un VisualState de solo lectura y otro de edición, cambiando propiedades de los controles en cada uno de ellos para modificar la forma en la que el usuario interactúa con la página.

También, como vamos a ver en el ejemplo de este artículo, podemos crear estados visuales que modifiquen la interface de usuario dependiendo de la orientación del dispositivo. De esta forma podemos ofrecer al usuario la mejor experiencia en cada momento.

Los VisualStates usan animaciones para modificar los controles a los que quieren afectar y podemos usar behaviors para iniciar el proceso de cambio de uno a otro.

Por regla general, los VisualStates de una página se definirán en la primera Grid que contenga la página. Para ello incorporaremos el nodo, que debe ser el primero dentro de la Grid, VisualStateManager para definir los grupos y los estados de cada grupo:

VisualStateManager
<Grid>
    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name=“LayoutStates”>
            <VisualState x:Name=“Landscape”>

            </VisualState>
            <VisualState x:Name=“Portrait”>

            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>

</Grid>

Tras definir el nodo VisualStateManager.VisualStateGroups, definimos los grupos que necesitemos, en este caso uno. El nombre, LayoutStates, es libre y a nuestra elección. Por claridad deberíamos indicar un nombre descriptivo de la finalidad del grupo. En este caso este grupo contiene dos estados, Landscape y Portrait, nombres también a nuestra elección. Si quisiésemos tener otro grupo, podríamos ponerlo a continuación de este con sus correspondientes estados.

En este ejemplo, tenemos una lista de imágenes y queremos variar la forma de mostrarlas al usuario dependiendo de la orientación del dispositivo. Cuando estemos en horizontal, queremos usar un FlipView que haga uso de toda la pantalla. Por el contrario cuando la orientación sea vertical, queremos usar una GridView que muestre las imágenes en una cuadrícula. Así mismo, cuando estemos en vertical queremos que al hacer click en las imágenes aparezca un popup con la imagen seleccionada. Nuestro XAML quedaría más o menos así:

 

XAML
<GridView x:Name=“ListImages” ItemsSource=”{Binding Images}>
    <GridView.ItemTemplate>
        <DataTemplate>
            <Grid Width=“150” Height=“150” Margin=“0”>
                <Image Stretch=“UniformToFill” Source=”{Binding }/>
            </Grid>
        </DataTemplate>
    </GridView.ItemTemplate>
    <i:Interaction.Behaviors>
        <core:EventTriggerBehavior EventName=“SelectionChanged”>
            <core:GoToStateAction StateName=“BigImage”/>
        </core:EventTriggerBehavior>
    </i:Interaction.Behaviors>
</GridView>

<Grid x:Name=“Popup” Visibility=“Collapsed” Background=“#AA555555” VerticalAlignment=“Stretch” HorizontalAlignment=“Stretch”>
    <Image Margin=“40” Stretch=“Uniform” Source=”{Binding SelectedItem, ElementName=ListImages}>
    </Image>
    <i:Interaction.Behaviors>
        <core:EventTriggerBehavior EventName=“Tapped”>
            <core:GoToStateAction StateName=“NormalState”/>
        </core:EventTriggerBehavior>
    </i:Interaction.Behaviors>
</Grid>

<FlipView x:Name=“flipImages” Visibility=“Collapsed” ItemsSource=”{Binding Images} SelectedItem=”{Binding SelectedItem, ElementName=ListImages}>
    <FlipView.ItemTemplate>
        <DataTemplate>
            <Image Stretch=“Uniform” Source=”{Binding }></Image>
        </DataTemplate>
    </FlipView.ItemTemplate>
</FlipView>

 

Como vemos, simplemente tenemos todos los controles necesarios: un GridView, una Grid llamada Popup y por último un FlipView. Por defecto tanto el popup como el FlipView tienen su visibilidad establecida a Collapsed. Lo que vamos a hacer es, en cada VisualState, mostrar u ocultar los controles que nos interesen en cada momento:

VisualState Landscape
<VisualState x:Name=“Landscape”>
    <Storyboard>
        <ObjectAnimationUsingKeyFrames Storyboard.TargetName=“ListImages” Storyboard.TargetProperty=“Visibility”>
            <DiscreteObjectKeyFrame KeyTime=“0:0:0” Value=“Collapsed”/>
        </ObjectAnimationUsingKeyFrames>
        <ObjectAnimationUsingKeyFrames Storyboard.TargetName=“flipImages” Storyboard.TargetProperty=“Visibility”>
            <DiscreteObjectKeyFrame KeyTime=“0:0:0” Value=“Visible”/>
        </ObjectAnimationUsingKeyFrames>
    </Storyboard>
</VisualState>

 

VisualState Portrait
<VisualState x:Name=“Portrait”>
    <Storyboard>
        <ObjectAnimationUsingKeyFrames Storyboard.TargetName=“ListImages” Storyboard.TargetProperty=“Visibility”>
            <DiscreteObjectKeyFrame KeyTime=“0:0:0” Value=“Visible”/>
        </ObjectAnimationUsingKeyFrames>
        <ObjectAnimationUsingKeyFrames Storyboard.TargetName=“flipImages” Storyboard.TargetProperty=“Visibility”>
            <DiscreteObjectKeyFrame KeyTime=“0:0:0” Value=“Collapsed”/>
        </ObjectAnimationUsingKeyFrames>
    </Storyboard>
</VisualState>

 

Así, en el caso del VisualState Landscape, cambiamos la visibilidad del GridView a Collapsed y la del FlipView a Visibile. En el Portrait lo contrario, mostramos el GridView y ocultamos el FlipView.

¿Y como lanzamos cada VisualState? Tenemos que hacerlo manualmente. Detectar el cambio de orientación y cambiar al VisualState que corresponda. Aquí es donde los behaviors vienen en nuestra ayuda. En concreto vamos a servirnos del Behavior DataTriggerBehavior. En nuestra ViewModel vamos a acceder a la clase DisplayInformation, que nos ofrece la propiedad CurrentOrientation y el evento OrientationChanged. Analizando los datos que nos ofrecen vamos a exponer una propiedad llamada IsLandscape:

DisplayInformation
public VMMain()
{
    var dInfo = DisplayInformation.GetForCurrentView();
    if (dInfo.CurrentOrientation == DisplayOrientations.Landscape || dInfo.CurrentOrientation == DisplayOrientations.LandscapeFlipped)
        IsLandscape = true;
    else
        IsLandscape = false;

    dInfo.OrientationChanged += dInfo_OrientationChanged;
}

Luego en XAML, usaremos el DataTriggerBehavior para ver si esta propiedad es true, momento en el que usaremos el GoToStateAction para cambiar al estado Landscape, o false, para cambiar al estado Portrait:

DataTriggerBehavior
<i:Interaction.Behaviors>
    <core:DataTriggerBehavior Binding=”{Binding IsLandscape} ComparisonCondition=“Equal” Value=“true”>
        <core:GoToStateAction StateName=“Landscape”/>
    </core:DataTriggerBehavior>
    <core:DataTriggerBehavior Binding=”{Binding IsLandscape} ComparisonCondition=“Equal” Value=“false”>
        <core:GoToStateAction StateName=“Portrait”/>
    </core:DataTriggerBehavior>
</i:Interaction.Behaviors>

Y Voila! Si ejecutamos nuestra aplicación en el simulador de Windows 8.1 o el emulador de Windows Phone 8.1, veremos que al cambiar la orientación, automáticamente cambia la apariencia de nuestra aplicación. Además, como todo lo visto en los artículos anteriores, los VisualStates son también totalmente compatibles entre Windows Phone y Windows Store, por lo que el ejemplo incluido en este artículo es una aplicación universal que comparte el 100% del código C# y XAML usado:

image

Las aplicaciones de los VisualStates son muchas. Pero lo más importante es que nos ofrecen una forma sencilla de cambiar el aspecto de nuestra página. De echo, si editas la plantilla por defecto de cualquier control de XAML, verás que usa VisualStates para definir estados como Focus, Tapped, o Selected.

Y con esto llegamos al final de este artículo y de la serie. Espero que haya sido útil para ver una forma nueva de trabajar con el aspecto visual de nuestra página, lanzar acciones en respuesta a las del usuario y crear bonitas animaciones. Como siempre, aquí puedes descargar este último ejemplo para usarlo como referencia.

Un saludo y Happy Coding!!

 

[Windows Phone 8.1] Trio de ases: Behaviors, Animations y VisualStates (2)

En el artículo anterior de esta serie hablamos sobre el behavior SDK, una herramienta que nos permitía realizar ciertas acciones directamente en XAML y sin necesidad de escribir código C# en respuesta a cambios de datos o lanzamiento de eventos. En este, vamos a ver otra herramienta que XAML pone a nuestra disposición: las animaciones.

En todo desarrollo existe algo en lo que debemos poner toda nuestra atención: fluidez. Que nuestra aplicación se comporte rápido y de forma fluida es muy importante. Pero muchas veces, podemos dividir la fluidez en dos conceptos: fluidez real y fluidez percibida. Y contrariamente a lo que pudiésemos pensar, es la segunda, la fluidez percibida, la más importante. Por su puesto que es muy importante que nuestra aplicación sea fluida y rápida. Pero siempre existirán puntos, como ciertos procesos de carga, que serán inevitables. Si aderezamos esos momentos con una distracción para el usuario, desviando su atención del tiempo exacto que tardamos en cargar datos, conseguiremos que este perciba la aplicación como más fluida y rápida de lo que realmente es.

Pongamos un ejemplo. Imaginad que tras cargar la página principal de nuestra aplicación y mostrarla en pantalla debemos llamar a un servicio web para obtener ciertos datos necesarios. aquí el truco para dar fluidez a la aplicación es muy sencillo: Primero mostramos la página con todo el contenido estático que podamos, para a continuación en otro hilo cargar los datos del servicio. La página principal se carga rápido, la interface no se bloquea. Podemos decir que nuestra aplicación es fluida. Pero realmente, existe un ligero desfase, en el que el usuario ve la barra de carga de la aplicación, quizás durante 500 milisegundos o un segundo. Aunque se ha cargado todo sin bloquear nada, el usuario ha tenido que esperar casi un segundo para poder empezar a usar nuestra aplicación. Bien, si sabemos que ese tiempo oscila entre 500 y 1000 milisegundos, aprovechémoslo. Por ejemplo podríamos hacer que al cargarse la pantalla, los elementos estáticos en vez de aparecer ya posicionados, vayan apareciendo en una sucesión, tener una imagen como la splash screen sobre la página que animemos para que desaparezca con un fade out, o algo por el estilo. Si ajustamos esta animación a 750 milisegundos por ejemplo, por debajo podemos al mismo tiempo pedir los datos al servicio. El resultado es que: En el mejor de los casos cuando la animación acabe la página estará operativa. En el peor de los casos quizás el usuario tendrá que esperar unos 250 milisegundos a obtener todo. Pero fijaros que hemos pasado de una espera de 500 a 1000 milisegundos a otra de entre 0 y 250 milisegundos. No hemos hecho que nuestra aplicación sea más rápida, pero si hemos mejorado la fluidez percibida. Todo esto gracias además a que las animaciones en XAML son totalmente asíncronas, mientras no bloqueemos el hilo de interface de usuario, podemos ejecutar código al mismo tiempo que lanzamos una animación. ¿Qué os parece el truco?

Además de esta utilidad “práctica”, las animaciones también cumplen un papel claramente estético. usar una pequeña y simple animación para mostrar un elemento o resaltarlo, como veremos hoy, pueden mejorar el aspecto de nuestra aplicación muchísimo. Así que empecemos a meternos en faena, viendo como crear animaciones en Windows Phone 8.1, Windows 8.1 y apps universales.

Storyboard, Animations y KeyFrames.

Toda animación en XAML se encuadra dentro de un elemento Storyboard. El elemento Storyboard define la duración, el auto rebobinado, el comportamiento de repetición y más cosas mediante varias propiedades:

  • Duration. Nos permite expresar el tiempo como un TimeSpan (hh:mm:ss.ms) se trata del tiempo total que va a durar la animación en completarse.
  • BeginTime. Expresa, también como un TimeSpan, el tiempo a esperar, una vez comenzada la ejecución de la animación, antes de ejecutar el primer frame. Es muy útil si queremos lanzar y sincronizar o encadenar distintas animaciones.
  • FillBehavior. Aporta dos opciones: HoldEnd y Stop. Indica el comportamiento a llevar a cabo al terminar la animación. HoldEnd es el valor por defecto y mantiene la animación en el último cuadro de la misma. Stop para la animación y vuelve al estado inicial.
  • AutoReverse: indica si al terminar se debe ejecutar la animación al revés automáticamente.
  • RepeatBehavior: Permite especificar el comportamiento de repetición: Puede contener un número que indica el número de veces que se repetirá la animación, 0 para nunca, o la palabra Forever, que indica que nunca dejará de repetirse a no ser que la paremos explícitamente.
  • SpeedRatio. La velocidad de reproducción. Podemos considerarlo como un avance rápido de la animación.

La clase Storyboard también contiene dos métodos: Begin y Pause, que nos permiten comenzar o parar la reproducción de la animación. Así mismo dispondremos del evento Completed para saber cuando ha terminado. En XAML, Un Storyboard con una duración de 2 segundos, 1 repetición y auto rebobinado tendría este aspecto:

Sample storyboard
<Storyboard x:Key=“SampleStoryboard” RepeatBehavior=“1” Duration=“0:0:2” AutoReverse=“True”>
</Storyboard>

Al declarar un Storyboard usamos el identificador x:Key. Esto se debe a que una Storyboard es un recurso, ya sea de la aplicación, de la página o de un control.

Lo siguiente que tenemos que hacer es definir la colección de animaciones a usar en el Storyboard. Disponemos de diferentes tipos de animaciones, dependiendo del tipo de la propeidad que deseemos modificar. De cada tipo existen dos variantes: Una variante simple, que nos permite indicar un valor final y una duración y una variante más completa que nos permite definir una colección de cuadros para la animación:

  • DoubleAnimation / DoubleAnimationUsingKeyFrames, para animar propiedades numéricas.
  • ColorAnimation / ColorAnimationUsingKeyFrames, para animar propiedades basadas en colores.
  • PointAnimation / PointAnimationUsingKeyFrames, para animar propiedades basadas en puntos.
  • ObjectAnimationUsingKeyFrames, para animar cualquier otro tipo de propiedad.

Dentro de la animación usaremos las propiedades Storyboard.TargetName y Storyboard.Property para definir el elemento y la propiedad que deseamos animar. En este sentido debemos tener en cuenta que, en un mismo Storyboard no podremos definir dos animaciones distintas para una misma propiedad de un mismo elemento. Esto no es problema puesto que al poder usar KeyFrames, dentro de una animación podemos definir tantos cambios como queramos. Por ejemplo podemos animar la propiedad Opacity de un elemento de la siguiente forma usando una DoubleAnimationUsingKeyFrames:

DoubleAnimationUsingKeyFrames
<Storyboard x:Key=“SampleStoryboard” RepeatBehavior=“1” Duration=“0:0:2” AutoReverse=“True”>
    <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“ScoreCard” Storyboard.TargetProperty=“Opacity”>
    </DoubleAnimationUsingKeyFrames>
</Storyboard>

A continuación ya solo nos queda definir los frames de la animación. Cada frame es un instante en el tiempo de la animación en el que definimos un valor para la propiedad que estamos animando. Cada tipo de animación soporta cuatro tipos de frames:

  • Linear, que usa una interpolación lineal entre frames para animar la propiedad.
  • Discrete, que usa una interpolación discreta entre frames para animar la propiedad.
  • Easing, que usa una función de easing para modificar la interpolación entre frames.
  • Spline que usa un Spline para definir la interpolación entre frames.

Normalmente utilizaremos Lineal y Easing dependiendo de si queremos una animación uniforme o aplicar efectos de rebote, aceleración o deceleración entre cuadros. El uso es el mismo en ambos casos, debemos indicar el tiempo dentro del Storyboard en el que deseamos ejecutar cada frame y el valor que debe tener la propiedad animada en ese momento. A mayores, en el caso del Easing podremos indicar una función de easing para aplicar el efecto deseado:

 

LinearDoubleKeyFrame
<Storyboard x:Key=“SampleStoryboard” RepeatBehavior=“1” Duration=“0:0:2” AutoReverse=“True”>
    <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“ScoreCard” Storyboard.TargetProperty=“Opacity”>
        <LinearDoubleKeyFrame KeyTime=“0:0:2” Value=“1”/>
    </DoubleAnimationUsingKeyFrames>
</Storyboard>

 

 

EasingDoubleKeyFrame
<Storyboard x:Key=“SampleStoryboard” RepeatBehavior=“1” Duration=“0:0:2” AutoReverse=“True”>
    <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“ScoreCard” Storyboard.TargetProperty=“Opacity”>
        <EasingDoubleKeyFrame KeyTime=“0:0:2” Value=“1”>
            <EasingDoubleKeyFrame.EasingFunction>
                <CubicEase EasingMode=“EaseOut”/>
            </EasingDoubleKeyFrame.EasingFunction>
        </EasingDoubleKeyFrame>
    </DoubleAnimationUsingKeyFrames>
</Storyboard>

 

Y ya tenemos lista nuestra animación. En ambos casos animamos la propiedad Opacity de un elemento llamado ScoreCard hasta un valor de 1. No indicamos el valor inicial de la propiedad, así la animación tomará como valor inicial el que tenga la propiedad en el momento en que se ejecute la animación. En el caso del EasingDoubleKeyFrame además definimos la función de easing, un Cubic ease en modo out. Esto hace que la animación haga un efecto de aceleración.

Como hemos mencionado antes, dentro de un Storyboard podemos definir distintas animaciones para conseguir efectos más complejos. Incluso podemos combinar distintas animaciones (jugando con la propiedad BeginTime). En el ejemplo adjunto a este artículo tenemos una animación que cambia el color y la escala de un TextBlock con un número y además muestra unos rayos girando a toda pantalla:

image

Los rayos no aparecen de golpe, se anima el tamaño y la opacidad para que aparezcan expandiéndose y luego girando. El código de la animación completa es el siguiente:

Rays animation
<Page.Resources>
    <Storyboard x:Key=“ShowSuccess”>
        <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“Rays” Storyboard.TargetProperty=“Opacity”>
            <EasingDoubleKeyFrame KeyTime=“0:0:0.5” Value=“.5”>
                <EasingDoubleKeyFrame.EasingFunction>
                    <CubicEase EasingMode=“EaseOut”/>
                </EasingDoubleKeyFrame.EasingFunction>
            </EasingDoubleKeyFrame>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“Rays” Storyboard.TargetProperty=“(UIElement.RenderTransform).(CompositeTransform.ScaleY)”>
            <EasingDoubleKeyFrame KeyTime=“0:0:0.5” Value=“15”>
                <EasingDoubleKeyFrame.EasingFunction>
                    <CubicEase EasingMode=“EaseOut”/>
                </EasingDoubleKeyFrame.EasingFunction>
            </EasingDoubleKeyFrame>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“Rays” Storyboard.TargetProperty=“(UIElement.RenderTransform).(CompositeTransform.ScaleX)”>
            <EasingDoubleKeyFrame KeyTime=“0:0:0.5” Value=“15”>
                <EasingDoubleKeyFrame.EasingFunction>
                    <CubicEase EasingMode=“EaseOut”/>
                </EasingDoubleKeyFrame.EasingFunction>
            </EasingDoubleKeyFrame>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“ScoreCard” Storyboard.TargetProperty=“(UIElement.RenderTransform).(CompositeTransform.ScaleX)”>
            <EasingDoubleKeyFrame KeyTime=“0:0:0.3” Value=“1.2”>
                <EasingDoubleKeyFrame.EasingFunction>
                    <CubicEase EasingMode=“EaseOut”/>
                </EasingDoubleKeyFrame.EasingFunction>
            </EasingDoubleKeyFrame>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“ScoreCard” Storyboard.TargetProperty=“(UIElement.RenderTransform).(CompositeTransform.ScaleY)”>
            <EasingDoubleKeyFrame KeyTime=“0:0:0.3” Value=“1.2”>
                <EasingDoubleKeyFrame.EasingFunction>
                    <CubicEase EasingMode=“EaseOut”/>
                </EasingDoubleKeyFrame.EasingFunction>
            </EasingDoubleKeyFrame>
        </DoubleAnimationUsingKeyFrames>
        <DoubleAnimationUsingKeyFrames Storyboard.TargetName=“ScoreCard” Storyboard.TargetProperty=“Opacity”>
            <EasingDoubleKeyFrame KeyTime=“0:0:0.3” Value=“1”>
                <EasingDoubleKeyFrame.EasingFunction>
                    <CubicEase EasingMode=“EaseOut”/>
                </EasingDoubleKeyFrame.EasingFunction>
            </EasingDoubleKeyFrame>
        </DoubleAnimationUsingKeyFrames>
    </Storyboard>
    <Storyboard x:Key=“AnimateRays” RepeatBehavior=“Forever” BeginTime=“0:0:0.1” FillBehavior=“HoldEnd” >
        <DoubleAnimationUsingKeyFrames EnableDependentAnimation=“True” Storyboard.TargetName=“Rays” Storyboard.TargetProperty=“(UIElement.RenderTransform).(CompositeTransform.Rotation)”>
            <LinearDoubleKeyFrame KeyTime=“0:0:12” Value=“500”/>
        </DoubleAnimationUsingKeyFrames>
    </Storyboard>
</Page.Resources>

Quizás lo más extraño de esta animación es la forma de definir las propiedades. en vez de usar una propiedad del elemento estamos usando una transformación para poder rotarlo o escalarlo, por eso la animación se define como (UIElement.RenderTransform).(CompositeTransform.ScaleY):

  • (UIElement.RenderTransform) Aquí indicamos que de un UIElement (Todos los elementos en XAML heredan de la clase base UIElement), deseamos acceder a su propiedad RenderTransform.
  • (CompositeTransfrom.ScaleY) indicamos que dentro de la propiedad RenderTransform tenemos definido un CompositeTransform y que deseamos animar la propiedad ScaleY del composite transform.

En el TextBlock ScoreCard, definimos el RenderTransform de la siguiente forma:

CompositeTransform
<TextBlock x:Name=“ScoreCard” Text=”{Binding ScoreValue, Mode=TwoWay} FontSize=“64” Width=“130” Height=“70”
           TextAlignment=“Center” FontWeight=“Bold” Grid.Row=“1” Opacity=“.5” VerticalAlignment=“Center”
           HorizontalAlignment=“Center”>
    <TextBlock.RenderTransform>
        <CompositeTransform CenterX=“65” CenterY=“35” ScaleX=“1” ScaleY=“1”/>
    </TextBlock.RenderTransform>
</TextBlock>

Por último, solo nos queda iniciar las animaciones en el momento justo. Aquí es donde entran en juego los behaviors que explicamos en el artículo anterior. En este caso podemos hacer uso de la acción ControlStoryboardAction del namespace Microsoft.Xaml.Interaction.Media. Como disparador, podemos usar el click de un botón:

ControlStoyboardAction (1)
<Button Content=“play”>
    <i:Interaction.Behaviors>
        <core:EventTriggerBehavior EventName=“Tapped”>
            <media:ControlStoryboardAction ControlStoryboardOption=“Play” Storyboard=”{StaticResource ShowSuccess}/>
            <media:ControlStoryboardAction ControlStoryboardOption=“Play” Storyboard=”{StaticResource AnimateRays}/>
        </core:EventTriggerBehavior>
    </i:Interaction.Behaviors>
</Button>

Simplemente indicamos el evento, Tapped, y lo que queremos hacer con cada Storyboard (Play, Pause, Stop…) y por último el Storyboard afectado y listo! Pero pensemos por un momento, que queremos mostrar esta animación cuando el usuario completa el 100% de una tarea o llega a un hito concreto en nuestra aplicación. Para esto, podemos usar el disparador basado en datos (DataTiggerBehavior). Lo podemos definir por ejemplo en el TextBlock ScoreCard:

ControlStoryboardAction(2)
<TextBlock x:Name=“ScoreCard” Text=”{Binding ScoreValue, Mode=TwoWay} FontSize=“64” Width=“130” Height=“70”
           TextAlignment=“Center” FontWeight=“Bold” Grid.Row=“1” Opacity=“.5” VerticalAlignment=“Center”
           HorizontalAlignment=“Center”>
    <TextBlock.RenderTransform>
        <CompositeTransform CenterX=“65” CenterY=“35” ScaleX=“1” ScaleY=“1”/>
    </TextBlock.RenderTransform>
    <i:Interaction.Behaviors>
        <core:DataTriggerBehavior Binding=”{Binding ScoreValue} ComparisonCondition=“GreaterThanOrEqual” Value=“100”>
            <media:ControlStoryboardAction ControlStoryboardOption=“Play” Storyboard=”{StaticResource ShowSuccess}/>
            <media:ControlStoryboardAction ControlStoryboardOption=“Play” Storyboard=”{StaticResource AnimateRays}/>
        </core:DataTriggerBehavior>
    </i:Interaction.Behaviors>
</TextBlock>

En este caso, indicamos al DataTriggerBehavior la propiedad que nos interesa de nuestra ViewModel (ScoreValue), la condición de comparación que debe cumplir (GreaterThanOrEqual) y el valor contra el que compararlo (100 en este caso).

En nuestra ViewModel, simplemente incrementamos la propiedad y notificamos el cambio:

ScoreValue
public int ScoreValue
{
    get { return this.scoreValue; }
    set
    {
        this.scoreValue = value;
        RaisePropertyChanged();
    }
}

Sin tener que escribir ningún código extra, cuando la propiedad ScoreValue llegue a 100, se ejecutará la animación ShowSuccess y AnimateRays. Como podemos observar, este último método nos ofrece la gran ventaja de hacer que nuestras vistas sean más ricas y reaccionen de forma animada a los cambios de los datos de nuestras ViewModels, abriendo un gran abanico de posibilidades para nuestra UI.

Por supuesto, algo a tener muy en cuenta es que, al igual que pasa con los behaviors, el sistema de animación es totalmente universal y compartido entre Windows phone y Windows store. De echo, todo el código de este artículo está compartido en un proyecto universal: la página, las animaciones y las viewmodels. No hay ni una sola línea de código C# o XAML en los proyectos específicos de la plataforma.

Y hasta aquí llega este segundo artículo. En el próximo colocaremos la última pieza de este trio de ases, los VisualStates, que nos permitirán crear páginas totalmente adaptables al momento, datos, situación… Pero para eso todavía os haré esperar un poco más. Mientras tanto, podéis descargaros de aquí el código completo y funcional de este artículo y ejecutarlo para ver lo bien que quedan las animaciones y lo sencilla que es hacerlas.

Un saludo y Happy Coding!!

[Windows Phone 8.1] Trio de ases: Behaviors, Animations y VisualStates (1)

Hola a todos!

Hoy vamos a comenzar a dar un repaso a un trio clásico de XAML que nos ayudará a crear mejores apps tanto para Windows Phone 8.1 como para Windows Store y Universal Apps. Hablo sin duda del equipo formado por los behaviors, las animaciones y los visual states.

Behaviors

Los behaviors (o comportamientos, si queréis traducirlo) nos permiten agregar cierta inteligencia a nuestro XAML para que realice acciones sin tener que escribir código para ello. Con Windows 8.1 se introdujo una extensión llamada Behaviors SDK, que ahora tenemos disponible también en Windows Phone 8.1, exactamente con la misma funcionalidad.

Podríamos dividir su uso en dos grandes bloques. Por un lado tenemos los triggers, que nos permiten definir la situación bajo la cual nuestros behaviors deben ser ejecutados. Por otro tenemos los behaviors y las activities propiamente dichos, que nos permiten definir qué hacer cuando se active el trigger.

En cuanto a triggers, tenemos los siguientes tipos:

  • DataTriggerBehavior. Este trigger nos permite ejecutar behaviors basándonos en datos para definir cuando comenzar la ejecución. Dispone de varias propiedades para definir el momento del lanzamiento:
    • Binding: Nos permite definir un enlace a una propiedad de otro objeto/ViewModel para usar su valor como base de la ejecución.
    • ComparisonCondition: Se trata de un enumerado en el que podemos definir como observar el valor de binding: Equal, GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual y NotEqual.
    • Value: el valor contra el que comparar el Binding.
  • EventTriggerBehavior. Nos permite definir un evento, que al lanzarse, ejecutará nuestros behaviors. Dispone de una propiedad EventName, donde podremos definir el nombre del evento que queremos escuchar y SourceObject, donde podremos definir el objeto de origen del evento, en caso de que sea distinto del objeto que contiene al trigger.

Y por el lado de los behaviors, encontramos los siguientes:

  • IncrementalUpdateBehavior. Un gran desconocido pero muy útil, sobre todo si trabajamos con grandes listas. Dentro de un DataTemplate de un ListView o GridView, nos permite definir diferentes “fases” de carga de los controles que lo componen. De esta forma, al hacer scroll, la carga de los diferentes elementos y su visualización se realizará en secuencia. Por ejemplo, podemos tener una DataTemplate que muestre un texto y una foto. Con este behavior, en su propiedad Phase, podemos  establecer la fase 1  al texto y la 2 a la imagen. Al hacer scroll, la lista mostrará primero los textos y a continuación cargará la imagen, lo que nos dará mayor fluided.
  • CallMethodAction. Como su nombre bien indica, nos permite ejecutar un método. Contiene una propiedad MethodName, donde podemos definir el nombre del método a ejecutar y una propiedad TargetObject, donde podremos definir un enlace a datos al objeto que contiene el método. Importante tener en cuenta que el método debe ser público para poder ejecutarlo.
  • GoToStateAction. Nos permite cambiar nuestro VisualState actual, definiendo el nombre del estado nuevo en la propiedad StateName, el objeto que lo contiene en la propiedad TargetObject y si deseamos usar transiciones entre el estado actual y el nuevo, con la propiedad UseTransitions. Más adelante cuando examinemos los VisualStates, veremos la potencia de este behavior.
  • InvokeCommandAction. Ejecuta el comando indicado. Disponemos de una propiedad Command, donde podemos definir el comando al igual que haríamos en un elemento Button y CommandParameter, que nos permite definir un parámetro.
  • NavigateToPageAction. Nos permite iniciar la navegación a una página. En la propiedad TargetPage debemos indicar el nombre cualificado completo de la clase de la página a la que queremos navegar, mientras que la propiedad Parameter nos permite indicar un parámetro que se enviará a dicha página.
  • ControlStoryboardAction. Como su nombre bien indica, este behavior nos ayudará a controlar una Storyboard, que como veremos más adelante es la base de cualquier animación en XAML. Dispone de una propiedad ControlStoryboardOption, donde podremos definir el tipo de acción que deseamos realizar: Play, Pause, Resume, SkipToFill, Stop, TogglePlayPause… También disponemos de la propiedad Storyboard, donde podremos indicar la Storyboard que deseamos controlar.
  • PlaySoundAction. Reproducción de sonido, dispone de una propiedad Source, donde definiremos el path del archivo de sonido a reproducir y una propiedad Volume, donde podremos definir el volumen de reproducción.

Como podemos ver, si combinamos los distintos tipos de behaviors con los tiggers, disponemos de una amplia gama de acciones a realizar bajo diferentes condiciones sin necesidad de añadir código C#. Podemos poner como ejemplo:

  • Ejecutar una animación cuando una propiedad boolean de nuestra ViewModel sea True.
  • Navegar a una página distinta cuando el usuario haga click en una imagen.
  • Reproducir un sonido al cambiar el elemento seleccionado de una lista.
  • Invocar a un comando o un método cuando cierto número de elementos haya sido cargado.
  • Cambiar el VisualState en respuesta a un cambio en los datos de nuestra ViewModel.

Bien, ¿Y como se usan? Primero debemos añadir una referencia al Behavior SDK que se incluye por defecto para Windows Phone 8.1 y Windows Store 8.1. Para ello solo tendremos que pulsar el botón derecho sobre nuestro proyecto, seleccionar Add Reference e ir al nodo de Extensions y marcar la extensión “Behaviors SDK (XAML)” como podemos ver en la imagen a continuación:

image

Una vez hecho esto, tendremos que añadir los namespaces Microsoft.Xaml.Interactivity, Microsoft.Xaml.Interaction.Core y Microsoft.Xaml.Interaction.Media a nuestra página o user control:

Namespaces
xmlns:i=“using:Microsoft.Xaml.Interactivity”
xmlns:core=“using:Microsoft.Xaml.Interactions.Core”
xmlns:media=“using:Microsoft.Xaml.Interactions.Media”

Y ya podremos empezar a usar los behaviors. Por ejemplo, Si tenemos dos paginas en nuestro proyecto, MainPage y SecondaryPage, podemos usar el behavior NavigateToPageAction en conjunción con el trigger EventTriggerBehavior para navegar de MainPage a SecondaryPage al hacer tap sobre una imagen:

NavigateToPageAction
<Grid>
    <Image Source=“/assets/picture.jpg” Width=“300”>
        <i:Interaction.Behaviors>
            <core:EventTriggerBehavior EventName=“Tapped”>
                <core:NavigateToPageAction TargetPage=“BehaviorsSample.SecondaryPage”/>
            </core:EventTriggerBehavior>
        </i:Interaction.Behaviors>
    </Image>
</Grid>

La utilización es muy simple y siempre igual para todos los behaviors. Dentro de un elemento definimos un hijo de tipo Interaction.Behaviors, que se encuentra en el namespace Microsoft.Xaml.Interactivity, a continuación el trigger a usar, definido en Microsoft.Xaml.Interactions.Core y por último la acción a realizar por el behavior.

Además, como son exactamente iguales en Windows Store y Windows Phone, podemos compartir el XAML donde los usemos en la carpeta shared de un proyecto universal sin problemas.

En el siguiente artículo de la serie, veremos las animaciones y volveremos a hablar de los behaviors y los triggers, como una fantástica forma de lanzar animaciones basándonos en datos y eventos, sin tener que escribir código extra para manejarlas.

Por ahora, aquí podréis descargar el ejemplo de hoy para que empecéis a practicar con los behaviors y ver la potencia que encierran. Como en el ejemplo, ser capaces de integrar en vuestras aplicaciones navegación, basada en eventos, sin tener que crear un servicio de navegación, comandos ni eventos.

Un saludo y Happy Coding!