Autor: jyeray

Hola a todos!

Hace unas semanas publiqué la primera entrada sobre Win2D, usando la versión 0.0.5 de Win2D. Hoy está disponible ya una nueva versión, la 0.0.7 con muchas mejoras, bugs arreglados y nuevas características. Si quieres ver una lista detallada de los cambios, la tienes en el blog del equipo. Si no has visitado mi primer artículo, ve a por él para saber como descargar y compilar Win2D.

En este artículo quiero centrarme en los efectos, que no pudimos ver en la entrada anterior. Para darle algo de continuidad, voy a usar el mismo ejemplo de la nave espacial de la primera parte y mejorarla con algunos efectos.

Win2D incluye muchos efectos que podemos aplicar a cualquier cosa dibujada por Win2D. Esto, aunque pueda parecer trivial, es muy importante: Normalmente las librerías de efectos nos permiten aplicar estos a una imagen. Con Win2D podremos aplicarlos a geometría, texto, imágenes e incluso a otros efectos, pudiendo producir resultados increibles encadenando varios efectos. Además, el número de efectos disponible está bastante bién:

• ArithmeticComposite
• Atlas
• Blend
• Border
• Brightness
• ColorMatrix
• ColorSource
• Composite
• Crop
• DirectionalBlur
• DisplacementMap
• DistantDiffuse
• DistantSpecular
• DpiCompensation
• GammaTransfer
• GaussianBlur
• HueRotation
• LinearTransfer
• LuminanceToAlpha
• Morphology
• OpacityMetadata
• PointDiffuse
• PointSpecular
• Premultiply
• Saturation
• Scale
• Shadow
• SpotDiffuse
• SpotSpecular
• Tile
• Transform2D
• Transform3D
• Turbulence
• UnPremultiply

Como podemos ver, una buena cantidad de efectos. Además la posibilidad de aplicarlos de forma encadenada hace que el número de combinaciones y resultados distintos sea enorme. Pero lo mejor, sin duda, es lo sencillo que resulta usarlos.

Aprovechándonos de todos estos efectos, la apariencia final que le daremos a nuestro ejemplo será algo parecido a esto:

Hemos añadido una barra inferior con llamas de colores extraños, para simular una explosión que nos persigue y al mismo tiempo hemos aplicado varios efectos a los planetas de forma que ahora aparecen difuminados y con ciertas partes más iluminadas que otras.

Empecemos por el principio. ¿Como podemos aplicar un efecto, por ejemplo de difuminado, a un círculo o un rectángulo? En primer lugar necesitamos crear una supercifie de dibujo compatible con los efectos, por lo que crearemos una instancia de CanvasRenderTarget en la que dibujaremos la forma que necesitemos:

De la misma forma que vimos ya en el primer artículo, creamos un degradado y pintamos nuestro círculo con él. Pero este código no se está dibujando en pantalla, estamos creando una imagen en la superficie de dibujo de tipo CanvasRenderTarget, que debemos dibujar en la sesión del CanvasControl:

Ahora si se dibujará nuestro círculo:

Pero no tiene nada especial ¿Donde están esos efectos? Vamos a empezar con ellos, creando una nueva instancia de la clase DirectionalBlurEffect que podemos encontrar en el namespace Microsoft.Graphics.Canvas.Effects:

Las tres prímeras propiedades definen parámetros del efecto: Ángulo de difuminación, cantidad y como tratar los bordes de la imagen generada. El cuarto es el interesante. Todo efecto en Win2D, bueno casi todos, tiene la propiedad Source, donde podemos indicar un ICanvasImage como fuente de datos sobre la que aplicar el efecto. En este caso, es el CanvasRenderTarget donde creamos nuestro círculo anteriormente. Ahora solo tenemos que dibujar el efecto, en vez del CanvasRenderTarget y voila!:

El resultado es nuestro mismo círculo, pero con un difuminado direccional aplicado:

Ahora ya hemos visto como aplicar un efecto a nuestros objetos. Con cualquier tipo, ya sea texto, círculos, rectángulos, imágenes… con todo tenemos que hacer la misma operación para aplicar un efecto. Pero lo realmente interesante es que podemos aplicar más de uno. Por ejemplo, podemos añadir un efecto de  transformación de color, usando una matriz de 4×4, a nuestro círculo difuminado. Simplemente tenemos que indicar en la propiedad Source el nuevo efecto:

Así podemos encadenar tantos efectos como queramos. Los resultados dependerán de nuestra habilidad:

Si no necesitamos animar el efecto, lo mejor es que lo creemos de antemano, al preparar los objetos. Calcular y aplicar efectos es costoso aunque esté acelerado por hardware. Debemos recordar que estamos tratando además con Tablets y Smartphones, con una capacidad gráfica mucho más reducida que un PC de escritorio o una consola. En nuestro ejemplo, he añadido a la clase Planet una propiedad de tipo ICanvasImage llamada ImageToDraw y una propiedad bool llamada IsPlanet. Si IsPlanet es true, almaceno en ImageToDraw la superficie de dibujo con los efectos aplicados, lista para ser dibujada:

Un caso aparte es el del fuego inferior, que está animado. En este caso, la animación se consigue mediante una matríz de 3×2 para la traslación y otra para el escalado. Lo que vamos a hacer es precrear todo el efecto antes de dibujar, sin indicar las matrices:

En este código podemos ver varios efectos en uso: Morphology, GaussianBlur, ColorMatrix, Transform2D y DisplacementMap. Todavía usaremos otro más, llamado Composite, que nos permitirá combinar dos efectos sin usar su propiedad Source.

En el momento de dibujar, crearemos el objeto al que aplicar los efectos, estableceremos las matrices de traslación y escalado y crearemos el efecto Composite:

Y listo, obtendremos un efecto de fuego animado. Con la variable seed controlamos el movimiento. Al hacerla negativa, verticalmente parecerá que el fuego se mueve hacia arriba, mientras que al volverla positiva, parecerá moverse horizontalmente de izquierda a derecha.

Esto es todo por ahora! Lo más interesante de Win2D es que este pequeño ejemplo que hemos hecho, que dista mucho de ser un juego completo por supuesto, comparte todo el código entre Windows y Windows Phone. Además nos aporta una nueva serie de características gráficas para hacer nuestras aplicaciones XAML mucho más ricas visualmente.

Como siempre, aquí puedes descargarte el proyecto de ejemplo actualizado. Espero que te sea de utilidad.

Un saludo y Happy Coding!

Hola a todos!

Existe un tema tan ignorado en el desarrollo de aplicaciones para Windows Phone, por parte de los propios desarrolladores, que incluso parece que se trate de algún tipo de tabú social auto impuesto. Hablo de la barra del sistema. esa pequeña franja de apenas 20 píxeles de alto, donde Windows Phone muestra la hora, la cobertura y otras notificaciones.

Generalizando, que nunca es bueno, encontramos dos formas típicas de gestionar la barra de sistema. Existen desarrolladores que simplemente no la gestionan. Ese espacio no es suyo, no les importa y no se molestan ni siquiera en mirarlo. Luego están los “acaparadores”, los que quieren cada píxel de la pantalla para ellos mismos. Estos le prestan atención a la barra del sistema el tiempo suficiente para comprobar que su código ha hecho efectivamente su trabajo: ocultarla para siempre.

Personalmente creo que ni unos ni otros tienen razón. Al menos no siempre. Como usuario, tener la barra de sistema con sus notificaciones y la hora, me conserva en la aplicación activa. Si tengo que salir de la aplicación solo por querer ver la hora o si tengo conexión WiFi, quizás no vuelva a entrar. Por otro lado, ver la barra de sistema con fondo negro y letras blancas, o viceversa, pegada a una app muy bien diseñada… es algo chocante… que hace deslucir toda la aplicación.

Y digo que es una pena, por lo extremadamente sencillo que es gestionarla. En Windows Phone 8.1 existe una clase llamada StatusBar. En ella encontraremos un método estático, GetForCurrentView, que nos devolverá la instancia de StatusBar para la ventana actual, nuestra aplicación.

Una vez hecho esto, tenemos propiedades como BackgroundColor y ForegroundColor que nos permiten definir el color de fondo y de letra de nuestra barra de sistema, pudiendo adaptarla a los colores usados en la aplicación:

De esta forma integramos la propia barra en el diseño de la aplicación y hacemos que de la impresión de que forma parte de la misma:

Con solo tres líneas de código integramos la barra perfectamente. Pero además StatusBar incluye una propiedad ProgressIndicator, que nos permite mostrar una barra de progreso indeterminada en la cabecera, así como un mensaje.

También tenemos a nuestra disposición métodos para mostrar y ocultar la barra de estado: ShowAsync y HideAsync.

Y nada más por hoy… No seais desarrolladores perezosos y prestad atención a estos detalles jejeje.

Un saludo y Happy Coding!

En Septiembre, Microsoft liberó la primera versión de una librería gráfica para WinRT, llamada Win2D. Se trata de un wrapper sobre Direct2D, compatible con aplicaciones universales. Lo mejor de esto es que nos ofrece una forma muy sencilla de acceder a la potencia de DirectX para dibujar gráficos en dos dimensiones, sin tener que irnos a desarrollar código C++.

El desarrollo de Win2D está en progreso y el equipo va liberando versiones según terminan sprints, por lo que tenemos que tener en cuenta que puede haber fallos, bugs y que no está totalmente implementado Direct2D en este momento. No obstante empieza a ser una herramienta muy interesante y con la que podemos hacer cosas relativamente “resultonas” de forma muy sencilla.

Es importante destacar los tres principios de diseño sobre los que el equipo de Win2D trabaja:

1. Todo lo que se pueda hacer con Win2D, debe poder hacerse con Direct2D. No se incluirán APis extras en Win2D. De esta forma simplemente se expone Direct2D a más desarrolladores.
2. Crear una superficie de API que imite a Direct2D de forma que portar código sea más sencillo.
3. Compartir el código y los progresos con la comunidad de desarrolladores.

Una vez que hemos visto un poco sobre qué es Win2D… ¿Para qué sirve? Podríamos pensar que una libraría 2D en pleno 2014 es algo con una utilidad limitada, pero nada más lejos de la realidad. Precisamente su punto fuerte es que solo es 2D, sencillo y antiguo 2D. Nos quitamos del medio la complejidad del 3D, el consumo de recursos del 3D y nos beneficiamos de una forma de dibujar gráficos bidiménsionales con aceleración por hardware. Podrías usar Win2D para un juego, pero también para hacer un increible fondo de pantalla animado y con aceleración para tu próxima aplicación. Incluso Win2D incluye algunos filtros, muy fáciles de implementar, para imágenes.

Vamos a comenzar por el principio.. Donde está el paquete de NuGet?

Where is my NuGet?

Podemos buscar el paquete de NuGet de Win2D hasta la saciedad y lo cierto es que no lo encontraremos. Actualmente el equipo de Win2D publica todo su código en un repositorio de GitHub, con lo que para usar esta librería tendremos que compilarnos nosotros mismos el paquete. Aunque tranquilos, porque es realmente sencillo de hacer.

Desde Visual Studio, en el panel “Team Explorer”,  vamos a la opción “Connect to team projects” (El icono en forma de enchufe en la parte superior). En la parte inferior encontraremos “Local Git Repositories” y entre otras opciones, una llamada “Clone”. Al presionarla nos pedirá la ruta del repositorio que queremos clonar. En la página del repositorio de GitHub de Win2D podemos encontrar la url para clonarlo, que es la siguiente:

https://github.com/Microsoft/Win2D.git

Simplemente introducimos esta URL en la primera caja de texto y seleccionamos el directorio local donde queramos guardar el repositorio local y presionamos el botón “Clone”:

Una vez terminado de clonar, tenemos que abrir una consola de símbolo de sistema de desarrollador (Developer command prompt), navegar al directorio donde hemos descargado el repositorio y ejecutar el archivo build.cmd.

Tendremos que tener un poco de paciencia, porque el proceso tarda un poco en completarse. Al terminar es posible que nos indique que falta NuGet.exe y una línea de comandos a ejecutar para descargarlo. Lo descargamos, vamos al directorio buildnuget y ejecutamos el archivo build-nupkg.cmd y voila! en el directorio bin ya tendremos nuestros dos paquetes NuGet de Win2D.

Solo tenemos que irnos ya a las opciones de Visual Studio en el menú “Tools” y en opciones de NuGet agregar la ruta de los paquetes NuGet de Win2D como una nueva fuente de paquetes, de forma que podamos referenciarlos en nuestro proyecto.

Tenemos dos paquetes a nuestra disposición: Win2D y Win2D debug. El segundo permite que depuremos la propia librería Win2D. En este artículo uso la librería normal.

Superficie de dibujo

Una ves que hemos añadido el paquete NuGet a un proyecto universal, podemos empezar a usarlo. La gran baza de Win2D es la sencillez para integrarlo con XAML. Simplemente debemos añadir un nuevo namespace en la página donde queramos usar Win2D apuntando a Microsoft.Graphics.Canvas y añadir a la página el control CanvasControl contenido en ese namespace:

Ya tenemos una superficie sobre la que dibujar. Para poder mostrar gráficos, debemos usar una sesión de dibujo, representada por el objeto CanvasDrawingSession. Este objeto se obtiene de la propiedad DrawingSession de CanvasDrawEventArgs, en el evento Draw del CanvasControl, por lo que tendremos que manejarlo para poder dibujar.

Podríamos crear un código como el siguiente para el evento Draw:

Como CanvasDrawingSession implementa IDisposable y además su ciclo de vida es el mismo que el de la ejecución del evento, una vez terminado el evento se pierde la sesión, usamos un bloque using para obtener la instancia de CanvasDrawEventArgs.

Una vez hecho esto, CanvasDrawingSession expone una serie de métodos que nos permiten dibujar diferentes formas como círculos, elipses, texto, rectángulos, líneas o imágenes. También nos permite borrar el contenido de la pantalla para empezar a dibujar de nuevo.

En el código anterior, primero borramos el contenido del canvas estableciendo el fondo azul, a continuación creamos una instancia de la clase Vector2 para definir el centro de un circulo, una variable float para definir el radio y usamos el método FillCircle para dibujarlo, indicando en el último parámetro el color del que queremos rellenarlo. El resultado es el siguiente:

Nada espectacular hasta ahora. Además el contenido es estático, el evento Draw solo se invoca una vez al comienzo de la aplicación o si redimensionamos la ventana que contiene la aplicación WinRT. En realidad lo que ocurre es que el método Draw se ejecuta cuando se invalida la superficie del control CanvasControl. Podríamos crear un DispatcherTimer que simplemente la invalidase cada X milisegundos. Si hacemos los cálculos, veremos que para conseguir una tasa de refresco de 60 cuadros por segundo, debemos ejecutar el DispatcherTimer cada 33 milisegundos, más o menos. Por lo que, simplemente en el evento Tick del DispatcherTimer, vamos a invalidar el redibujado. Primero inicializamos el timer en el método OnNavigatedTo de nuestra página:

En el evento Tick, debemos parar el timer, para evitar que cualquier operación que se alargue más de 30 milisegundos haga que se ejecute varias veces sin llegar a dibujar. A continuación llamamos al método Invalidate de nuestro CanvasControl y se volverá a lanzar el evento Draw:

Pero… ¿No vuelves a arrancar el DispatcherTimer al terminar el evento Tick? En realidad… lo deberíamos arrancar de nuevo cuando haya terminado de dibujar, y ya no tengamos nada más que hacer. Esto es tan solo una forma de hacerlo y cada uno debe experimentar con la cadencia de tiempo, con la forma de parar y arrancar el timer… para adaptarlo a lo que necesitemos en cada desarrollo.

Bien, ya podemos invalidar y redibujar cada XX milisegundos pero… ¿De qué nos vale? En el método Draw solo dibujamos un círculo una y otra vez. Pero no se trata de un objeto al que podamos acceder desde fuera… es una simple llamada al método FillCircle. Vamos a complicar un poco más el ejemplo. Como me gusta mucho la ciencia ficción, sobre todo la que trata sobre el espacio… vamos a hacer una vista del espacio con planetas. En primer lugar, ¿Como podemos definir un planeta? Quizás podríamos necesitar saber su posición con respecto a nuestro punto de vista, el radio central para definir su tamaño, el radio de sus anillos (si tiene claro…) El color de su cuerpo y el color de sus anillos. Incluso su aceleración, pues normalmente se trata de cuerpos celestes en movimiento. Así que podríamos desgranarlo en una clase más o menos como esta:

Podría funcionar… Como podemos ver, el color del cuerpo del planeta se define con una propiedad del tipo CanvasRadialGradientBrush. Este nuevo tipo de brocha, nos permite crear un degradado radial, en ves de uno lineal. Los que hayáis trabajado en WPF, abrazaros y llorad de alegría. Estoy con vosotros.

Para crear un degradado CanvasRadialGradientBrush, al crear la instancia necesitaremos pasarle cierta información:

• El CanvasControl donde vamos a pintarlo.
• El color inicial (central)
• El color final (borde exterior)

Además, una vez hecho esto, necesitaremos indicarle tres propiedades más: Center, RadiusX y RadiusY:

Es muy importante que el centro sea el mismo que el del objeto donde lo queremos usar. Las coordenadas que indicamos aquí, no son relativas al objeto donde lo apliquemos, son relativas a la pantalla. Es muy importante esto, o podemos darnos cabezazos contra la mesa pensando en porqué no se pinta el degradado correctamente.

Bien, ahora que sabemos como crear el degradado, vamos a crear un método llamado CreatePlanet, al que le pasemos ciertos valores y cree una instancia de un objeto de tipo Planet y lo guarde en una lista:

Este código simplemente rellena las propiedades que hemos indicado anteriormente del planeta. Como podemos ver, a la propiedad BodyColor (CanvasRadialGradientBrush) le pasamos los mismos valores que a la clase Planet para el centro y el radio X e Y.

Pero Yeray, esto es una clase normal y corriente, no es un objeto especial de DirectX super chulo y emocionante… Tranquilos a todo llegaremos. Para lo que nos va servir esta clase es para definir que hay que pintar, de una forma sencilla. Por ejemplo, podemos crear 125 instancias de la clase Planet, muy pequeñas y con un degradado radial de blanco a transparente, con este código:

El radio será de entre 5 y 10 píxeles, y la aceleración un valor aleatorio entre 0 y 1. En nuestro evento Draw, podemos escribir ahora código que recorra la lista de planetas y usar el método FillCircle para dibujar cada uno:

Usamos el método FillCiircle para crear el círculo y rellenarlo con el color de cuerpo (El degradado radial que creamos anteriormente) e indicamos la posición y el radio. A continuación usamos el método DrawCircle, para dibujar exactamente igual un círculo, pero en esta ocasión sin relleno, solo dibujando el borde con el color de anillo y la misma posición. Si ejecutamos este código en el simulador de Windows Store, obtendremos algo parecido a esto:

Simplemente con un bucle ya hemos dibujado algo parecido a un campo de estrellas… con algo de imaginación al menos. Ahora, vamos a aprovecharnos del DispacherTimer para agregar algo de lógica relacionada con la propiedad Acceleration que hemos incluido en la clase Planet. A ver que os parece:

Con el código anterior, antes de invalidar el CanvasControl, recorremos la lista de planetas y creamos una nueva instancia de Vector2, dejamos la posición X en el mismo punto en el que se encuentra. Con la posición Y, comprobamos si es menor que el area vertical de la pantalla. Si lo es, a la posición Y actual le añadimos la aceleración de la instancia de planeta. Si es mayor, reseteamos la posición a un valor negativo, fuera de la pantalla para que continue avanzando.

Con esto, conseguimos un movimiento vertical descendente de los círculos. Pero además como no todos los planetas tienen la misma aceleración, obtenemos el efecto de profundidad.

Ahora, con el código que hemos creado, podemos seguir creando más planetas, más grandes, con diferentes colores y con más aceleración de forma que obtengamos una mayor sensación de profundidad:

Simplemente añadiendo estos nuevos planetas, nuestro código los dibujará, de una forma parecida a la siguiente:

Esto ya parece otra cosa… además, como hemos añadido diferentes aceleraciones en cada capa, desde más lenta a más rápida, obtenemos un mejor efecto de profundidad. Lo se, no es que sea precisamente lo último en tecnología gráfica, pero ilustra lo que os quiero contar jeje.

Ahora que tenemos un campo de estrellas en su lugar, nos falta ¡una nave espacial! y cual que mejor que un X-Wing.

Afortunadamente Win2D incluye métodos y objetos para trabajar con imágenes de forma muy sencilla. Uno de esos objetos es el CanvasBitmap, que nos permite cargar una imagen almacenada en un archivo en el proyecto:

Usando el método estático LoadAsync y pasándo como parámetro nuestro CanvasControl y la ruta relativa de la imagen en el proyecto, tenemos creado un objeto CanvasBitmap.

Una vez creado el objeto CanvasBitmap, en nuestro método Draw lo podemos mostrar usando el método DrawImage con tres parámetros:

• el CanvasBitmap a dibujar
• una instancia de Rect (Windows.Foundation.Rect) para definir la posición (X, Y) y el tamaño de destino.
• una instancia de Rect  para definir la posición (X, Y) y el tamaño dentro de la imagen original, que queremos pintar.

El que el segundo Rect nos permita definir un fragmento de la imagen, es especialmente útil para trabajar con sprites.  Pero no todo va a ser tan facil. Al igual que con la clase Planet, vamos a definir una clase Spaceship que identifque a nuestra nave espacial. Esta vez es un poco más sencilla: una posición, un desplazamiento negativo y una imagen a dibujar:

La posición y la imagen, están claras. Pero, ¿Desplazamiento negativo? Bueno, ha sido una idea por darle un poco más de lógica a la demo. ¿Y si al mover la nave en cualquier dirección, aplicamos la misma cantidad de movimiento a las estrellas y planetas, pero en la dirección contraria? Le damos un poco más de interactividad a la lógica.

Primero lo primero, en el mismo método que creaba los planetas, vamos a crear la instancia de la clase Spaceship que vamos a usar:

Simplemente le asignamos el CanvasBitmap y posicionamos la imagen en el centro de la pantalla. Para ello, calculamos el centro y le restamos la mitad del tamaño con el que queremos dibujar la nave.

En nuestro evento Draw, tras dibujar los planetas, vamos a añadir código para dibujar la nave:

Como dijimos anteriormente, el primer Rect indica el destino y el segundo indica el pedazo de la imagen que queremos mostrar. En este caso toda la imagen, que como veréis no me he molestado en disminuir desde una resolución mastodóntica… pensando en hacer algunos juegos de ampliar y reducir la imagen, para dar efecto de elevación… Pero eso para otro tutorial.

Ya solo nos queda una cosa: Poder interactuar con la nave moviéndola al pulsar sobre ella. Para ello, vamos a definir la propiedad ManipulationMode del CanvasControl y manejar los eventos: ManipulationStarted, ManipulationDelta y ManipulationCompleted:

Como solo queremos manipular la “nave” cuando el usuario pulse sobre ella y la arrastre, en el evento ManipulationStarted, comprobamos si el punto sobre el que empieza la manipulación está contenido en el area de la imagen, definida por la posición + el tamaño. Si está contenida, señalaremos una variable boolean indicando que efectivamente estamos manipulando la nave:

Simplemente comprobamos si la posición X, Y de ManipulationStartedRoutedEventArgs, está dentro del area de la nave. Una vez hecho esto, es en el evento ManipulationDelta donde recibiremos la información mientras el usuario arrastra la imagen, y donde modificaremos su posición:

 

 

Primero comprobamos si estamos manipulando la nave. A continuación, usamos la propiedad Delta de ManipulationDeltaRoutedEventArgs para obtener la cantidad de traslación realizada desde la última vez que se lanzó el evento. Normalmente el valor es bastante pequeño y relativo al punto donde hayamos tocado. Si desplazamos el puntero/dedo hacia abajo o hacia la derecha, tendremos un valor positivo. Si lo desplazamos hacia arriba o izquierda, un valor negativo. A continuación, cogemos ese mismo valor y obtenemos su inverso (si es 3.2, obtenemos –3.2) y lo guardamos en el Vector2 NegativeDisplacement. Un poco más adelante lo vamos a usar en nuestra lógica.

Por último, el evento ManipulationCompleted nos informa de que el usuario ha dejado de actuar sobre el objeto. En ese momento, podemos establecer la variable boolean a false de nuevo, ya no existe manipulación y reseteamos el NegativeDisplacement a 0, pues ya no hay movimiento:

Como podemos ver, en ninguno de estos eventos invalidamos el CanvasControl. No lo necesitamos, nuestro DispatcherTimer sigue activo y lo que vamos a hacer es añadir la lógica que tenga en cuenta el NegativeDisplacement a la hora de calcular el movimiento de los objetos:

 

 

En primer lugar, tanto en el valor X como Y, comprobamos si estamos dentro de la pantalla. Si estamos dentro, en el eje X le sumamos a la posición actual el valor de X de NegativeDisplacement de la nave. En el eje Y a la posición ya le sumamos el valor de aceleración del propio planeta, para crear la sensación de movimiento. Ahora además le añadimos el valor de Y de NegativeDisplacement. Si estamos fuera de la pantalla o a punto de salir de ella, en el eje X volvemos a calcular un valor aleatorio de X para repintar el planeta en otra parte de la pantalla. En el eje Y simplemente lo pintamos al principio de la pantalla, unos píxeles fuera, para que al animarlo vaya entrando en la misma.

Como podemos ver, no hacemos nada con la nave. En el evento ManipulationDelta ya hemos actualizado el Vector2 Position, con lo que el propio evento Draw la dibujará en la posición adecuada.

Y con esto, si ejecutamos tanto en Windows Store como Phone, podremos mover la nave en todas direcciones y veremos como las estrellas se desplazan en la dirección inversa.

Lo único que nos queda por ver es… como se integra con el resto del XAML. La verdad es que no es ningún misterio, tan solo tenemos que poner el XAML que queramos mostrar, a continuación del CanvasControl y funcionará automáticamente. Por ejemplo, por completar la imitación de un juego de naves, yo he añadido un TextBlock y una ProgressBar que muestran la “energía” restante de la nave:

Simplemente colocamos el XAML como con cualquier otra página. El resultado final de todo el trabajo que hemos hecho, una app universal, compartiendo todo el código, tanto para Windows como para Windows Phone:

Y llegamos al final! Creo que hemos dado un buen repaso por encima de las capacidades básicas de Win2D, como conseguirlo y como poder empezar a usarlo. Quedan más cosas que puede hacer, como aplicar filtros a imágenes, pero eso se va a quedar para el siguiente artículo.

Como siempre, aquí podéis descargaros el ejemplo usado en este artículo. Espero que lo disfrutéis tanto como yo lo he hecho escribiéndolo.

Un saludo y Happy Coding!

 

Hola a todos!

Hace ya casi un año que escribí sobre AppStudio por última vez. Mucho ha llovido desde entonces y AppStudio a cambiado mucho así que, ahora que está de moda en el cine, quiero hacer un “reboot” del artículo original.

En este año que ha pasado, AppStudio ha crecido y cambiado mucho:

Hace un año…	Hace unos minutos…

La filosofía sigue siendo la misma, pero el diseño ha evolucionado, al igual que la usabilidad. Ahora puedes generar apps Windows también, incluso cuenta con un “simulador” Windows adicional al de Windows Phone, en el que ver la preview de tus apps. Porque además, AppStudio soporta ahora apps universales:

Todo esto y muchas más novedades son lo que me han decidido a reescribir ese artículo original, para repasarlas todas y ver lo que nos puede ofrecer una herramienta que cada vez es más potente.

Vamos a empezar por el principio…

Ahora podemos entrar a AppStudio desde AppStudio.Windows.com. Una vez dentro, tenemos un menú en la parte superior de la pantalla con varias opciones. Las más interesantes ahora: “My projects”, “Start new” y “Sample apps”. Start new nos lleva directamente a crear una nueva app, al igual que el botón “Start new project” que tenemos en la parte superior derecha de la pantalla.

My projects

Esta opción nos lleva a nuestra área personal, donde podremos ver los proyectos que hemos inciado, los hayamos terminado o no, y nos ofrece opciones para manejar cada proyecto:

Directamente desde esta pantalla podremos editar un proyecto ya existente con el botón “Edit” de cada uno, generar el código fuente y el paquete de publicación compilado con el botón “Generate” o eliminarlo si no deseamos conservarlo, usando el botón “Delete”.

Sample apps

En el menú “Sample apps” encontraremos dos aplicaciones universales creadas por el equipo de AppStudio:

Por cada app, podremos descargarnos su código fuente generado con AppStudio, de forma que tengamos una referencia del tipo de código que genera, como se estructura y como funciona. También vamos a poder ver las aplicaciones en funcionamiento, tanto para Windows Store como para Windows Phone, puesto que ambas aplicaciones de ejemplo están publicadas en las tiendas de la plataforma. Es una forma muy sencilla de ver de que es capaz AppStudio y como lo hace internamente. Si no te las has descargado, hazlo! además he de reconocer que la de Windows App Studio es bastante resultona gráficamente. Kudos para el equipo!

Start new o Start new project

Y llegamos a la parte interesante! con la opción de menú “Start new” o el botón “Start new project” se carga la pantalla de plantillas. Aquí encontraremos tres secciones:

• Primero las plantillas más usadas: Estas son las plantillas destacadas, que más suelen usarse. Nos permiten crear nuestro proyecto tanto para Windows Phone como para Windows Store.
• Plantillas web apps: Nos permite crear una aplicación a partir de un sitio web existente. Por ahora solo funciona para Windows Phone.
• Más plantillas: Son iguales que las primeras que vimos, simplemente más tipos y diseños para que no partas de 0 en tu proyecto.

Es importante darnos cuenta que la primera de todas las plantillas, “Empty App” nos permite crear una aplicación totalmente vacía con la que comenzar. Es la que vamos a usar en este artículo, así que vamos a por ella. Pinchamos en “Empty App” y nos mostrará un popup con el preview de la plantilla.

En este caso está totalmente vacía, ya que se trata de una aplicación totalmente en blanco:

Presionando el botón “Create” pasamos a la página central de la creación de una aplicación en App Studio:

Aquí podemos definir toda nuestra aplicación a golpe de ratón. Lo mejor es que, además, todo lo que vayamos cambiando se irá actualizando en el simulador que tenemos a la izquierda, con lo que podremos ver una preview en tiempo real de como va a quedar nuestra app. Tenemos que tener en cuenta que no es un emulador de Windows Phone, es una simulación, no creo que sea 100% exacta, pero a un 90% seguro que coincide. Pero hay que tenerlo en cuenta.

Lo primero que necesitamos es cambiar el nombre de nuestra aplicación. En este caso yo quiero hacer una app que muestre los vídeos de youtube que tenemos en WPSUG, por lo que la app se llamará WPSUG. Original eh? Podemos cambiar el título escribiendo en la caja de texto que está justo sobre el emulador, donde pone “App Title”.

Ahora vamos a ponerle algo de contenido. Al lado derecho del simulador tenemos 6 cajas punteadas. en cada una de ella podemos añadir una sección. Justo debajo tenemos los tipos de secciones:

• Rss: El contenido de un RSS que tengamos disponible.
• Html: Contenido html estático que podemos incluir en la aplicación.
• Youtube: Una busqueda, un usuario o una lista de reproducción.
• Flickr: Una busqueda de flickr.
• Bing: Una busqueda de Bing.
• Facebook: Una página de facebook.

Debajo de estas, disponemos de dos secciones más, en la categoría avanzada:

• Menú: Si no tenemos suficiente con las secciones iniciales, limitadas a 6, podemos usar un menú para crear más subsecciones.
• Colección: Nos permite crear una colección de datos, ya sean estáticos (dentro de la app) o dinámicos (en la nube). En ambos casos puedes definir las columnas que tendrá la colección y el tipo de cada una de ellas.

En nuestro caso, vamos a empezar con una sección HTML, que será la primera que verá el usuario al entrar. En esta sección vamos a explicar un poco que es WPSUG y la finalidad de la aplicación. Al presionar sobre la opción de Html, se abre un popup donde podemos indicar el título de la sección y el contenido HTML:

Una vez que estemos contentos con el texto solo tenemos que presionar “Confirm” para terminar de añadir la sección.

A continuación vamos a crear una sección de YouTube, donde mostraremos los videos del usuario “WPSUG”. Este tipo de sección solo nos pide que indiquemos el título, el tipo de busqueda y el término. En nuestro caso, el título será  “Webcasts”, el tipo de busqueda será por usuario y el término será “WPSUG”, como se puede ver en la siguiente pantalla:

Presionamos el botón “Confirm”, se añade la nueva sección y ya podremos interactuar con el simulador y ver los datos reflejados. Incluso si pinchamos en el botón verde bajo el teléfono que pone “Windows preview” podremos ver una previsualización, e interactuar con ella, de nuestra app en Tablet.

Y ya está, estos eran los datos que queríamos mostrar. Ahora lo que necesitamos es personalizar la aplicación. En primer lugar, podemos presionar en el link “Edit” de cada una de las secciones que hemos creado. Acuerdate de guardar primero con el botón “Save” que tienes en la parte superior derecha, para no perder nada. Al presionar “Edit” veremos la configuración de la página de detalle de cada elemento, en el caso de la sección de tipo YouTube. podremos elegir como se muestra la lista: con o sin imágen, solo título, imágen grande, solo imágenes, bloques con imagen de fondo y texto superpuesto… hay un montón de combinaciones posibles:

Cuando tengamos el diseño que queremos, solo tendremos que guardar con el botón “Save” y volver atrás con el botón atrás que hay al lado del nombre de la sección.

Ahora, otra cosa que podemos hacer es cambiar el logotipo por defecto de Windows que se muestra al lado del título. En la parte superior izquierda de la pantalla, al lado de la caja de texto donde escribimos el título de la aplicación, podemos ver el logo por defecto. pinchando sobre él, nos permite seleccionar otro de nuestro equipo, del OneDrive asociado a la cuenta con la que hagamos entrado en AppStudio o de recursos de AppStudio. En mi caso voy a escoger el logo de WPSUG que tengo en mi equipo. La imagen debe cumplir algunos requisitos:

• Debe tener un alto y ancho mayor de 300 píxeles.
• Debe ser cuadrada (mismo alto y ancho).

Una vez que escojamos una imágen que cumpla esas dos reglas, se subirá y colocará automáticamente en su posición. Ahora necesito cambiar el Fondo de la app, quiero que sea blanco y el color de la letra, para que la app no sea blanca y negra. Para ello, previo guardado de los cambios, Vamos a pasar de la pestaña “Content” en la que hemos estado a “Themes”:

Tenemos varias opciones aquí. En primer lugar podemos escoger el esquema de colores entre tres opciones:

• Tema oscuro (Dark Style). Es el tema oscuro del dispositivo por defecto.
• Tema claro (Light Style). Es el tema claro del dispositivo por defecto.
• Personalizar el tema (Custom Style). Un tema nuevo creado por nosotros.

En el tema personalizado, podemos cambia el color de la barra de aplicación, el color de fondo y el color de letra. Incluso podemos añadir una imagen de fondo a la aplicación si lo deseamos. Una vez que la aplicación quede a nuestro gusto, podemos guardar los cambios y continuar a los Tiles, donde podremos definir los tiles que usaremos en nuestra aplicación. En nuestro caso, vamos a usar el tema oscuro por defecto.

Podemos escoger entre tres tipos de tile diferente:

• Flip template: Un tile que tiene contenido en la parte de atrás y gira para mostrarlo.
• Cycle template: Un tile al que podemos asociar una colección de imágenes (si tenemos) que se irán mostrando.
• Iconic template: Un tile con texto y una imagen a mostrar.

En el caso de nuestro ejemplo, vamos a usar el flip template. Nos permite mostrar el logo de WPSUG en varios tamaños y especificar una imagen extra como contenido trasero del tile.

En esta misma pestaña podemos definir también el uso de una splash screen y lock screen. pulsando sobre el botón “Splash & Lock” en la parte de arriba. Tendremos la posibilidad de especificar la imagen que queremos usar en la SplashScreen de Windows Phone y Windows Store y la imagen de lock screen de Windows Phone.

Y una vez definido esto último, estamos listos para terminar el proceso en la pestaña de “Publish info”. En esta última pestaña podremos definir varios parámetros de la aplicación:

• App title: El título de la aplicación.
• App Description: Una descripción para incluir en la aplicación.
• Language: Esto es una novedad incluida hace muy poco tiempo. Nos permite indicar el idioma por defecto de la aplicación, de forma que a la hora de certificar no tengamos problemas. Por ejemplo, la aplicaión WPSUG tiene los textos en español. Si selecciono como Language el Inglés, fallará la revisión de la tienda.
• Include about page: Si lo habilitamos se incluye una página About automáticamente.
• Enable ad client: Nos permite habilitar la inclusión de publicidad e indicar los datos del PubCenter de Microsoft.
• Associate app with the Store: permite asociar esta aplicación con la tienda directamente para poder publicarla.
• Privacy Statement URL: url a la declaración de privacidad de la aplicación. Si no vamos a modificar la aplicación, no es necesario incluir una url propia y AppStudio usará una por defecto.

Ya solo nos queda darle al botón grande y azul que pone “Finish” para poder recoger los frutos de nuestro trabajo. Esto nos llevará a una página donde podremos ver la previsualización de nuestra aplicación tanto en tablet como en teléfono, interactuar con ella y ver si se nos ha olvidado algo:

Si todo es correcto, solo tenemos que presionar el botón “Generate” y aparecerá un popup donde podremos indicar que queremos obtener exactamente:

En estos momentos, solo podemos generar código/paquetes para Windows Phone 8.1 y Windows 8.1. Podemos escoger si queremos obtener un paquete instalable o uno de publicación y añadir algún comentario. Por úlimo al darle a Generate se cerrará el popup y en la parte de abajo de la pantalla podremos ver un indicador de la generación. Es muy rápido pero no es necesario que esperemos. El sistema nos enviará un email cuando termine, avisándonos de que nuestra aplicación está completa.

Es interesante notar que cada generación de una aplicación no pisa la generación anterior. mantenemos como un histórico, de ahí la opción de añadir un comentario. podemos tener varias versiones generadas y ver exactamente que hicimos en cada una apuntándolo en el campo de comentarios.

Y esto es todo por hoy. Espero que os sea muy útil y ayude a que exprimáis todo el jugo a AppStudio.

Un saludo y happy coding!

 

Hello all!

Today i want to steal some space of my blog to talk about something other than Windows, Windows Phone or XAML. Today i want to talk about myself hehe.

Without getting deep in details, after one year working in a company called Icinetic, yesterday i leave the job. Wait! What? With the actual crisis the world is suffering you are leaving your job? Why? Are you crazy? Well, the why, the crisis, even the job not really matter… The important thing is… i had an awesome year working with such a group of talented people. Share projects, lines of code, adventures and misadventures with a lot of good friends.

In spain there is a popular phrase “lo bueno, si breve, dos veces bueno” (the good things, if brief, twice as good) and another one “no hay mal que cien años dure, ni cuerpo que lo aguante” (there is not bad situations with 100 year durations, and no one can’t hold them) What this two phrases try to explain is: The good things and the bad things aren’t there to stay forever. And i think this was the time to leave in the search of new things… bad or good? i don’t know, and really i don’t care much about that.

So, from today i’m starting a new life as a freelance contractor. Hoping to be able to work with much more intelligent, interesting and tallented people, as i did until today, to try to learn more, do more things and… code a lot of XAML and C# by the way!

Regards and happy coding!

Hola a todos!

Hoy voy a permitirme robar un poco de espacio para hablar de algo distinto a Windows, Windows Phone, XAML…. Hoy voy a hablar un poco de mi jeje.

Sin entrar mucho en detalles, tras un año en Icinetic ayer fué mi último día. ¿Por qué? Pero si te acabas de mudar a Sevilla! Y que importa realmente… Lo importante es que he pasado un gran año, he tenido el placer de compartir proyecto, aventuras y desventuras con un montón de gente increible y muy muy buena profesional y personalmente, entre ellos Javier Suarez, un gran compañero. He tenido la oportunidad de trabajar en un proyecto muy interesante, con mucha difusión y tras terminar en ese proyecto he podido pasar los últimos 8 meses con un proyecto Windows Phone XAML muy chulo, con bluetooth LE de por medio, mucho (ojo, pero muuuuuucho) trabajo de animaciones y efectos en XAML y bastante grande para lo que suele ser una app móvil.

Pero como dice el dicho: “lo bueno, si breve, dos veces bueno” o era “no hay mal que mil años dure, ni cuerpo que lo aguante”? Bueno, ya me entendéis.

Ahora me lanzo a una nueva aventura, la de hacerme autónomo… o “Contractor” como se dice en la lengua de Shakespeare. Con mucha ilusión, con muchas ideas. Sin un duro, pero con muchas ganas de desarrollar más apps, de escribir más, y de compartir más conocimiento.

¿Qué podría ir mal? Un gran compañero me enseño que no hay nada que no se arregle con un “Malo será…”.

Un saludo a todos y Happy Coding!!

Hola a todos!

Desde ayer está disponible la CTP 4 de Visual Studio 14. Trae un monton de novedades, pero hoy quiero hablaros de una, que por su simplicidad, es una auténtica maravilla para los que pasamos muchas horas trabajando con XAML.

Hablo de Peek definition. En español se podría traducir como “ver definición”. No debemos confundirlo con el Go to definition que ya teníamos disponible en Visual Studio 2013. Aunque su función es parecida, la forma en que se ha implementado es totalmente diferente.

En Visual Studio 2013 ya teníamos Peek Definition para el código C#/VB.NET/C++, pero no para XAML. Este nos permitía ver en línea, sin cambiar de archivo ni posición, la definición del miembro sobre el que la usemos:

 

Pues por fín se han decidido a implementarlo en XAML también. Funciona con controles de usuario y recursos, de forma que, por ejemplo, podemos ver la definición de una plantilla, sin cambiar de pantalla y editarla mientras vemos los resultados en el contexto real donde se usa:

Si trabajas con muchas páginas XAML distintas, controles de usuario y estilos en varios diccionarios de recursos, podrás apreciar la ventaja de “Peek definition” sobre “Go to definition”. Como extra, decir que funciona en cualquier “sabor” de XAML: Tanto proyectos Windows Phone y Windows Store, como WPF, que ya se merecía algo de cariño.

Un saludo y Happy Coding!!

Hola a todos!

El pasado 30 de septiembre, junto a Javier Suarez Ruíz, Alejandro Campos y Luis Guerrero tuve el placer de participar en el Madrid Mobility Day, organizado en las oficinas de Microsoft Ibérica.

Para empezar a caldear el ambiente, la primera charla que hice fue una breve introducción al desarrollo de aplicaciones universales para Windows 8.1 y Windows Phone 8.1. He subido la presentación a SlideShare para que podáis acceder a ella fácilmente:

También pude compartir charla con Javier Suarez Ruiz en una charla sobre Xamarin.Forms. Javi publicará la presentación y los ejemplos en su blog.

Como siempre, ha sido un placer poder estar con toda la gente de DX de Microsoft Ibérica. Incluso aprovechamos para sacarnos una foto Javi y yo en una de las cafeterías:

Un saludo y Happy Coding!

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:

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:

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.

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:

 

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

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…

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

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:

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:

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:

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!

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.

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:

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:

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:

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:

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:

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:

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:

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:

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

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:

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.

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!!