[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 (768×1280) 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 (480×800) 4 pulgadas 512Mb
Emulator 8.1 WVGA 4 inch WVGA (480×800) 4 pulgadas 1024Mb
Emulator 8.1 WXGA 4 inch WXGA (768×1280) 4 pulgadas 1024Mb
Emulator 8.1 720p 4.7 inch 720P (720×1280) 4.7 pulgadas 1024Mb
Emulator 8.1 1080P 5.5 inch 1080P (1080×1920) 5.5 pulgadas 1024Mb
Emulator 8.1 1080P 6 inch 1080P (1080×1920) 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 300×300 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!