[Universal Apps] Monetización con Fortumo Mobile Payments

Hola a todos!

Después de un descanso de vacaciones y escribir algo menos de lo normal para dedicar tiempo a otros proyectos… aquí vuelvo a la carga. Además, con uno de los temas que más nos interesan a los devs… ¡Como ganar dinero!.

Bueno, en este caso concreto, veremos realmente como hacer más fácil al usuario gastarse el dinero. Por defecto, podemos integrar de forma muy sencilla las APIs de In App Purchase de WinRT en nuestras aplicaciones universales. El único problema, por buscar alguno, es que el método de pago será una tarjeta de crédito asociada a la cuenta de la tienda. En algunos países, Microsoft ya soporta pagos con el operador móvil, pero son los menos.

El echo es que mucha gente no gusta de incluir una tarjeta de crédito en su cuenta de la tienda y en un gran número de países, no todo el mundo tiene acceso a una. Esto puede crear una situación, anecdótica para el usuario, pero muy preocupante para nosotros: El usuario quiere pagarnos, pero ¡NO PUEDE!

Es curioso, pero es un problema… en el que nadie suele pensar. Desarrollas tu app, pones opciones de pago y la lanzas al mercado. Luego en las analíticas ves que mucha gente presiona el botón de quitar publicidad o de comprar items… pero en la tienda, tus compras reales son mucho menores… Y piensas que es que la gente se ha arrepentido (que seguro que un porcentaje lo ha hecho). Pero la realidad es que hay una parte de esa gente, que ha tenido que cancelar la operación por que no le dabas opciones validas con las que pagar. Creo que es algo, que pocos se plantean, aunque después de pensar en ello 5 minutos digas, ¡Como lo he podido pasar por alto!

Lo que si que tiene todo el mundo, o al menos la gran mayoría, que posee un smartphone es una tarjeta SIM y un contrato (o saldo prepago) con una operadora. De esta forma, si encontrásemos la forma de que el usuario nos pagase con su móvil directamente, todos podrían pagar. Este es el momento en el que alguien podría decir… eh espera, Microsoft soporta pago por operador en Windows Phone. Si y no:

  • Es verdad que Microsoft soporta pago por operador, solo en 37 países de los 191 donde se encuentra presente la tienda.
  • En cada país solo soporta pagos si el operador de tu SIM está adherido. Por ejemplo en España soporta pagos si tu operador es Movistar o Vodafone. Si es Yoigo, Orange, u otro… mala suerte
  • Está soportado en Windows Phone, NO en Windows Store. Esto complica el desarrollo de apps universales.

En este terreno es donde entran empresas como Fortumo Mobile Payments, que incrementa y mejora las opciones de pago que nos ofrece Microsoft:

  • En primer lugar, Fortumo está disponible ahora mismo en 81 paises. Eso son 44 más que el operator billing de Microsoft.
  • En mi opinión, los países presentes en Fortumo son más importantes. Es muy probable que cualquiera en Finlandia, Francia o Estados Unidos tenga una tarjeta de credito. Pero países como India, Moldavia, Nigeria, Pakistan o Korea pueden ser más proclives para el pago con operador. Fortumo incluye todos estos paises y Microsoft no.
  • Fortumo es compatible con Android, Windows Store y Windows Phone (8 y 8.1) con lo que es una solución ideal para nuestras aplicaciones universales. También dispone de un api web, que nos permite integrarlo en páginas web.

Ahora la pregunta es, ¿Que esfuerzo nos requiere Fortumo? Pues sorprendentemente, es muy sencillo de integrar en nuestras aplicaciones. Lo primero que necesitaremos, será registrarnos en su web www.fortumo.com/register. Una vez hecho esto, podremos ver la página de servicios y crear un nuevo servicio:

image

Tras presionar el botón “Create new service”, veremos una lista de los servicios disponibles. En este ejemplo seleccionaremos “In App purchasing for Windows Phone & Windows 8”. En la siguiente página, solo tenemos que pulsar “Start now” para comenzar a configurar el servicio:

StartNow

Ahora llega el momento de configurar nuestro servicio de pago. En primer lugar, ¿En que países funcionará? Podemos escoger país por país o seleccionarlos todos y además marcar la opción “Auto add new territories when they become available”, que añadirá nuevos países cuando estén disponibles. Hablando con la gente de Fortumo me han dicho que normalmente el ritmo es de un par nuevo de territorios cada trimestre.

addTerritories

A continuación, nos piden información sobre el tipo de app o juego en el que queremos implementar Fortumo. En la mayoría de paises no se permiten servicios de pago de juego o con contenido adulto explícito, por lo que no podremos usar Fortumo en ese caso. También nos pedirán el tipo de item a vender. Podremos escoger entre un elemento de la app o juego o créditos virtuales. Por último necesitamos indicar un nombre para el servicio:

 

configureitem1

Y llegamos a la parte interesante. Cuanto queremos cobrar por nuestro producto:

configureprice

Aquí, tenemos varias opciones. Tenemos que entender que el sistema de pago con Fortumo se basa en mensajes SMS especiales. Debido a esto, existen un mínimo y un máximo que podemos cobrar, que puede ser diferente en cada país. Así, tenemos tres opciones:

  • El precio más barato posible. Por ejemplo esto es 2 euros en Austria, 30 céntimos de euro en Bosnia, 1.31 euros en Chipre y 10 céntimos de euro en Venezuela.
  • El precio más caro posible. Esto nos sube a 10 euros en Austria, 1.76 euros en Bosnia, 4.04 euros en Chipre y 10 céntimos de euro en Venezuela. Aquí podemos ver que con este sistema de pago, jugamos al son de las regulaciones de cada país. En Venezuela solo vamos a poder cobrar 10 céntimos de euro.
  • Por último, un valor aproximado al valor que indiquemos en euros. Si indicamos 1.5 euros, En Austria marcará 2 euros, porque es el mínimo, en Chipre subirá a 1.31 euros, en Bosnia al máximo 1.76 euros y así…

También en esta pantalla podremos ver el porcentaje de ese dinero que nos llevamos, que también varía de un país a otro, pues aquí jugamos con las operadoras y las regulaciones. Tenemos países con un share revenue del 85% y otros con un 20%. Puede parecer en un primer momento una locura en cuanto a lo poco que ganamos, pero un 20% de 100 euros es más que un 70% de 0 euros. Aquí el truco está en llegar a captar dinero que antes se nos estaba escapando.

Una vez configurado nuestro “target” de precio, tendremos que indicar información de soporte para los usuarios, nombre del servicio, etc…

ConfigureBillingData

Ya solo nos queda aceptar las regulaciones especiales de cada país y finalizar el proceso confirmando los precios de cada país:

countryRegulations

Y voila! nuestro servicio está creado. El setup nos dirige automáticamente a la página de descarga del SDK, en el menú superior podremos ir a la sección “General” donde podremos hacer varias cosas:

image

En primer lugar, tenemos el botón “Go Live”. Por defecto el servicio se crea en modo pruebas, una vez que publiquemos nuestra app debemos cambiar el servicio para que los pagos se puedan realizar.

A continuación vemos el tipo de servicio y los países disponibles. Y lo más importante al final: El Service ID y el Secret que tendremos que incluir en nuestra aplicación para realizar pagos. Ahora vamos a descargar el SDK. Como estamos haciendo una app universal, solo tendremos que descargar el de Windows Store, que podremos referenciar tanto en el proyecto Windows 8.1 como Windows Phone 8.1. Una vez que lo tengamos referenciado, empezar a trabajar es realmente fácil. Solo tendremos que trabajar con la clase Payment del namespace FortumoWindows:

Make a Payment with Fortumo
public Task<bool> ShowPayment(IDictionary<string, string> parameters)
{
    TaskCompletionSource<bool> tcs = new TaskCompletionSource<bool>();

    Payment payment = new Payment("ServiceId", "Secret");
    if (parameters != null)
    {
        foreach (var parameter in parameters)
        {
            payment.AddParameter(parameter.Key, parameter.Value);
        }
    }

    payment.Completed += (sender, paymentArgs) =>
    {
        if (paymentArgs.status == PaymentStatus.ok)
        {
            tcs.TrySetResult(true);
        }
        else
        {
            tcs.TrySetResult(false);
        }
    };
    payment.Show();

    return tcs.Task;
}

En el código podemos ver todo lo necesario para hacer un pago. En primer lugar creamos una instancia de la clase Payment pasándole el ServiceID y el Secret que obtuvimos al crear el servicio. A continuación, incluimos parámetros, si existen. Los parámetros disponibles los podemos ver en la web de ayuda de Fortumo.

A continuación, manejamos el evento Completed. En este evento nos llegará el resultado de la operación, de forma que podamos actuar en relación a ella. paymentArgs incluye información como el país y la moneda de pago, el operador móvil, el precio pagado, el id de producto… de forma que podamos verificar o almacenar la información que necesitemos.

Por último, mostramos la ventana de pago con el método Show. Esto lanza la propia página de Fortumo para que el usuario pueda realizar el pago:

image

image

Y listo! Ya tenemos nuestro nuevo sistema de pagos integrado en nuestra app. Con muy poco código, podemos poner a funcionar este sistema en nuestras aplicaciones, incluso combinarlo con el sistema de IAP que ofrece la propia tienda, de forma que el usuario pueda escoger como pagar en cada momento y nosotros obtengamos más ingresos.

Como siempre, aquí tenéis el ejemplo totalmente funcional usado en este artículo. He creado un servicio que se encarga de realizar el pago. Solo tenéis que poner el ServiceID y Secret de vuestra cuenta y debería funcionar perfectamente en cualquier app universal.

Antes de terminar, decir que la gente de Fortumo está haciendo grandes promociones, regalando crédito de Adduplex para los que integren esta solución de pago en sus aplicaciones, como podéis ver en este artículo en su blog,  así que aprovechad la oportunidad!!

Un saludo y Happy Coding!

[Windows Phone 8.1] Nokia SensorCore SDK

El martes 24 de junio pasado Nokia presentó y puso a nuestra disposición su último SDK (por el momento al menos): SensorCore. Es tanto el último que en la página oficial de su documentación no se aclaran si llamarlo Lumia SensorCore SDK o Microsoft Mobile SensorCore SDK. Aún se encuentra en beta, pero es totalmente usable para publicar apps a la tienda.

Ya lo habían presentado en el Build 2014, pero hasta ahora se encontraba en beta privada y exclusivamente bajo invitación. Por fin está aquí, ¿Qué nos aporta?

SensorCore es una tecnología de sensores de muy bajo consumo, integrada a nivel de hardware en ciertos modelos de la familia Lumia. Por el momento lo podemos encontrar y usar en el Lumia 630/635 y el Lumia 930. El Lumia 1520 y el Lumia Icon también incluyen estos sensores, pero deberemos esperar hasta la actualización de firmware Cyan para que el software necesario quede habilitado. En el resto de dispositivos, no podremos usar este SDK. No por una cuestión de software, si no por la falta de los sensores de hardware de los que hace uso.

Estos sensores de los que hablamos, de bajo consumo, se habilitan y recaban información en segundo plano. Según nos cuentan desde Microsoft, el consumo de energía es totalmente marginal. Aprovechan nuestra actividad de GPS para obtener datos del mismo, no activándolo ellos de forma activa, y monitorizando nuestros pasos gracias a su podómetro. Luego el software crea un histórico de todos estos datos de los últimos 10 días y los procesa de forma que puede indicarnos el tipo de actividad realizada en un momento dado (correr, caminar…), lugares frecuentes como nuestra casa o la oficina, número de pasos en un momento determinado, o rutas comunes que solemos usar.

Como estaréis pensando, esta es una cantidad ingente de datos personales y muy sensibles. En todo momento las aplicaciones tendrán que pedirnos acceso a la información y podremos desactivar totalmente esta tecnología en la configuración del dispositivo. Incluso podremos borrar el histórico de los 10 últimos días cuando deseemos.

Ahora que ya sabemos un poco que es y como funciona SensorCore, vamos a ver como integrarlo en nuestra aplicación. SensorCore SDK se compone de cuatro APIs distintas:

  • Step counter, número de pasos del usuario.
  • Activity monitor, tipo de actividad.
  • Place monitor, identifica la casa y la oficina del usuario así como lugares conocidos.
  • Track point monitor, guarda puntos de geo localización.

Vamos a ver cada una de estas APIs en detalle. Pero primero, veamos algunas buenas practicas relacionadas con el uso del SDK.

Buenas prácticas

Como hemos dicho anteriormente, no todos los dispositivos soportan SensorCore. De echo, solo un pequeño número de ellos lo hace en este momento. Hasta que el Lumia 1520 y el Icon obtengan Cyan, solo el Lumia 630/635 y el 930 soportan este SDK. Debido a esto, es especialmente recomendable que siempre nos aseguremos de que el dispositivo sobre el que se ejecuta nuestra aplicación soporta SensorCore. Para ello cada una de las APIs que hemos comentado incluye un método IsSupportedAsync, al que debemos llamar en primer lugar antes de intentar acceder a los datos.

Otra cosa que debemos tener en cuenta es que, aun estando soportado a nivel de hardware y software, puede que el usuario haya desactivado la opción de Location and motion en la configuración del dispositivo. Si es así, cualquier llamada a un API del SDK fallará con una excepción. Para evitar problemas, deberemos envolver nuestro código que haga uso de SensorCore en un bloque Try/Catch. En el Catch podemos obtener la excepción y haciendo uso de la clase SenseHelper que incluye el SDK extraer el error que se ha producido de la propiedad HRESULT de la propia excepción usando el método GetSenseError, que devuelve un enumerado SenseError con el tipo de error encontrado. SenseDisabled o LocationDisabled pueden ser dos errores muy comunes.

Por último, pero no menos importante, deberemos hacernos cargo de activar y desactivar la monitorización del API desde nuestra aplicación cuando la aplicación esté en primer plano o sea enviada a segundo plano. Para esto lo mejor es controlar la visibilidad de la ventana principal, para activar o desactivar el API que estemos usando dependiendo de si es visible o no.

Instalación

Para empezar a usar el SensorCore SDK solo tendremos que ir al administrador de NuGet y buscar “sensorcore”. Encontraremos dos paquetes. SensorCoreSDK Testing tools y SensorCoreSDK.

image

SensorCore SDK incluye los ensamblados necesarios para usar los sensores y acceder a las diferentes APIs. Por su parte las Testing tools incluye las mismas APIs que SensorCore, pero con datos pregrabados que nos permitirán probar las diferentes APIs aún sin disponer de un móvil compatible. Como siempre digo, si queremos hacer una aplicación comercial, estas herramientas nunca sustituirán totalmente las pruebas en dispositivos. Pero al menos nos ayudarán a desarrollar.

Algo que tenemos que tener en cuenta tras incluir SensorCore en nuestra aplicación es que no podremos compilarla como AnyCPU. Al usar componentes nativos, debemos compilarla en ARM para dispositivos o x86 para los emuladores.

Todas las APIs son muy parecidas, por lo que en este artículo vamos a ver a fondo una de ellas, StepCounter y su simulador StepCounterSimulator. Vamos a hacer una aplicación que tenga las siguientes características:

  • Detecte si nuestro dispositivo soporta o no SensorCore.
  • Dependiendo de la configuración de compilación use el simulador o no.
  • Muestre una gráfica de pasos y nos permita cambiar de día.

Al final, nuestro ejemplo debería parecerse a esto, para ello usaremos VisualStates y Behaviors, aunque en este artículo nos centraremos en SensorCore:

image

Step counter API

Como dijimos anteriormente, esta API nos permite obtener el histórico de los pasos dados por el usuario. Pero antes de aventurarnos a usarla, debemos comprobar que está realmente soportada por nuestro dispositivo. Para ello, tanto StepCounter como el resto de APIs de SensorCore disponen de un método llamado IsSupportedAsync, que devuelve true si está soportado o false si no lo está. Mirando a que más adelante queremos poder usar también el simulador, vamos a crear una interface llamada ISensorService donde crearemos un método IsStepsCounterSupported y otro GetStepsForDate:

ISensorService interface
public interface ISensorService
{
    /// <summary>
    /// Get if the device support or not StepsCounter
    /// </summary>
    /// <returns>true if supported, otherwise false.</returns>
    Task<bool> IsStepsCounterSupported();

    /// <summary>
    /// Get steps for a given date.
    /// </summary>
    /// <param name="date"></param>
    /// <returns>Steps recorded for given date.</returns>
    Task<StepCounterReading> GetStepsForDate(DateTime date);
}

De esta forma, podremos usar IoC para decidir que implementación usar sin tener que modificar nuestra ViewModel.

La implementación de IsStepsCounterSupported es muy sencilla, simplemente llamamos al método IsSupportedAsync de la clase StepCounter:

IsStepsCounterSupported
public async Task<bool> IsStepsCounterSupported()
{
    return await StepCounter.IsSupportedAsync();
}

Lo siguiente es implementar el método que nos devolverá los pasos para un día concreto. Para ello primero tendremos que obtener acceso a la clase StepCounter, usando el método GetDefaultAsync. A continuación, podremos usar el método GetStepCountAtAsync, que nos permite indicar una fecha y nos devuelve una instancia del tipo StepCounterReading:

GetStepsForDate
public async Task<StepCounterReading> GetStepsForDate(DateTime date)
{
    var stepCounter = await StepCounter.GetDefaultAsync();
    var steps = await stepCounter.GetStepCountAtAsync(date);

    return steps;
}

StepCounterReading contiene propiedades con detalles sobre la actividad para la fecha indicada:

  • WalkingStepCount, el número de pasos caminando.
  • RunningStepCount, el número de pasos corriendo.
  • WalkTime, el tiempo que hemos pasado caminando.
  • RunTime, el tiempo que hemos pasado corriendo.
  • TimeStamp, el momento en el que se creó la lectura actual.

Algo a tener en cuenta es que todos los métodos de SensorCore son nativos y si se produce un error, no nos devuelven el error completo como una excepción. En vez de eso, devuelven una excepción genérica con un valor HRESULT. Para saber exactamente que ha ocurrido debemos usar el método GetSenseError de la clase SenseHelper. Por lo tanto, podríamos reescribir el método anterior de forma segura como se muestra a continuación:

Safe GetStepsForDate
public async Task<StepCounterReading> GetStepsForDate(DateTime date)
{
    Exception failure = null;
    StepCounterReading steps = null;
    try
    {
        var stepCounter = await StepCounter.GetDefaultAsync();
        steps = await stepCounter.GetStepCountAtAsync(date);
    }
    catch (Exception ex)
    {
        failure = ex;
    }

    GetError(failure);

    return steps;
}

Ahora si se produce un error, podremos obtenerlo con GetError y reaccionar a él. El método GetSenseError devuelve un tipo que nos indica que es lo que ha ocurrido y que procesamos en el método GetError del código anterior:

GetError
private static void GetError(Exception failure)
{
    var error = SenseHelper.GetSenseError(failure.HResult);
    switch (error)
    {
        case SenseError.Busy:
            break;
        case SenseError.GeneralFailure:
            break;
        case SenseError.IncompatibleSDK:
            break;
        case SenseError.InvalidParameter:
            break;
        case SenseError.LocationDisabled:
            break;
        case SenseError.NotFound:
            break;
        case SenseError.SenseDisabled:
            break;
        case SenseError.SenseNotAvailable:
            break;
        case SenseError.SensorDeactivated:
            break;
        case SenseError.SensorNotAvailable:
            break;
        default:
            break;
    }
}

Solo tendremos que obtener el error y usando un Switch, ver lo que ha ocurrido para mostrar un mensaje al usuario, llevarlo a una pantalla de configuración o lo que necesitemos.

Ahora que ya es seguro usar nuestro servicio, podemos incluirlo en nuestra ViewModel para obtener los pasos por cada fecha:

VMSteps
IsSupported = await this.sensorService.IsStepsCounterSupported();

if (IsSupported)
{
    var stepsReading = await this.sensorService.GetStepsForDate(this.currentDate);
    if (stepsReading != null)
    {
        Steps = stepsReading.WalkingStepCount + stepsReading.RunningStepCount;
    }
}

Y listo, ya tenemos nuestra app funcionando. Pero solo en terminales que soporten SensorCore. A continuación vamos a ver como usar el simulador para nuestras pruebas en el emulador o en dispositivos sin SensorCore.

Step counter simulator API

Los métodos del simulador son exactamente los mismos que los del API normal, la única diferencia es que la clase no es StepCounter, es StepCounterSimulator y que necesitamos indicarle de donde queremos recoger los datos. Podemos grabar datos reales de un dispositivo o cargar datos ya grabados. En el repositorio de GitHub de Nokia tenemos varios archivos grabados que solo tendremos que descargar y agregar a nuestro proyecto (Content/Copy always). Podéis encontrarlos aquí.

Lo que vamos a hacer es crear una nueva implementación de la interface ISensorService. En este caso IsStepsCounterSupported devolverá true simplemente, sin realizar ninguna comprobación. Después de todo, estamos usando un simulador. Antes de poder implementar GetStepsForDate, crearemos un constructor que se encargue de cargar los datos pre grabados desde disco:

Fake data init
private async Task InitializeAsync()
{
    recording = await SenseRecording.LoadFromFileAsync("record.txt");
}

recording es una variable de tipo SenseRecording, que contiene todos los datos pregrabados. Ahora la usaremos para inicializar la clase StepCounterSimulator:

Simulated GetStepsForDate
public async Task<StepCounterReading> GetStepsForDate(DateTime date)
{
    var stepCounter = await StepCounterSimulator.GetDefaultAsync(recording, date.AddDays(-10));
    var steps = await stepCounter.GetStepCountAtAsync(date);

    return steps;
}

Además de la grabación de datos, también indicamos una fecha en el método GetDefaultAsync. Esta fecha sobre escribe la que se ha grabado en los datos para permitirnos cambiarla sin tener que editar el archivo de disco. En este caso simplemente le decimos que la fecha de inicio de los datos debe ser hace 10 días. Y no tenemos que hacer nada más, automáticamente llamamos a GetStepCountAtAsync igual que en la implementación real y nos devolverá datos, siempre que la fecha esté dentro de esos 10 días anteriores a hoy.

En este caso no hace falta incluir una manera segura de llamar a los datos, porque el simulador siempre devolverá datos correctos.

Usando IoC para decidir el API a usar

Ahora ya tenemos nuestras dos implementaciones: SenseService y SenseServiceFake. Pero, ¿Como cambiamos entre una y otra? Bien, en primer lugar es importante que lo que consuma nuestra ViewModel sea ISenseService, la interface, para poder cambiar de implementación. Para automatizar, aunque esto puede variar según tus necesidades, podemos usar nuestro Locator de ViewModels en conjunción con la configuración de compilación:

  • Para publicar en la store y hacer pruebas reales, tengo que compilar en Release, por lo que cuando se compile en Release usaré la implementación real SensorService.
  • Para pruebas durante el desarrollo en el emulador uso la configuración de Debug, por lo que cuando compile en Debug usaré la implementación simulada SensorServiceFake.

Con esto, nuestro Locator, podría quedar de la siguiente forma:

VMLocator
public VMLocator()
{
    ContainerBuilder builder = new ContainerBuilder();

#if DEBUG
    builder.RegisterType<SensorServiceFake>().As<ISensorService>().SingleInstance();
#else
    builder.RegisterType<SensorService>().As<ISensorService>().SingleInstance();
#endif
    builder.RegisterType<VMSteps>();

    this.container = builder.Build();
}

Ahora solo tenemos que incluir la interface ISensorService en nuestra ViewModel y voila! Todo debería funcionar correctamente, tanto en Debug como en Release, usando en cada caso la implementación correcta.

VMSteps constructor
public VMSteps(ISensorService sensorService)
{
    this.sensorService = sensorService;

    this.previousDayCommand = new DelegateCommand(ExecutePreviousDayCommand);
    this.nextDayCommand = new DelegateCommand(ExecuteNextDayCommand, CanExecuteNextDayCommand);
}

Y hasta aquí nuestro artículo de hoy. Como siempre, podéis descargar el código del ejemplo aquí para que os sirva de referencia. Espero que os sea de mucha utilidad y ver nuevas apps usando este SDK en la tienda.

Un saludo y Happy Coding!!

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!

[Windows Phone 8.1] WebAuthenticationBroker

Hola a todos!

Después de unos días sin escribir y de que se presentase oficialmente la RTM del SDK de Windows Phone 8.1, volvemos a la carga con novedades en las APIs de Windows Phone 8.1. En esta ocasión quiero hablar del WebAuthenticationBroker. Los que hayáis trabajado con apps Windows Store, lo conoceréis sin duda. Para el resto, aquí va una introducción.

¿Qué es el WebAuthenticationBroker?

El WebAuthenticationBroker es una clase pensada para facilitarnos la vida como desarrolladores a la hora de usar sistemas de autenticación OAuth de cualquier tipo. Facebook, Twitter, LinkedIn… casi toda empresa que expone APIs públicas usa OAuth como sistema de identificación. Básicamente este sistema nos permite registrar nuestra app en él y obtener unos identificadores para la misma. Luego, en tiempo de ejecución nuestra aplicación abre una web del sistema, enviando los identificadores recibidos a la misma y en la que se pide al usuario que introduzca su nombre y clave para autorizar a nuestra aplicación a acceder a su cuenta. Lo bueno de esto es que el usuario no introduce sus datos en nuestra aplicación, lo hace en una web del creador del API, por lo que su confianza debería ser mayor. Al final, nuestra aplicación recibe un token, normalmente con un tiempo de vida predeterminado, que podemos usar para autentificar las llamadas al API que realicemos. Además, el usuario puede revocarnos el acceso desde la administración del API en cualquier momento. A continuación os muestro un esquema, OAuth tiene un funcionamiento interno que en este esquema simplifico para enseñar como se relaciona con nuestra aplicación, no como funciona internamente que está fuera del alcance de este artículo:

image

Como podemos ver, simplemente hacemos una petición a una URL OAuth. En realidad navegamos a esa URL, lo cual muestra la web de autenticación. En el ejemplo he puesto una de las webs de autenticación que usa Facebook. En esa web, el usuario puede permitirnos el acceso a su cuenta. Si funciona correctamente, la web nos redirigirá a una URL de respuesta configurada en el servicio al registrar nuestra aplicación. En esa redirección, suele enviarse como parámetro el token de acceso a la API. Y listo, ya podemos realizar peticiones autenticadas con el token que hemos recibido.

¿Como implementamos esto antes de Windows Phone 8.1?

Pues muy a “mano”. Básicamente, siguiendo los siguientes pasos:

  • Construías en nuestra aplicación una página que contuviese un WebBrowser.
  • Si no estamos autenticados (no tenemos un token) navegar a la URL de OAuth en esa página
  • Vigilar los eventos de navegación del WebBrowser para detectar cuando esta redirigiéndonos a la respuesta.
  • Procesar la URL de respuesta para extraer el token.

No es que sea el proceso más complicado del mundo, pero es todo muy manual y puede llevarnos un rato de prueba/error si queremos que funcione con varios proveedores distintos al mismo tiempo.

¿Como implementamos esto ahora en Windows Phone 8.1?

Lo implementamos usando el WebAuthenticationBroker, que nos facilita la vida:

  • Si no estamos autenticados (no tenemos un token) llamamos al método AuthenticateAndContinue de la clase WebAuthenticationBroker.
  • Recibimos la respuesta y extraemos el token.

Si, ya está. Solo tenemos que hacer eso. El propio WebAuthenticationBroker se encarga por nosotros de todos los demás pasos. Esta fue una de las grandes novedades que incluyó Windows 8 en su API WinRT cuando salió y por fin la tenemos disponible en Windows Phone. No obstante existen ciertas diferencias entre el API de Windows 8 y la de Windows Phone 8.1, como veremos a continuación.

WebAuthenticationBroker: Windows Store vs Windows Phone

Como hemos dicho, solo tenemos que llamar al método AuthenticateAndContinue de la clase WebAuthenticationBroker, pero este método no existe en Windows Store, donde usaremos en su lugar AuthenticateAsync. Esta diferencia, que encontraremos en algunas APIs más de Windows Phone 8.1, va mas allá de un simple cambio de nombre. AuthenticateAsync es, como su nombre indica asíncrono, podemos usar await para esperar que se complete y nos de el resultado. Por el contrario, AuthenticateAndContinue no es asíncrono y devuelve ¡VOID!, ahora veremos porqué y como obtener el resultado.

El problema principal es el siguiente. En terminales de baja memoria, 512Mb, Windows Phone no puede asegurar en todo momento que pueda mantener nuestra aplicación abierta al mismo tiempo que lanza otra aplicación, la cual se encargará de realizar la autenticación. Por este motivo, ciertas APIs que necesitan abrir un “Broker”, una aplicación del sistema para realizar una acción, como el WebAuthenticationBroker, han implementado un método llamado “DoSomethingAndContinue” que no devuelve ningún resultado. En su lugar seguiremos el siguiente flujo:

image

Básicamente tenemos los siguientes pasos:

  1. Nuestra aplicación ejecuta el método AuthenticateAndContinue del WebAuthenticationBroker. En esta
  2. La aplicación WebAuhtenticationBroker del sistema pasa a primer plano y nuestra app se suspende. Dependerá del sistema si se conserva en memoria o no.
  3. El usuario realiza las acciones necesarias y el WebAuthenticationBroker termina, activando nuestra app de nuevo.
  4. Nuestra app pasa al primer plano, recibiendo como argumento un objeto de tipo AuthenticationResult.
  5. Tenemos que enviar la respuesta a nuestra página/viewmodel para seguir trabajando.

Viendo el código.

Ahora que tenemos claro como funciona el proceso, vamos a ver el código implicado en él. Para el primer paso, necesitaremos una URL de autenticación OAuth que podamos usar. En este ejemplo vamos a usar una de Facebook. Para obtener una URL, tendremos que ir a https://developers.facebook.com/, registrarnos y crear una nueva app en el menú superior “Apps”:

image

Una vez creada, nos mostrará la página de la app con el AppID y el AppSecret, estos identificadores serán necesarios para componer nuestra URL de conexión a continuación:

https://www.facebook.com/dialog/oauth?client_id=[APPID]&redirect_uri=http://localhost/reply&scope=[PERMISOS]&display=popup&response_type=token

Simplemente tenemos que sustituir el texto [APPID] por el appID que nos dio Facebook al registrar la aplicación y añadir los permisos necesarios, según las acciones que deseemos realizar.

El código sería algo como esto:

AuthenticateAndContinue
private void LoginFacebookExecute()
{
    string appID = "YOUR APP ID FROM FACEBOOK";
    string permissions = "publish_actions";
    string authUrl = string.Format("https://www.facebook.com/dialog/oauth?client_id={0}&redirect_uri=http://localhost/reply&scope={1}&display=popup&response_type=token", appID, permissions);
            
    WebAuthenticationBroker.AuthenticateAndContinue(new Uri(authUrl), new Uri("http://localhost/reply"), null, WebAuthenticationOptions.None);
}

Como vemos no es un código complicado. formamos la URL de OAuth2 de Facebook añadiendo nuestro APPID y los permisos a usar y a continuación llamamos al método AuthenticateAndContinue. Es en esta parte donde viene lo divertido. Justo tras llamar a ese método, nuestra aplicación se suspende y se abre el WebAuthenticationBroker. ¿Y como obtenemos el resultado de la operación? Bien, controlando el método OnActivated de la clase App (App.xaml.cs) Desde ese método deberemos pasar la información a nuestra ViewModel. Para hacer esto más sencillo, yo he creado un Interface que añado a todas las ViewModels que hacen uso de métodos “…AndContinue”. Esta interface se llama IContinuationAwareViewModel y define el método Continue:

IContinuationAwareViewModel
public interface IContinuationAwareViewModel
{
    void Continue(IActivatedEventArgs args);
}

Simplemente la implemento en la ViewModel donde hemos llamado a AuthenticateAndContinue y dentro del método Continue pongo el código para recibir y procesar la respuesta de Facebook:

Continue
public void Continue(IActivatedEventArgs args)
{
    var arguments = (WebAuthenticationBrokerContinuationEventArgs)args;
    WebAuthenticationResult result = arguments.WebAuthenticationResult;

    if (result.ResponseStatus == WebAuthenticationStatus.Success)
    {
        string responseCode = result.ResponseData;
        responseCode = responseCode.Substring(responseCode.IndexOf("=") + 1);
        AccessToken = responseCode.Split('&').First();
        ExpirationTime = int.Parse(responseCode.Split('&').Last().Split('=').Last());
    }
}

Comprobamos si la operación a tenido éxito y simplemente procesamos la cadena de texto que devuelve Facebook con el token de acceso y el tiempo de expiración en segundos.

Ahora ya solo nos queda ver como invocar a este método desde el OnActivated de la clase App:

App OnActivated
protected override void OnActivated(IActivatedEventArgs args)
{
    var rootFrame = (Frame)Window.Current.Content;
    var currentPage = (Page)rootFrame.Content;
    var currentViewModel = (IContinuationAwareViewModel)currentPage.DataContext;

    currentViewModel.Continue(args);
}

Primero obtenemos el frame actual de la aplicación, del cual extraemos la página activa. Del DataContext de la página extraemos la ViewModel (que convertimos a IContinuationAwareViewModel) y ya solo nos queda invocar al método Continue pasando los argumentos de activación. Es tarea del método Continue implementado en la ViewModel decidir como usar esos argumentos y que información obtener. De esta forma, si tenemos varias páginas que usen métodos “…AndContinue” el método de activación será standard para todas ellas.

Y con esto llegamos al final de esta artículo. Como siempre, aquí tienes el ejemplo funcionando con el código que hemos visto, para que puedas jugar con él y por supuesto usando MVVM para que veas como implementar WebAuthenticationBroker con todas las piezas en su sitio.

Espero que lo disfrutes.

Un saludo y Happy Coding!

 

 

[Windows Phone] Este viernes 16 de mayo llega //Publish

Hola a todos!

Después de mucho tiempo de preparación, ya está aquí el 16 de mayo y el evento //Publish que se celebrará a nivel mundial en más de 60 ciudades al mismo tiempo.

En Madrid, las inscripciones ya están cerradas y tenemos todo preparado para pasar un gran día juntos, desarrollando apps y con muchas sorpresas.

El día empezará a las 9 de la mañana con el registro general. Según vayáis llegando, empezaréis a desarrollar. Hemos decidido no hacer charlas técnicas ese día. Estaremos varios por allí para ayudaros con lo que necesitéis, pero el objetivo es desarrollar y no queremos distraeros. a la 1 de la tarde pararemos una hora para comer y luego seguiremos hasta las 6 y media de la tarde desarrollando. A las 6:30 pararemos, para que cada cual presente sus apps a los demás y el jurado, compuesto por Javier Suarez Ruiz, Santiago Porras y Alejandro Campos, deliberará sobre las mejores apps. Entre ellas escogeremos dos: La primera podrá escoger como premio entre un Lumia 1520 y una tablet Dell Venue 8 Pro. El premio restante será para el segundo. Pero no os preocupéis que tendremos sorpresas y regalos parar todos!!.

¿Vas a venir? ¿Qué tienes que traer para poder aprovechar bien el día?

  • Lo principal: muchas ganas de desarrollar, aprender y sacar una app al público.
  • Como solo tenemos un día, lo ideal es que ya traigas algo desarrollado de casa, pero si vienes con una idea, haremos lo posible para que te vayas con mucho hecho y funcionando… incluso puede que con la aplicación publicada en la tienda.
  • Recuerda traer tu portatil, con el software necesario instalado. Si tienes que instalarlo sobre la marcha te ayudaremos, pero perderas un valioso tiempo instalando. Necesitarás al menos:
    • Windows 8.1 Pro o superior de 64 bits
    • SDK de Windows Phone 8.1

Si tu idea es desarrollar una app Windows Phone 8.1, tendremos varios terminales para que la puedas probar (un Lumia 1520 y un Lumia 625 listos con Windows Phone 8.1).

Para ayudarte, tendrás un monton de gente que controla de Windows Phone:

  • Javier Suarez Ruiz
  • Santiago Porras
  • Alejandro Campos
  • Un servidor

Además, Santiago llegará al evento con la gorra y bufanda de diseñador, listo para daros un apoyo en el diseño de vuestra app para sacarle el máximo partido y que tenga la mejor apariencia posible.

Por último, recordaros que el evento se celebrará en las oficinas de Microsoft Ibérica:

 

Asignar imagen

 

Paseo Club Deportivo, número 1.

Centro Empresarial La Finca.

Un saludo y Happy Coding!

 

[Windows Phone 8.1] MVVM en apps universales.

Hola a todos!

Una de las grandes novedades, como ya vimos anteriormente, en la nueva versión de Windows Phone 8.1 son las aplicaciones universales. Este nuevo tipo de proyecto nos promete ser capaces de compartir la gran mayoría de código entre una versión Windows Store y otra Windows Phone de la misma aplicación. ¿Pero realmente es así? Antes de empezar a repasar nuevas APIs, XAML y otras cosas, creo que es importante ver como podemos usar MVVM en nuestras aplicaciones universales para compartir gran parte del código.

Implementando MVVM en proyectos universales

Realmente la implementación de MVVM no cambia en absoluto, con respecto a la que podríamos hacer en Windows Phone 8.0 o Windows Store. Lo único que cambia es el proyecto donde colocamos nuestros archivos.

Mientras que anteriormente implementábamos MVVM en el propio proyecto de la aplicación o una PCL, en las apps universales usaremos el proyecto Shared para almacenar nuestros archivos. El objetivo es llegar a tener solo el XAML de las páginas en cada proyecto de plataforma y que toda la lógica de la aplicación esté centralizada en el proyecto Shared. ¿Es esto posible? Si en la mayoría de los casos. Siempre nos encontraremos con casos en que las APIs de Phone y Store no son exactamente iguales, incluso donde su valor de retorno no es el mismo. En estos casos tendremos dos opciones: Crear una ViewModel específica para cada proyecto o usar bloques condicionales de compilación. ¿Cual usar en cada caso? Pues dependerá un poco de nuestras necesidades particulares en cada momento y de lo que necesitemos hacer. Si es poco el código particular de cada plataforma y mucho el código compartido, quizás usar un bloque condicional nos ayude a compartir código y no tener que reescribirlo todo. Sin embargo, si el código particular es la mayoría de la ViewModel, quizás sea mejor crear una por cada plataforma.

Vamos a comenzar por las bases. En todo proyecto XAML con MVVM, me gusta crear dos clases base: PageBase y ViewModelBase.

PageBase

PageBase la usaré como clase base de todas mis páginas. Esto me permite varias cosas:

  • Definir comportamientos comunes a todas las páginas, como detección de internet.
  • Definición de transiciones comunes.
  • En conjunto con la ViewModelBase, “rutear” los metodos de navegación hacia las ViewModels.
  • Establecer en la ViewModelBase el Frame activo de cada página, de forma que sea más facilmente accesible.

Con esta funcionalidad, la clase PageBase tendría este aspecto:

PageBase
public class PageBase : Page
{
    private ViewModelBase vm;

    public PageBase()
    {
    }

    protected override void OnNavigatedTo(NavigationEventArgs e)
    {
        base.OnNavigatedTo(e);

        vm = (ViewModelBase)this.DataContext;
        vm.SetAppFrame(this.Frame);
        vm.OnNavigatedTo(e);
    }

    protected override void OnNavigatedFrom(NavigationEventArgs e)
    {
        base.OnNavigatedFrom(e);
        vm.OnNavigatedFrom(e);
    }

    protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)
    {
        base.OnNavigatingFrom(e);
        vm.OnNavigatingFrom(e);
    }
}

Aquí podemos observar una de las ventajas de Windows Phone 8.1 y las aplicaciones universales. Ya no tenemos un objeto PhoneApplicationPage. Ahora todas las páginas, tanto de Windows Phone como Windows Store, heredan del objeto Page. Esto permite que de igual forma, nuestra página base pueda ser compartida entre las dos plataformas.

Podéis ver que el código no es nada de otro mundo, controlamos los métodos de navegación y en el método OnNavigateTo obtenemos la ViewModel asignada a la página y establecemos el Frame activo en la misma. Por último en todos los métodos de navegación invocamos un método que se llama igual en la ViewModelBase. De esta forma no necesitamos usar code behind para controlar la navegación de nuestras páginas.

ViewModelBase

Nuestra ViewModelBase actuará como la clase base de las cuales heredarán todas nuestras ViewModels, lo que nos permitirá darles una funcionalidad básica y homogénea a todas:

  • Acceso al objeto Frame de la página asociada.
  • Acceso a los eventos de navegación para sobre escribirlos.
  • Notificación de cambios.
  • Notificación de carga a la UI.

El código de la ViewModelBase, sería parecido a este:

ViewModelBase
public abstract class ViewModelBase : INotifyPropertyChanged
{
    private Frame appFrame;
    private bool isBusy;

    public ViewModelBase()
    {
    }

    public Frame AppFrame
    {
        get { return appFrame; }
    }

    public bool IsBusy
    {
        get { return isBusy; }
        set
        {
            isBusy = value;
            RaisePropertyChanged();
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    public abstract Task OnNavigatedFrom(NavigationEventArgs args);

    public abstract Task OnNavigatingFrom(NavigatingCancelEventArgs args);

    public abstract Task OnNavigatedTo(NavigationEventArgs args);

    public void RaisePropertyChanged([CallerMemberName]string propertyName = "")
    {
        var Handler = PropertyChanged;
        if (Handler != null)
            Handler(this, new PropertyChangedEventArgs(propertyName));
    }

    internal void SetAppFrame(Frame viewFrame)
    {
        appFrame = viewFrame;
    }
}

Hemos creado tres métodos abstractos: OnNavigatedFrom, OnNavigatingFrom y OnNavigatedTo que implementaremos en nuestras ViewModels para poder ejecutar código durante la navegación. Esto es muy útil cuando queremos recibir un parámetro de otra página, pero también al cargar datos. Si realizamos carga de datos en el constructor, podemos ralentizar la carga de la página. Sin embargo usando el método OnNavigatedTo, realizamos la carga una vez que la página está activa, no antes.

Ahora ya podemos empezar a crear nuestras páginas y ViewModels, usando las clases base que hemos definido.

Páginas

En cada página, tendremos que incluir el namespace de nuestra página base y cambiar su tipo, tanto en XAML como en C#:

 

MainPage.xaml
<base:PageBase
    x:Class="Wp81MVVM.MainPage"
    xmlns:base="using:Wp81MVVM.Base"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Wp81MVVM"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d">

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    </Grid>
</base:PageBase>

 

 

MainPage.xaml.cs
namespace Wp81MVVM
{
    using Wp81MVVM.Base;

    public sealed partial class MainPage : PageBase
    {
        public MainPage()
        {
            this.InitializeComponent();
        }
    }
}

 

Ahora solo tenemos que definir una ViewModel para esta página, implementando la ViewModelBase y sus métodos abstractos de navegación:

ViewModel
public class MainViewModel : ViewModelBase
{
    public MainViewModel()
    {

    }

    public override Task OnNavigatedTo(Windows.UI.Xaml.Navigation.NavigationEventArgs args)
    {
        return null;
    }

    public override Task OnNavigatedFrom(Windows.UI.Xaml.Navigation.NavigationEventArgs args)
    {
        return null;
    }

    public override Task OnNavigatingFrom(Windows.UI.Xaml.Navigation.NavigatingCancelEventArgs args)
    {
        return null;
    }
}

Ya solo nos queda unir nuestra página y nuestra ViewModel, de la forma que más nos guste: usando IoC, asignándola directamente en el constructor de la página… En este caso voy a usar Unity para resolver nuestra ViewModel y servicios. Para ello, lo primero que necesitaremos es añadir una referencia en nuestro proyecto universal a Unity. En este tipo de proyectos esto significa añadir la referencia a cada proyecto de plataforma (Phone y Store). Vamos a comenzar por el proyecto Store. Solo tenemos que hacer click derecho sobre el nodo “References” del proyecto y seleccionar la opción “Manage NuGet packages”, buscar “Unity” y presionar el botón instalar:

image

Ahora deberíamos repetir lo mismo con el proyecto Phone, pero el resultado será el siguiente:

image

El problema aquí es que, en la mayoría de los casos, todavía no se han actualizado los paquetes de NuGet para soportar los tipos de proyecto “WindowsPhoneApp, version=8.1”. ¿Quiere decir esto que no podemos usar Unity? Ni mucho menos. Lo unico que quiere decir es que no podemos instalarlo desde NuGet. Como Windows Phone 8.1 y Windows Store comparten ahora todo el core de desarrollo, “en teoría” podríamos usar el mismo ensamblado que en Windows Store. Solo tenemos que hacer click con el botón derecho sobre “References” en el proyecto Windows Phone y seleccionar “Add Reference”, presionar el botón “Browse” e ir a la carpeta de packages donde se ha descargado Unity para Windows Store previamente, seleccionando la carpeta NetCore45, que es la usada en Windows Store, seleccionamos la dll dentro de esa carpeta y presionamos “add” y “ok” y listo, ya tendremos Unity funcionando en nuestra aplicación Windows Phone 8.1.

Ahora en nuestro proyecto Shared, en la carpeta Base de ViewModels, vamos a añadir una nueva clase llamada ViewModelLocator, que haga uso de Unity para registrar y resolver nuestras ViewModels, exponiéndolas mediante propiedades públicas:

ViewModelLocator
public class ViewModelLocator
{
    IUnityContainer container;

    public ViewModelLocator()
    {
        container = new UnityContainer();

        container.RegisterType<MainViewModel>();
    }

    public MainViewModel MainViewModel
    {
        get { return container.Resolve<MainViewModel>(); }
    }
}

Como podemos ver, desde nuestro proyecto Shared podemos acceder a cualquier ensamblado referenciado en nuestros proyectos de plataforma, haciendo muy sencillo escribir código compartido. Ya solo nos queda añadir nuestro ViewModelLocator como una referencia en el archivo App.xaml, que también se encuentra compartido en el proyecto Shared:

Shared App.xaml
<Application
    x:Class="Wp81MVVM.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Wp81MVVM"
    xmlns:VMBase="using:Wp81MVVM.Base">

    <Application.Resources>
        <VMBase:ViewModelLocator x:Key="Locator"/>
    </Application.Resources>
</Application>

Y ya lo podemos usar en las páginas de ambas plataformas. De la misma forma que haríamos en un proyecto de Phone o Store tradicional:

 

MainPage.xaml Windows Store
<base:PageBase
    x:Class="Wp81MVVM.MainPage"
    xmlns:base="using:Wp81MVVM.Base"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Wp81MVVM"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    DataContext="{Binding MainViewModel, Source={StaticResource Locator}}">

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    </Grid>
</base:PageBase>

 

 

 

Mainpage.xaml Windows Phone
<base:PageBase
    x:Class="Wp81MVVM.MainPage"
    xmlns:base="using:Wp81MVVM.Base"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:Wp81MVVM"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"
    DataContext="{Binding MainViewModel, Source={StaticResource Locator}}">

    <Grid>

    </Grid>
</base:PageBase>

 

En este punto, puede parecer que tener una sola página es mejor y compartirla en el proyecto Shared. Si, podríamos hacerlo sin ninguna dificultad. Pero en la mayoría de los casos, haría que en Phone o Store, la UX fuese horrible. En mi caso soy un firme defensor de hacer una interface de usuario para cada plataforma, aprovechándonos de sus puntos fuertes. Sin embargo, si que es posible que nos encontremos compartiendo pequeños trozos de interface en forma de controles de usuario y en muchos casos usando las diferentes páginas solo para modificar la distribución de la información en pantalla para aprovechar mejor el área de trabajo de cada plataforma. Esto da para un próximo artículo.

Conclusión

Esto es todo por hoy, como hemos podido ver es muy fácil compartir código con los proyectos universales, sin necesidad de hacks ni cosas extrañas (seguro que en algún momento nos hacen falta jeje) y nos permite construir apps para la plataforma Windows en conjunto. Como siempre, podéis descargar todo el código de ejemplo aquí para jugar con él y usarlo como punto de partida para vuestras apps.

Sería un buen arranque para una app que queráis presentar en el Hackathon //Publish del 16 de Mayo en Madrid, Barcelona o Palma de Mayorca. Premios, asistencia para el diseño de tu app, y mentores para ayudarte a crear el próximo hit!

Un saludo y Happy Coding!

 

[Eventos] Después del //Build/ llega //Learn/ y //Publish/

Hola a todos!

Solo hace unos días que termino el //Build/ 2014. Este año los seguidores de Windows Phone tuvimos grandes novedades y anuncios con la presentación de Windows Phone 8.1. Desde Microsoft Corp. y la comunidad de MVPs de Windows Phone, queremos ayudarte a seguir el ritmo de las novedades y crear grandes aplicaciones usando las nuevas ventajas que ofrece la plataforma Windows con esta última revisión.

Para ello, se han creado dos eventos que tendrán lugar en Abril y Mayo: //Learn/ y //Publish/

//Learn/

Este evento online está organizado directamente por los MVPs de Windows Phone. Durante 6 horas, tendremos webcast sobre diferentes temáticas de Windows Phone 8.1: aplicaciones universales, diseño, nuevas APIs, notificaciones… Lo mejor de todo, es que no solo será en Inglés. Dispondremos de una track principal en inglés y tracks paralelas en Chino, Ruso, Portugués, Frances y Español!!

En la Track en Español, Sorey García, Roberto Alvarado, Jose Luis Latorre, Ivan Toledo y un servidor estaremos dando todo el contenido. Las sesiones que tendremos serán las siguientes (Puede variar alguna todavía):

  • Introducción a Windows Phone 8.1
  • Empezando a construir apps Windows XAML
  • Controles de layout y transiciones de páginas
  • Adaptando tu UI a diferentes pantallas
  • Ciclo de vida de apps WinRT XAML
  • Tiles, badges, notificaciones y el Action center
  • Tareas en background
  • Windows XAML para desarrolladores Silverlight

El evento se celebrará el 24 de Abril, se pueden registrar aquí. Al ser un evento internacional los horarios han tenido que ser consensuados y España no sale demasiado bien parada. El evento en España empezará alrededor de la 1 de la mañana del día 25… pero no os preocupéis, el material será grabado y al día siguiente, o tan pronto tenga los enlaces, los pondré aquí.

//Publish/

Cerca de un mes después del evento //Learn/ tendremos un nuevo evento, esta vez presencial. Se trata de un hackathon organizado entre Microsoft y la comunidad MVP. En él ayudaremos a los asistentes a crear apps para Windows 8.1 y Windows Phone 8.1, tendremos mentores, premios, dispositivos para probar vuestras apps y os invitaremos a comer.

En España tenemos la suerte de tener tres sedes: Barcelona, organizada por Microsoft y Madrid y Palma de Mallorca, organizadas por la comunidad MVP. En mi caso estaré en Madrid, junto con Javier Suarez y Santiago Porras para ayudaros a crear apps increíbles y publicarlas. El evento en Madrid se llevará a cabo en las oficinas de Microsoft el día 16 de mayo.

En breve tendremos más información, según vayamos avanzando con la organización y actualizaré este post con todas las novedades. Por ahora podéis registraros en cualquiera de las tres sedes aquí.

Estos eventos son grandes oportunidades para actualizar vuestros conocimientos o introduciros en la plataforma Windows, así que no perdáis esta oportunidad. Nos vemos en breve.

Un saludo y Happy Coding!

[Windows Phone 8.1] Opciones para desarrollar

Hola a todos!

En el artículo anterior, hablamos sobre las novedades de Windows Phone 8.1 en cuanto a las herramientas que tenemos disponibles. Hoy vamos a hablar sobre las nuevas opciones y frameworks que tenemos disponibles para crear nuestras aplicaciones.

Bien, esta es una de las cosas que mas enrolladas están. Windows Phone 8.1 trae consigo nuevas formas de hacer las cosas, pero Microsoft no ha querido dejar a nadie en la cuneta, con lo que es totalmente compatible con el código que ya teníamos para Windows Phone 8.0.

En primer lugar tenemos que tener en cuenta que el motor de ejecución de apps ha cambiado en Windows Phone 8.1. Se ha abandonado el motor basado en Silverlight y se ha creado todo un nuevo motor de ejecución basado en WinRT y Windows Store. Pero sobre este motor, se ha trabajado para poder ejecutar las aplicaciones de Windows phone 8.0 sin necesidad de realizar ningún cambio ni adaptarlas. Automáticamente todas son compatibles. Con esto, podemos desarrollar de las siguientes formas:

  • Silverlight para Windows Phone 8.0: Podemos crear una app de Windows Phone 8.0 y se ejecutará perfectamente en terminales 8.0 y 8.1. Pero no tendremos acceso a las nuevas APIs de Windows Phone 8.1.
  • Silverlight para Windows Phone 8.1: Esta nueva versión nos permite migrar una app Windows Phone 8.0 de forma muy rápida (con una opción de menú) y además acceder a las nuevas APIs de Windows Phone 8.1.
  • Windows XAML: Es la gran novedad de Windows Phone 8.1, básicamente es el mismo sistema usado en las apps Windows Store XAML. 100% WinRT y mismo XAML para la interface de usuario. Es el que más cambia con respecto a la anterior versión del sistema. Con Windows XAML podremos crear proyectos universales, de los que hablaremos más adelante, que nos permitirán desarrollar para Windows Phone y Windows Store de forma muy sencilla.
  • WinJS: Para todos los aficionados a HTML5, JS y CSS… ahora podréis desarrollar apps Windows Phone nativas de la misma forma que ya se hacía en Windows Store usando HTML5 y JS. Con WinJS también podréis realizar proyectos universales. Cabe mencionar que, aunque usemos la denominación WinJS, en realidad estamos hablando de HTML5 y JS nativo, con lo que podrás usar librerías como JQuery, Angular, Knockout… WinJS es solo necesario para acceder a funcionalidades del sistema.

El nuevo camino planteado por Microsoft es Windows XAML / WinJS. Silverlight para Windows Phone 8.1 ha sido pensado para escenarios muy concretos. En particular la mayor fortaleza de Silverlight es permitirte migrar tus desarrollos de Windows Phone 8.0 a 8.1 y conseguir acceso a las nuevas APIs sin tener que reescribir toda la aplicación o gran parte de ella.

De echo, las aplicaciones de correo, alarmas, calendario, etc… que vienen en el sistema están escritas con este mismo framework Windows XAML. Con lo que nos podemos hacer una idea de su potencia dandole un vistazo a las mismas. Se ha reescrito el motor de ejecución de aplicaciones para Windows XAML y se ha creado una superficie compatible con Silverlight que permite la ejecución de las nuevas aplicaciones de Silverlight 8.1 en el motor de Windows XAML. De esta forma es como las apps  de Silverlight 8.1 pueden acceder a las nuevas APIs de Windows XAML.

image

Como podemos ver, nuestras apps de Windows Phone 8 se seguirán ejecutando sobre el mismo motor, por lo que no tendremos problemas de compatibilidad. Las apps Silverlight 8.1 se ejecutarán sobre una superficie de compatibilidad sobre el motor de ejecución Windows XAML, por eso tienen acceso a todas las nuevas APIs (nuestras apps wp8 no podrán acceder a las nuevas APIs ni usando reflection siquiera). Las nuevas aplicaciones Windows XAML se ejecutan directamente sobre su nuevo motor.

Pero cada sistema tiene sus pros y sus contras. Windows XAML es una nueva manera de desarrollar traída directamente de las aplicaciones Windows Store e introduce muchos cambios. Así, echaremos en falta los ya tan típicos Launchers y Choosers de Windows Phone, que no existen en Windows XAML y algunas cosas más. ¿Como decidimos entre uno u otro para nuestros desarrollos? Aquí intento dejaros una lista de cosas a valorar. La más importante no obstante es recordar que Silverlight para Windows Phone 8.1 existe como ayuda en la transición a la nueva versión del sistema. La opción de continuidad en el futuro es Windows XAML. No incluimos Silverlight para Windows Phone 8 en este apartado, porque no tienes que hacer nada, por defecto tu aplicación funcionará en Windows Phone 8.1.

  • Silverlight para Windows Phone 8.1:
    • Parto de una aplicación para Windows Phone 8.0.
    • No estoy interesado en hacer una versión para Windows Store.
    • Quiero poder tener acceso a las nuevas APIs de Windows Phone 8.1.
    • Necesito hacer uso de Launchers y Choosers en mi aplicación.
    • Mi aplicación usa como característica importante el acceso a la pantalla de bloqueo.
  • Windows XAML:
    • Parto de una aplicación Windows Store.
    • No parto de una aplicación Windows Store o Windows Phone, empiezo desde 0.
    • Tengo una aplicación para Windows Phone 8.0 pero no hago uso de Launchers y Choosers o la pantalla de bloqueo.
    • Quiero poder tener un proyecto único para mi aplicación Phone y Store, de forma que sea muy sencillo mantener ambas aplicaciones.
  • WinJS:
    • Tengo una aplicación WinJS para Windows Store.

Como podemos ver, para cada uno la situación puede ser distinta y el camino a escoger también. Me gusta que Microsoft haya tenido en cuenta el ofrecer una vía rápida de migración de Windows Phone 8.0 a 8.1, mediante Silverlight. Pero debemos tener en cuenta que se trata de eso, una vía de migración. En mi opinión, si vamos a desarrollar una aplicación nueva deberíamos decantarnos por Windows Xaml / WinJS (según nuestra preferencia de lenguaje) y plantearnos seriamente usar los nuevos tipos de proyectos “Universales” que nos permiten desarrollar para Store y Phone al mismo tiempo. Pero, como ya mencionamos antes, Windows XAML trae consigo muchas APIs nuevas y otras muchas que han desaparecido. ¿Qué APIs vamos a perder en comparación con Silverlight y que alternativas tenemos? Vamos a intentar ponerlas en común:

API Silverlight API Windows XAML Notas
PhotoChooserTask y CameraCaptureTask FileOpenPicker Cuando al FileOpenPicker le añadimos un filtro de archivo de imágenes, muestra un botón para acceder a la cámara, además de permitirnos seleccionar una o varias imágenes del teléfono.
Maps/Call/Mail/Marketplace LaunchUri Muchos Launchers y Choosers se pueden cambiar por Uris estandard.
IconicTile / CycleTile, FlipTile Windows 8.1 tiles Ahora los tiles en Windows Phone 8.1 son los mismos que en Windows Store, por lo que los tres tipos de 8.0 desaparecen, podemos elegir entre cerca de 60 plantillas.
Scheduled Background agent Background Task Las tareas en background pasan a ser las usadas en Windows Store.
MPNS WNS Las notificaciones push dejan de usar el sistema Microsoft Push Notification Service para acoger el Windows Notification Service, de Windows Store.
Share Tasks Share Contract En Windows Phone 8.1 tenemos el mismo contrato de compartir que ya teníamos en Windows Store.
Panorama control Hub control El control panorama desaparece y es sustituido por el control Hub de Windows Store, se mantiene el control Pivot.
LongListSelector GridView/ListView/SemanticZoom Se cambia el control LongListSelector por los Grid/ListView con SemanticZoom.

También hay APIs que desaparecen sin alternativa:

  • Lockscreen, en Windows XAML no tendremos acceso a las APIs para establecer nuestra aplicación como proveedor de la imagen de la pantalla de bloqueo.
  • FMRadio, en Windows XAML no tendremos acceso al API de radio FM.
  • Globalization, se usará el sistema de globalización de Windows Store, por lo que este namespace entero desaparece.
  • Voip, no existe en Windows XAML.
  • Alarm/PeriodicTask/ScheduledAction, no existe en Windows XAML.
  • RadialGradientBrush, no existe en Windows XAML.

Tendremos que tener estas listas en cuenta. Si nuestra aplicación necesita alguna de estas APIs, deberemos usar Silverlight para Windows Phone 8.1.

Pero no todo son pérdidas. También tendremos muchas nuevas APIs que nos brindarán mucha más potencia para nuestros desarrollos:

  • Acceso a la galería de imágenes/videos/documentos y música. Mediante el uso de FileOpenPicker podremos acceder a todos los documentos y archivos multimedia de nuestro dispositivo sin restricciones!
  • APIs criptográficas, para poder leer y trabajar con PKIs, certificados  X509 y soporte de métodos criptográficos estandard.
  • Nueva ApplicationBar, extraida directamente de Windows 8.1, enlazable a datos y con muchas nuevas funcionalidades.
  • Nuevos controles: FlipView, GridView, ListView, SemanticZoom, Menu flyouts, RichTextBox, Hub…
  • Nuevo API MediaPlayer para reproducción en background de audio.
  • Namespace Windows.Media.Editing para ayudarnos a editar video directamente en nuestra aplicación.
  • Nuevas funcionalidades de captura de la pantalla de nuestra aplicación para poder grabar videos de la misma usando el namespace Windows.Media.Capture.
  • Transferencias en background mejoradas.
  • Nuevos tiles.
  • Capacidades de Geofencing, que nos permitirán disparar ejecución de código en segundo plano basado en posicionamiento.
  • NFC: mejor soporte de TAGS, TAGS de solo lectura, escribir TAGS sin formato.
  • Control WebView mejorado (el mismo que en Windows Store).
  • Se suprime el IsolatedStorage completamente para dar paso a la api de Storage de Windows Store.
  • Roaming de settings.
  • Contrato de compartir.
  • Soporte de lectura/escritura en tarjetas SD.
  • Nuevas APIs de notificaciones y Action Center.
  • Integración de DirectX y XAML.
  • WebAuthenticationBroker.

Como podemos ver, muchas y variadas novedades. No obstante una de las novedades, en cuanto a desarrollo, que más resonará es la convergencia de la plataforma. Ya lo hemos mencionado en este artículo varias veces. Con Windows XAML tendremos a nuestra disposición nuevos proyectos que nos permitirán crear aplicaciones para Windows Store y Windows Phone. Lo veremos en el siguiente artículo.

Un saludo y Happy coding!

[Windows Phone 8.1] Presentado en el /Build 2014 el SDK de Windows Phone 8.1

Hola a todos

Hoy durante la keynote del /Build Microsoft ha presentado al mundo la nueva versión de su sistema operativo móvil: Windows Phone 8.1. Esta entrega del sistema cuenta con muchas novedades, pedidas por usuarios y desarrolladores desde hace tiempo. En muchos aspectos estas novedades vienen a cerrar huecos dejados por Windows Phone 8 en cuanto a usabilidad.

En sitios web como The Verge, Engadget, XatakaWindows o WinPhoneMetro encontraremos un gran detalle de todas las novedades dirigidas a los usuarios. Lo que nos interesa en este blog es hablar de las novedades para los desarrolladores. En este sentido hay muchas, algunas más complejas que otras, novedades.

En este primer artículo, vamos a dar un repaso a las herramientas, requisitos y novedades en Visual Studio 2013 que incorpora el SDK de Windows Phone 8.1.

Existen diferentes versiones del SDK publicado hoy, dependiendo de la versión de Visual Studio 2013 que uses:

Herramientas

El SDK de Windows Phone 8.1 hace uso de Visual Studio 2013 como entorno de desarrollo. Tiene los siguientes requisitos para instalarlo:

  • Windows 8.1 Pro o superior
  • HyperV
  • Soporte de hardware para SLAT
  • 4Gb RAM (8Gb recomendados para los emuladores más grandes)

Y ¿Qué incluye el SDK? Al igual que el SDK de Windows Phone 8.0 tendremos una serie de herramientas/accesorios instaladas con el SDK:

  • Windows Phone Application Deployment 8.1: Sirve para, a partir de un paquete compilado, poder instalar una app en un emulador o dispositivo físico.
  • Windows Phone Developer Registration 8.1: Para poder registrar nuestro dispositivo para desarrollo. Si tenemos cuenta de desarrollador, podremos registrar hasta 3 dispositivos. Si no tenemos cuenta de desarrollador, con nuestro LiveID podremos registrar un dispositivo.

Además, como es tradicional, encontraremos Microsoft Blend para trabajar en nuestra interface de usuario. Si no disponemos de ninguna versión comercial de Visual Studio 2013, el SDK nos instalará una versión Express para que podamos trabajar sin ningún problema.

Y por supuesto, el plato fuerte, los emuladores. En esta última versión del SDK se incluyen 6 emuladores. En Windows Phone 8 los emuladores se diferenciaban por la resolución que usaban simplemente, pero existía una gran carencia: El tamaño de pantalla. En muchas ocasiones la resolución no es tan determinante como el tamaño de la pantalla en uso. Por ejemplo, si tengo un dispositivo 1080P con una pantalla de 4.5”, la interface será la misma que otro dispositivo de 720P con el mismo tamaño de pantalla. Pero un dispositivo con WXGA (768x1280) de 6” tendrá una interface diferente. Esto se debe a que lo que realmente importa más es el tamaño físico de pantalla, el área de pantalla que el usuario tiene para interactuar. Muchos hemos dado la vara a Microsoft para que tuviese esto en cuenta en los emuladores y, finalmente, así fue. De esta forma, encontramos emuladores divididos por resolución y por tamaño de pantalla:

Nombre Resolución Pantalla Memoria
Emulator 8.1 WVGA 4 inch 512MB WVGA (480x800) 4 pulgadas 512Mb
Emulator 8.1 WVGA 4 inch WVGA (480x800) 4 pulgadas 1024Mb
Emulator 8.1 WXGA 4 inch WXGA (768x1280) 4 pulgadas 1024Mb
Emulator 8.1 720p 4.7 inch 720P (720x1280) 4.7 pulgadas 1024Mb
Emulator 8.1 1080P 5.5 inch 1080P (1080x1920) 5.5 pulgadas 1024Mb
Emulator 8.1 1080P 6 inch 1080P (1080x1920) 6 pulgadas 2048Mb

Como podemos ver, tenemos casi cualquier combinación de dispositivo que podamos encontrar en el mundo real. Esto nos va a facilitar la tarea de adaptar nuestra app a diferentes resoluciones y tamaños de pantalla sin tener que comprar 1001 dispositivos.

Estos emuladores además incluyen nuevas herramientas extendidas que nos ayudarán en nuestro desarrollo:

  • Un simulador de red mejorado.
  • Un simulador de notificaciones.
  • Herramientas para simular geofencing.
  • Mapeo de la tarjeta SD del emulador a un directorio local de nuestro PC.
  • Creación de Checkpoints del emulador, para poder guardar su estado y recuperarlo en otro momento.
  • Configuración de los sensores presentes en el emulador.

image

Una nueva herramienta que incorpora Windows Phone 8.1 es “Developer Power Tools”, que encontraremos en el submenú “Windows Phone 8.1” del menú “TOOLS” de Visual Studio.

Esta herramienta tiene tres pestañas: Application verifier, Performance monitor y Performance recorder.

Application verifier nos permite listar todas las aplicaciones desplegadas en el dispositivo y marcar una serie de tests y comprobaciones tales como memory leaks, manejadores, bloqueos… al presionar el botón “Apply” se ejecutarán las comprobaciones y se marcará el estado de la aplicación.

image

Performance monitor nos permite ver en tiempo real el consumo de recursos del sistema en general o en particular en nuestra aplicación. Uso de CPU, memoria, operaciones de entrada y salida, todo con información bastante detallada. Además nos permite guardar un

image

Por último la pestaña Performance recorder nos permite guardar un log ETL de la actividad de nuestra aplicación, consumo de memoria o CPU, XAML, fallos de audio o video, actividad de GPU y muchos más parámetros.

image

Luego podremos abrir este log con la aplicación Windows Performance Analyzer, donde podremos ver en detalle cada una de las propiedades que hayamos marcado para monitorización:

image

Además, ahora dispondremos de la herramienta Performance and diagnostics para nuestras aplicaciones Windows XAML (Tanto Phone como Store) para poder realizar análisis más exhaustivos de nuestras aplicaciones:

image

Uso de CPU, Memoria, consumo de energía o respuesta de la UI XAML/HTML, así como varias herramientas de testing de rendimiento de Javascript.

Las plantillas de desarrollo de Visual Studio también han sufrido muchos cambios, tantos que les vamos a dedicar un artículo completo. Pero primero repasaremos los nuevos frameworks y opciones de desarrollo que tendremos disponibles, en el próximo artículo. Mientras tanto, puedes ir descargando el SDK de Windows Phone 8.1 aquí. Juega con él un poco y nos vemos en breve con más novedades.

Un saludo y Happy Coding!

[Windows Phone 8.1] Las nuevas aplicaciones universales

Hola a todos!

En el primer artículo de esta serie sobre Windows Phone 8.1 hablamos de las nuevas herramientas, en el segundo hablamos sobre los nuevos modelos de desarrollo. En esta ocasión toca hablar sobre una de las mayores novedades: Las aplicaciones universales. Comencemos!

Después de ver las nuevas herramientas, APIs y tipos de desarrollo, vamos a examinar las nuevas plantillas que tenemos a nuestra disposición. En este sentido también se han producido muchos cambios.

image_thumb16

Como podemos ver en la captura anterior, se han reorganizado las plantillas de proyecto de Windows Store, creando una nueva categoría “Store” que engloba tres subcategorías:

  • Universal Apps. Los nuevos tipos de aplicaciones universales que nos permiten desarrollar apps para Windows Store y Windows Phone 8.1
  • Windows Apps. Aquí encontraremos las plantillas que ya existían para Windows Store.
  • Windows Phone Apps. Aquí tendremos las plantillas de Windows XAML para Windows Phone 8.1.

Además, seguimos teniendo la categoría Wndows Phone, donde tendremos las plantillas para trabajar con Silverlight para Windows Phone (8.0 y 8.1).

La mayor novedad en este sentido viene en las plantillas universales. ¿Qué es una aplicación universal? Este concepto de “universal” nos indica que podremos crear un proyecto en el que facilmente podremos compartir XAML, código y recursos entre una aplicación Windows Store y una aplicación Windows Phone 8.1. Básicamente se crea un proyecto “Universal” que internamente contendrá tres sub proyectos:

  • Windows, con todo lo específico de Windows Store.
  • Windows Phone, con todo lo específico de Windows Phone.
  • Shared, con todo el código que queramos compartir entre ambas plataformas.

image_thumb19

Con esta organización será muy sencillo compartir código entre ambos sistemas. Por defecto, el app.xaml (y app,xaml.cs) yo se incluye en el proyecto Shared, por lo que es compartido para ambas plataformas. Imágenes comunes, controles que queramos reaprovechar (si, también podemos compartir XAML), Converters, ViewModels, Servicios de acceso al hardware, Diccionarios de recursos, incluso los archivos RESW con idiomas, pueden ser colocados en el proyecto shared.

image_thumb5

Luego, simplemente tendremos que colocar en cada proyecto particular las páginas de la aplicación. ¿Podríamos compartir las páginas también? Bueno, técnicamente si. Pero no funcionaría a nivel de experiencia de usuario. Los tamaños de pantalla entre una aplicación Store y Phone son muy diferentes. Algo tan básico como la orientación, que en Phone es vertical mientras normalmente en Store es horizontal, hace que usar la misma página para ambas sea muy complicado. De esta forma, en nuestros proyectos Phone y Store, acabaríamos teniendo las páginas que componen la aplicación y quizás alguna pieza de código que no queramos compartir por ser exclusiva de la plataforma:

image_thumb8[1]

Lo mejor es que, desde el proyecto Shared tendremos acceso a cualquier objeto creado en los proyectos específicos y viceversa. Desde cualquiera de los proyectos de Phone o Store tendremos total acceso al código del proyecto Shared. De esta forma podremos compartir la gran mayoría de código. Siempre encontraremos ciertas cosas que difieren entre las plataformas o funcionalidades que están solo en una de ellas.

Por poner un ejemplo, podemos hablar del FileOpenPicker. En Windows Store usamos los métodos PickSingleFileAsync o PickMultipleFilesAsync. Estos métodos devuelven, respectivamente, un StorageFile o una lista de StorageFile. Al invocarlos, nuestra aplicación sigue en ejecución mientras sobre ella se carga la interface del selector. El problema en Windows Phone viene dado por los dispositivos de baja memoria. En la mayoría de los casos resultaba imposible mantener abierta la aplicación mientras se cargaba la interface del picker. La solución llego por crear dos nuevos métodos llamados PickSingleFileAndContinue y PickMultipleFilesAndContinue. Fijaros  que estos métodos no son asíncronos. No devuelven nada. Cuando los invocamos, nuestra aplicación se suspende y se lanza la aplicación del selector. El usuario selecciona un archivo, presiona atrás o cancela y en ese momento se restaura nuestra aplicación, enviando en los argumentos del evento Activated el resultado de la operación. Debemos ser nosotros los encargados de enviar el archivo a la página/viewmodel correcta y gestionar el estado de la misma. ¿Como podemos compartir este código? Pues de dos formas distintas:

  • Podemos crear un servicio, cuya interface esté en el proyecto Shared y tenga una implementación distinta para cada plataforma.
  • Podemos usar bloques condicionales de compilación. Por defecto el proyecto universal define el símbolo WINDOWS_APP en el proyecto Windows Store y WINDOWS_PHONE_APP en el proyecto Windows Phone.

En próximos artículos hablaremos a fondo de los pickers disponibles y como usarlos. De la misma forma ocurre con algunas cosas más como las transiciones entre páginas. Por lo que, aunque podremos compartir un 80 o 90% del código todavía tendremos algunas cosas para las que tendremos que usar alguno de los puntos anteriores. Pero otras estarán totalmente unificadas: El sistema de navegación, el XAML y los controles, localización… y muchas cosas más.

Otra novedad para los proyectos universales, es que ahora dispondremos de Portable Class Libraries con soporte completo WinRT. Hasta el momento en una PCL solo podíamos usar código .NET. Con el nuevo SDK, tendremos como target Windows Store (Windows 8.1) y Windows Store (Windows Phone 8.1). Si seleccionamos estos dos frameworks solamente, la librería nos permitirá tener código WinRT, incluso XAML dentro de ella.

Y con esto llegamos al fin de este artículo. En el próximo empezaremos a ver código de verdad, con algunos ejemplos de las novedades que incluye Windows Phone 8.1.

Un saludo y Happy Coding!

[Windows Phone 8 ] Tip: Memoria y trabajo con imágenes.

Hola a todos!

En las plataformas móviles como Windows Phone 8 o Windows Store, nuestras aplicaciones tienen unas restricciones claras en el uso de memoria, a diferencia de los sistemas de escritorio que podían ocupar toda la memoria disponible en el sistema.

Hay muchas formas de controlar la memoria que usamos en nuestra aplicación. Aplicar bloques using, usar Dispose correctamente… Pero cuando trabajamos con imágenes, con objetos WriteableBitmap, BitmapImage o BitmapSource, descubriremos que nada de esto sirve.

Por norma general, si desarrollamos bien nuestro código, iremos aumentando el uso de la memoria hasta que llegue un punto en el que, debido a la presión que estamos ejerciendo sobre ella, el recolector de basura (GC, Garbage Collector) entre en escena y libere la memoria no usada.

El problema es que los objetos WriteableBitmap, BitmapImage o BitmapSource en Windows Phone 8 y Windows Store, realmente ocupan muy poca memoria manejada, apenas unos cuantos Kb. Realmente el peso de la memoria es nativo, no manejado en el objeto, ya que la imagen está almacenada en memoria nativa. Por esta razón, el Garbage Collector no es presionado a lanzarse, su memoria manejada no crece peligrosamente. Sin embargo el sistema operativo tiene en cuenta tanto la memoria nativa como la manejada para calcular nuestra cuota de uso.

Una práctica que muchos desarrolladores suelen llevar a cabo llegado este punto, es forzar la recolección de memoria invocando manualmente al Garbage Collector. Esto está totalmente desaconsejado, puesto que en primer lugar va a ralentizar nuestra app muchísimo durante la recolección, pero además puede tener efectos secundarios en la ejecución de nuestra app. Lo mejor, es que existe una forma de evitar esto: hacer que el GC se entere de la memoria que realmente estamos usando.

Existen dos métodos en la clase GC, que son dos grandes desconocidos: AddMemoryPressure y RemoveMemoryPressure. Estos dos métodos nos permiten informar al runtime de grandes bloques de memoria nativa que está siendo usada o que está dejando de ser usada, respectivamente, de forma que el runtime pueda tener en cuenta esta memoria para programar los ciclos de ejecución del recolector de basura. Ambos reciben un solo parámetro, de tipo long, que indica los bytes que estamos añadiendo a la memoria.

De esta forma, cuando por ejemplo carguemos una imagen en memoria y la añadamos a una lista, debemos indicar al sistema el peso que estamos añadiendo en la memoria usando AddMemoryPressure:

AddMemoryPressure
void task_Completed(object sender, PhotoResult e)
{
    WriteableBitmap bmp = new WriteableBitmap(100, 100);
    bmp.SetSource(e.ChosenPhoto);
    listImages.Items.Add(bmp);
    GC.AddMemoryPressure(40000000);
}

De la misma forma, cuando eliminemos o dejemos de usar esa imagen, podemos informar al runtime de que la hemos liberado:

RemoveMemoryPressure
private void RemoveImage()
{
    listImages.Items.RemoveAt(0);
    GC.RemoveMemoryPressure(40000000);
}

Y Voila! Permitimos que sea el sistema el que se ocupe de organizar las recolecciones de memoria y mantener la misma siempre saneada. Sin tener que forzarlas por nuestra parte ni sufrir la lentitud y efectos secundarios de ello.

Un pequeño tip, que espero que os ayude en vuestros desarrollos si trabajáis con muchas imágenes dinámicas o editando imágenes grandes.

Más información: AddMemoryPressure y RemoveMemoryPressure

Un saludo y Happy Coding!

 

[WPSUG] Hangout: Almacenamiento en la nube

Hola a todos!

Logo-256_png-160x0

En WPSUG volvemos a la carga con un nuevo hangout. En esta ocasión hablaremos sobre sistemas de almacenamiento en la nube que podemos integrar en nuestras aplicaciones. Estaremos acompañados por los sospechosos habituales:

  • Roberto Luis Bisbe, hablando sobre Dropbox y Box.
  • Quique Martínez, hablando sobre Azure Storage.
  • Javier Suarez, hablando sobre OneDrive.
  • Pedro Hurtado, hablando sobre Google Drive.
  • Santiago Porras, para comentar la jugada.
  • Un Servidor para atraerlos a todos y atarlos en las tinieblas…. digo en el hangout.

Realizar copias de seguridad, ofrecer a nuestros usuarios la posibilidad de cargar o guardar datos en nuestras apps y miles de situaciones más, requieren el uso de servicios externos de almacenamiento. ¿Como conectamos con ellos? ¿Qué podemos y que no podemos alojar en estos servicios? ¿Como de seguros son? ¿Que tan fácil o difícil es usarlos? Ven al hangout para encontrar respuesta a todas estas y más preguntas!

El Hangout tendrá lugar el miercoles 26 de Marzo, a las 19:00 horas (GMT+1). Podrás seguirnos directamente en esta URL: https://www.youtube.com/watch?v=2PyBLPvePEs

Espero veros a todos allí.

Un saludo y Happy Coding!

[Windows Phone 8] Preparar y administrar una Beta

Hola a todos!

El artículo de hoy no tiene un gran contenido técnico. En su lugar, quiero hablaros de la importancia de usar la distribución beta antes de lanzar nuestra aplicación al gran público, como crearla, distribuirla y administrarla para que nos ofrezca valor, sin que se nos escape de las manos.

Empecemos por ver que nos ofrece la distribución beta en Windows Phone. En primer lugar, nos facilita distribuir nuestra aplicación a un grupo de gente que la quiera probar y que pueda aportarnos feedback, descubrir fallos y ayudarnos a arreglarlos. Podríamos hacer esto mismo simplemente enviando el archivo XAP compilado por correo, pero eso exigiría que cada una de las personas que la vayan a probar tengan el SDK y un teléfono desbloqueado para desarrollo. Lo más importante en este punto es que quienes vayan a probar la beta, no tienen porqué ser desarrolladores. De echo sería muy bueno que no fuesen desarrolladores, para tener opiniones de alguien que no esté “contaminado” por la tecnología. Además, tenemos que simplificar el acceso a la beta, al distribuirla por la tienda de apps, se puede instalar directamente en el dispositivo sin necesidad de hacer nada más que click en un enlace.

Cuando vayamos a publicar nuestra aplicación, solo tendremos que seleccionar la opción “Beta” en “Distribution channels”, dentro del desplegable “More options”. Al seleccionar esta opción se habilitará una caja de texto donde deberemos introducir los LiveIDs de los participantes de la beta:

image

Aquí podemos encontrarnos con la primera dificultad. La distribución Beta nos permite tener hasta 10.000 LiveIDs añadidos, ¿Como gestionamos todo esto? Hay mil formas. Desde algo tan simple como un archivo de texto o un excel, hasta sistemas que nos aporten más funcionalidad. Precisamente, yo creo que esta segunda opción es la mejor, usar un sistema que nos permita tener más funcionalidad. En la gran mayoría de casos, los LiveIDs son también los correos electrónicos de esas personas, y nuestra principal vía de comunicación con ellos. Por cada versión beta, podemos comunicarles que ya está disponible, que incluye, que bugs son conocidos para que no pierdan su tiempo con ellos y darles cualquier indicación que sea necesario. Para gestionar todo esto, yo he escogido una herramienta muy usada, llamada MailChimp:

image

MailChimp es una herramienta para crear campañas de correo, manteniendo listas de distribución. Nos ofrece funcionalidad para crear formularios de registro, listas de personas suscritas, crear campañas de correo (enviar correos electrónicos a las listas), programar el envío de una campaña para una fecha/hora concreta e incluso estadísticas de quien ha abierto un correo de una campaña, quien ha hecho click en un enlace de esa campaña… Además podemos exportar la lista de personas suscritas a un archivo csv, que nos será muy útil para añadir los correos a la distribución beta. En Definitiva tenemos una forma de gestionar todas las comunicaciones con nuestros suscriptores, de permitir que nueva gente se suscriba a nuestras betas (porque, ¿Para que mantenerla privada? Cuanta más gente la pruebe, mejor!) o si ya no le interesa, se des suscriba cuando quiera.

Es realmente de usar y totalmente gratis. Una vez registrados, lo primero que tendremos que hacer es crear una lista:

image

Dentro de las opciones de la lista, encontraremos una llamada “Sign up forms” que nos permitirá crear y personalizar el formulario de suscripción, para adaptarlo al aspecto de nuestra aplicación e incorporar los campos que necesitemos pedir al usuario:

image

Solo alguna recomendación aquí:

  • Mantén el formulario lo más simple posible, no pidas datos que no vas a necesitar. Pidiendo muchos datos puedes acabar con el interés del usuario.
  • Personalízalo un poco. No te digo que inviertas 5 días en crear un formulario impresionante, pero un par de horas, para darle un aspecto que recuerde a tu app, si. Queda más profesional, y vas introduciendo al usuario a tu visión, a lo que se va a encontrar en la app.
  • Por lo menos, incluye dos idiomas: Inglés y Español. Así te aseguras que la gente que llegue a la página, podrá entender de que va. Puedes hacerlo poniendo ambos idiomas en la misma página o mediante traducciones. Como más gustes.

Una vez terminado el formulario, en la parte superior encontrarás una URL corta que da acceso a él. Cógela y lánzala al mundo: Twitter, Facebook, correo… cualquier medio es valido para llegar a la gente. pon la url y tu mensaje en inglés y español, es interesante salir de “la tierra” y tener usuarios de la beta por todo el globo, ofreciéndote su visión particular sobre la app.

Otro punto interesante es tener una cuenta de correo nueva para la aplicación, en mi caso photolabapp@outlook.com, cuando creemos una campaña de MailChimp nueva, usaremos esa misma cuenta como remitente y pediremos a los usuarios que envíen su feedback a ella. De esta forma separamos el feedback de nuestros otros correos personales o profesionales y mantenemos cierto orden en las comunicaciones.

Y por último nos queda gestionar el feedback recibido. Principalmente recibiremos dos tipos de elementos: bugs, que tendremos que ir corrigiendo, y mejoras, que implementaremos o no. Es muy recomendable que tengamos la mente abierta a las sugerencias de nuestros usuarios. En muchos casos pueden proponer cosas que no se nos habían ocurrido pero que realmente mejoran la app muchísimo. Es importante priorizar y llevar un control de estos bugs y mejoras. ¿Como? Pues como más cómodo te resulte, pero si partimos de la base de que usas TFS Online (www.visualstudio.com) para gestionar tu código, puedes crear iteraciones, una por beta por ejemplo, e introduciendo en ella el feedback de los usuarios. Así al final, cuando vayas a enviar la siguiente beta, podrás adjuntar un resumen de las mejoras y correcciones introducidas y de lo que tienes pendiente:

image

Y Voila, solo queda repetir una y otra vez hasta que el feedback sea mínimo, los bugs estén corregidos… y estemos listos para sacar nuestra app al gran público. ¿Y cuanto es eso? Pues en el caso de PHOTOLab, realicé 5 versiones beta. Lancé la primera tan pronto como el core de la app estaba listo para ser probado. Por último, en mi tierra dicen eso de “Es de bien nacidos, ser agradecidos”, por lo que yo personalmente recomiendo agregar una sección de gracias en el acerca de de tu app, para agradecer a toda la gente que te ha dado feedback y ha invertido tiempo probando tu app desinteresadamente:

unnamed

Que así por lo menos vean que aprecias su ayuda. Seguro que la próxima vez que les pidas que te ayuden con una revisión, estarán encantados de hacerlo.

Y con esto terminamos este artículo. Aun no habiendo tocado ningún tema técnico, de código, creo que es muy importante saber, primero, que las betas existen y que podemos usarlas. Y segundo, que manejarlas adecuadamente y hacer caso a nuestros usuarios, puede reportarnos muchos beneficios y ahorrarnos muchos problemas y perdidas de tiempo.

El próximo artículo, si tendrá código, lo prometo. :-)

Un saludo y Happy Coding!

[Windows Phone 8] Monetizar nuestra app: In App Purchase

Hola a todos!

euros

Hoy quiero hablaros de como monetizar vuestras apps usando In App Purchase (IAP). Sorprendentemente, IAP es un método de monetización que se puede encontrar en juegos pero que no se usa en apps tanto como debería.

Básicamente, IAP nos permite incorporar pagos dentro de nuestra aplicación, ya sea esta gratuita o tenga coste inicial. Existen dos tipos de “bienes” que podemos adquirir usando IAP: Consumibles y Perpetuos:

  • Los bienes consumibles son aquellos que podemos adquirir y una vez usados, desaparecen. Por ejemplo, monedas o un power up.
  • Los diebes perpetuos son aquellos que una vez adquiridos, nunca desaparecen. Por ejemplo, un pack de funcionalidades extra.

Implementar IAP en nuestra aplicación es muy sencillo y nos ofrece muchas ventajas. Con IAP hacemos que nuestra app sea de modelo “freemium”, es decir, gratuita y con pagos por contenidos o funcionalidades extra. Hay que ser muy cuidadoso con este aspecto, buscando equilibrio entre el cobro de partes de nuestra aplicación y su funcionamiento básico. En todo momento, debería ser posible usar la aplicación sin problemas sin pagar. Siendo estos micro pagos una forma de añadir funcionalidades nuevas.

Otra forma de usar IAP es para eliminar publicidad. Hoy en día es muy complicado que una app media genere beneficios mediante publicidad. En muchos casos, molestamos al usuario con publicidad, y no ganamos apenas más que unos céntimos al día. Al final, estamos “regalando” el espacio de anuncio y molestando a nuestro usuario y solo el anunciante se beneficia de ello. Un truco muy usado es incluir sobre la publicidad un botón de eliminar, normalmente una X, que quite la publicidad de la app mediante un IAP, de 0.99€ normalmente. De esta forma, si al usuario le molesta la publicidad o quiere recompensarnos directamente por nuestro trabajo, solo tiene que pagar este IAP y ambos ganan, desarrollador y usuario. Si no le molesta o no quiere pagar por quitar la publicidad, nos producirá los beneficios normales de la misma. En combinación, siempre vamos a ganar más dinero, conseguir generar 0.99€ con publicidad no es tarea fácil.

Creo que esta última opción es la más útil para una aplicación que no sea un juego. Es en la que me quiero centrar en este artículo. Las APIs para trabajar con IAP se encuentran en el namespace Windows.ApplicationModel.Store, en la clase CurrentApp. En esta clase encontraremos un método llamado RequestProductPurchaseAsync, que nos permitirá lanzar la pantalla de compra de un elemento IAP y la clase LicenseInformation que contiene un diccionario llamado ProductLicenses con el estado de todos los productos que podemos comprar en nuestra aplicación. Por ejemplo, imaginemos que tenemos un item IAP llamado REMOVEADS. El código para lanzar la pantalla de compra del mismo sería este:

Comprar un item IAP
public async Task PurchaseRemoveAds()
{
    try
    {
        await CurrentApp.RequestProductPurchaseAsync("REMOVEADS", false);
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

Muy sencillo. El primer parámetro es el Id del artículo que deseamos comprar y el segundo indica si se debe devolver un ticket de compra que podamos mostrar al usuario. Fijaros que tenemos el método envuelto en un bloque try/catch. Esto es debido a que, si el usuario cancela la compra o esta no se puede realizar por algún motivo, el método RequestProductPurchaseAsync devolverá una excepción con un valor HRESULT H_FAIL. (Para otro día dejamos el tema de Microsoft y los errores descriptivos).

Para comprobar si un item concreto, por ejemplo REMOVEADS, ha sido comprado por el usuario, podemos usar el siguiente código:

Comprobar compra
public bool AdsRemoved()
{
    var product = CurrentApp.LicenseInformation.ProductLicenses["REMOVEADS"];
    if (product != null && product.IsActive)
        return true;

    return false;
}

Y listo, podemos usar el método AdsRemoved para saber cuando mostrar u ocultar los anuncios en la aplicación. La propiedad IsActive devolverá true si el item se ha comprado y false de lo contrario.

Ahora, ¿Como podemos probar nuestro código antes de publicar la aplicación? Existen dos formas principalmente: Usando la publicación en beta o haciendo un mock de In App Purchase. Yo personalmente prefiero la primera, la publicación en beta, porque pruebo el proceso real al 100% (menos en la parte de cobrar, los IAP en beta tienen coste 0 siempre).

Si queréis leer a fondo sobre como realizar un Mock del IAP para pruebas, podéis leer más aquí. El problema del mock, es que al final te quedas con la duda de si realmente todo va a ir bien una vez subas tu app a la tienda. Por lo que acabas probando una distribución beta, así que, ¿Porqué no hacerlo desde el principio?

DISCLAIMER: El Mock puede ser una buena solución en escenarios complejos, donde por ejemplo tengas que probar lógica asociada a las compras, los items sean consumibles que caducan, etc… Pero creo que para un escenario como este, no son necesarios.

Así que vamos allá, una vez que tengas todo tu código en su sitio y lo hayas probado, verás que siempre que intentas hacer una compra, esta falla. Es normal, ya que el proceso va a los servidores de Microsoft a buscar los items asociados con tu aplicación y no encuentra ninguno. Así que lo primero que tienes que hacer es publicar tu aplicación en modo beta. El proceso de publicación es el mismo que para una aplicación normal, salvo que en el primer paso, App Info, en la sección More options debemos seleccionar Beta. Al hacerlo se habilitará el cuadro de texto que tiene debajo, donde debemos indicar, separados por punto y coma, los liveIDs de los participantes de la beta. Normalmente para probar los IAP, en primer lugar usaremos solo nuestro LiveID, para asegurarnos que todo va bien. El resto del proceso es totalmente igual. Una vez que hayamos publicado nuestra aplicación en beta, podemos añadirle productos. En nuestro caso se llamará REMOVEADS. Para ello pulsamos sobre la aplicación en el Dashboard y vamos a la última pestaña: Products, donde encontraremos un enlace Add in-app product.

image

Debemos seguir varios pasos, al igual que en la publicación de la aplicación y al terminar el producto pasará a certificarse. Si, los productos de IAP también pasan su propia certificación. Pero en nuestro caso, al estar trabajando sobre una beta, no tardará más de unos minutos. Es muy importante asegurarnos de que introducimos el mismo ID de producto que usamos en el código o no funcionará.

image

Ten en cuenta que puedes definir varios idiomas para cada producto, siendo recomendable que traduzcas el nombre y la descripción a los mismos idiomas que soportes en la app. Así mismo necesitarás un icono de 300x300 píxeles para el producto.

Y listo, una vez que la beta esté publicada, podremos instalarla en nuestro dispositivo y, si hemos hecho todo bien, deberíamos poder comprar el producto sin ningún problema.

Lo que más me gusta de este proceso, es que es rapidísimo, en unos 15 minutos todo está publicado y podemos probarlo en vivo y en directo. Además estamos probando el proceso real, puesto que lo único que cambiará cuando publiquemos es que no usaremos una beta y podremos poner un precio al producto.

Importante: Una vez que hayas terminado de probar y te dispongas a publicar tu aplicación de forma definitiva, recuerda eliminar el producto creado de la beta, pues aunque los productos se definen por aplicación, su ID debe ser único. Debido a esto tienes que eliminar el producto beta para poder crear el final.

Espero que esto os pueda ayudar a monetizar vuestras aplicaciones. Animaros a incluir IAP en ellas, porque al final todo se trata de ofrecer al usuario formas de pagar por nuestro trabajo, ya sea mediante anuncios o mediante compras. Además, con este sistema vuestra app sigue siendo gratuita, por lo que más usuarios se la descargarán.

Un saludo y happy Coding!

[HANGOUT WPSUG] Azure Mobile Services y Microsoft AppInsights

Logo-256_png-160x0

Hola a todos!

Hoy tenemos a dos grandes de la comunidad invitados al hangout mensual de WPSUG.

Hablo de Quique Martinez (Windows Azure MVP) y Rafael Serna (Nokia Developer Champion).

Como podréis adivinar, el hangout de hoy estará dedicado a la nube. En concreto, Rafa nos hablará de Azure Mobile Services y Quique de Microsoft Application Insights, una nueva tecnología, actualmente en preview, para monitorizar nuestras aplicaciones móviles (Windows Store y Windows Phone) y nuestros servicios.

¿Cuando?

Hoy jueves 20 a las 19:00 (GMT+1)

¿Donde?

En YouTube, en la siguiente dirección: http://www.youtube.com/watch?v=ut3Ykb3mQD0

Os esperamos!!

Recordad también que podéis acceder a nuestro canal de YouTube para poder ver los videos de los hangouts anteriores.

Un saludo y Happy Coding!!

[Windows 8.1] Listas paginadas

Hola a todos!

Hoy vamos a cambiar un poco de temática, para hablar de paginación en apps Windows Store para Windows 8.1.

En Windows Phone 8, usamos la capacidad del LongListSelector para detectar el final de la lista y poder lanzar la carga de más elementos. En Windows Store no disponemos de LongListSelector. En su lugar usamos un control GridView o ListView. Estos controles no tienen la capacidad de detectar la compresión final para cargar más elementos. En su lugar, realizan la carga de más páginas automáticamente usando la interface ISupportIncrementalLoading.

Esta interface debe estar implementada en la colección que enlazamos al GridView o ListView. Por defecto no existe ninguna colección que la implemente por lo que tendremos que crearnos la nuestra propia. Para ello podemos partir de una ObservableCollection. ISupportIncrementalLoading implementa una propiedad de solo lectura llamada HasMoreItems y un método llamado LoadMoreItemsAsync:

ISupportIncrementalLoading
public class PaginatedCollection<T> : ObservableCollection<T>, ISupportIncrementalLoading
{

    public bool HasMoreItems
    {
        get { throw new NotImplementedException(); }
    }

    public IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
    {
        throw new NotImplementedException();
    }
}

Normalmente necesitaremos usar este tipo de colección con más de un tipo de dato y la carga de más páginas, en el método LoadMoreItemsAsync, también variará. Para solventar esto podemos usar una táctica parecida a la empleada en el DelegateCommand en MVVM. Vamos a añadir un constructor que se encargue de recibir dos Func<T>: Uno para saber si debemos cargar más elementos y otro para cargarlos:

PaginatedCollection ctor
Func<uint, IEnumerable<T>> getMoreItems;
Func<bool> getHasMoreItems;

public PaginatedCollection(Func<uint, IEnumerable<T>> _getMoreItems, Func<bool> _getHasMoreItems)
{
    getMoreItems = _getMoreItems;
    getHasMoreItems = _getHasMoreItems;
}

Ahora simplemente, la propiedad HasMoreItems llamará a getHasMoreItems:

HasMoreItems
public bool HasMoreItems
{
    get
    {
        return getHasMoreItems();
    }
}

En el método LoadMoreItemsAsync, tendremos que trabajar un poco más. Básicamente debemos realizar los siguientes pasos:

  1. Llamar a getMoreItems
  2. Insertar los elementos nuevos en la colección base
  3. Devolver un nuevo LoadMoreItemsResult con el conteo de elementos recibidos.

Pero existen ciertas peculiaridades. El método LoadMoreItemsAsync devuelve un tipo IAsyncOperation<LoadMoreItemsResul>. Tendremos que ejecutar nuestro código en una Task para luego convertirlo a IAsyncOperation. Pero al ejecutar el código en una Task, si intentamos añadir elementos a la colección base obtendremos una excepción cross thread. Para evitar esta excepción, antes de modificar el método LoadMoreItemsAsync, vamos a añadir una propiedad pública y estática a nuestra clase App, para poder exponer el Frame de la aplicación y acceder fácilmente al Dispatcher que contiene, de forma que podamos usar el hilo principal de UI para añadir elementos a la colección. ¿Porqué? Pues por que la base de nuestra colección es una ObservableCollection, que notifica a la UI cada vez que su contenido cambia (al añadir o eliminar un elemento) y esta notificación debe producirse desde el hilo principal de interface de usuario:

Static RootFrame
sealed partial class App : Application
{
    public static Frame RootFrame { get; set; }

Una vez hecho esto, ya podemos escribir el código del método LoadMoreItemsAsync:

LoadMoreItemsAsync
public IAsyncOperation<LoadMoreItemsResult> LoadMoreItemsAsync(uint count)
{
    return Task.Run<LoadMoreItemsResult>(async () =>
    {
        var newItems = getMoreItems(count);

        await App.RootFrame.Dispatcher.RunAsync(CoreDispatcherPriority.Normal,
        () =>
        {
            foreach (var item in newItems)
                base.Add(item);
        });


        return new LoadMoreItemsResult() { Count = (uint)newItems.Count() };
    }).AsAsyncOperation<LoadMoreItemsResult>();
}

En este código, lo primero que hacemos es devolver una ejecución de una Task, como una AsyncOperation de LoadMoreItemsResult. Internamente dentro de esta Task, llamamos al Func<uint, IEnumerable<T>> que recibimos en el constructor, getMoreItems, pasándole el conteo de elementos que nos pide la interface de usuario. Esto puede ser muy útil si nuestra petición de nuevos datos permite indicar cuantos elementos obtener.

Una vez que recibimos los elementos, usamos el método RunAsync del dispatcher incluido en el RootFrame para, mediante un foreach, añadir cada elemento devuelto a la colección base. Por último la tarea devuelve un nuevo LoadMoreItemsResult, con el número de elementos devueltos.

Ya tenemos el código de nuestra clase PaginatedCollection<T> terminado. Ahora llega el momento de usarla en una ViewModel. En primer lugar creamos una variable privada y una propiedad pública, como con cualquier otra lista:

Public property use
private PaginatedCollection<string> collection;
public PaginatedCollection<string> Collection
{
    get { return collection; }
    set
    {
        collection = value;
        RaisePropertyChanged();
    }
}

A continuación vamos a escribir dos métodos privados, uno para devolver true/false y otro para obtener nuevos elementos. Deben coincidir con la firma que hemos declarado en la colección: Func<bool> y Func<uint, IEnumerable<T>> respectivamente:

HasMoreItems & GetMoreItems
private bool HasMoreItem()
{
    if (elementCount > 100)
        return false;

    return true;
}

private IEnumerable<string> GetMoreItems(uint count)
{
    IList<string> list = new List<string>();

    for (int i = 0; i < count; i++)
    {
        list.Add(string.Format("string number {0}", i));
    }
    elementCount += count;

    return list;
}

En este ejemplo, para no complicarlo, no estamos llamando a ningún servicio, simplemente cada vez que se nos piden datos, creamos nuevas strings. Exactamente el número que nos pide la lista. mientras ese número esté por debajo de 100, seguimos devolviendo true en nuestro método boolean. Por último, en nuestro constructor, inicializamos la nueva colección:

Collection constructor
public MainViewModel()
{
    collection = new PaginatedCollection<string>(GetMoreItems, HasMoreItem);
}

Y ahora solo nos queda el XAML. Para este ejemplo usaremos un GridView. También podríamos usar un ListView, que soporta paginación.

GridView XAML
<GridView ItemsSource="{Binding Collection}"
            IncrementalLoadingThreshold="1"
            IncrementalLoadingTrigger="Edge">
    <GridView.ItemTemplate>
        <DataTemplate>
            <Grid Margin="24" Width="350">
                <TextBlock Text="{Binding}" FontSize="36"/>
            </Grid>
        </DataTemplate>
    </GridView.ItemTemplate>
</GridView>

Como podemos ver no existe nada especial en esta declaración del GridView, salvo dos propiedades: IncrementalLoadingThreshold e IncrementalLoadingTrigger. Por defecto IncrementalLoadingTrigger tiene el valor Edge, la he indicado explícitamente para mostrarla, pero no es necesario hacerlo. IncrementalLoadingThreshold es muy importante sin embargo. Indica el número de páginas pendientes de ver antes de pedir nuevas. Cuidado, el número de páginas. Si introducimos un valor de 1, la petición de nuevos datos no se realizará hasta que el usuario no llegue casi al final de la lista. si introducimos 10, dejaremos mucho espacio entre el final y el usuario. Debemos calibrar esta propiedad bien, para equilibrar la respuesta al usuario con el uso de recursos.

Y ya tenemos terminado nuestro código. Si ejecutamos, veremos que funciona perfectamente. Ahora, una pregunta para nota. ¿Donde se realiza la carga inicial de datos? En ningún momento hemos llamado para obtener datos inicialmente. Esta es una de las ventajas del sistema de paginación. No tenemos que realizar la carga inicial. Cuando el control se enlaza, ve que tiene 0 elementos y como está dentro del Threshold indicado, pide datos a la lista inmediatamente. Con lo que nos hemos ahorrado tener que inicializarla nosotros mismos.

Con esto llegamos al final de este artículo. Espero que os haya gustado y sea útil. Como siempre, aquí tenéis el código de ejemplo en funcionamiento para que podáis jugar con él y tenerlo de referencia.

Un saludo y Happy Coding!!

Más artículos Página siguiente >