Bueno, ahora si que si vamos a darle caña a esto de Mobile Services y comenzamos por una de sus patas, concretamente con las opciones y capacidades de autenticación.

Para ello ahora mismo el sistema nos permite registrar 4 plataformas distintas por las cuales poder hacer autenticación en nuestras aplicaciones, que estén apoyadas en Mobile Services. Disponemos de Windows Live, Facebook, Google Account y Twitter para realizar dicha autenticación. (Si hay algún usuario que no disponga de cuenta en alguno de estos 4 gigantes, informáticamente hablando este usuario no existe ;-P )

Para configurar esta autenticación, deberemos de dirigirnos, lo primero, a la pestaña de identidad de nuestro servicio móvil, dentro del panel de control de Windows Azure.

Como vemos en la imagen, por cada uno de los 4 proveedores posibles de autenticación deberemos de indicar un par de parámetros. Obviamente solo tendremos que indicar los parámetros de aquellos servicios que queramos usar. Con todo esto la siguiente pregunta seria. ¿Donde consigo cada uno de los parámetros que me solicitan? Ahora os lo explico proveedor a proveedor, pero veréis que los pasos son básicamente los mismos en cualquiera de ellos.

Windows Live.

Para poder autenticarnos a través de una cuenta de Live Connect, deberemos de dirigirnos a la web dev.live.com En dicha pagina y una vez autenticados con una cuenta de Live, deberemos de dirigirnos a la sección de “Mis aplicaciones”. Dentro de dicha sección y después de pulsar sobre el botón de “Crear aplicación”, simplemente indicamos un nombre para dicha aplicación. En mi caso el mismo que el nombre de mi app que estoy creando. Pulsamos en “Aceptar” y ya tenemos nuestra aplicación creada en la plataforma Live.

Una vez creada la aplicación ya nos informa de los dos datos necesarios para configurar la autenticación. Por un lado el id de cliente y por otro la clave secreta de cliente.

Por ultimo, solo nos quedaría indicar el dominio de redirección, que es la web desde donde vamos a realizar la interconexión con esta aplicación de la plataforma Live. Esa dirección no es otra que la dirección de nuestro servicio móvil. En mi caso https://mylistoftasks.azure-mobile.net

Facebook.

Lo primero es disponer de una cuenta de Facebook (obvio), a continuación nos dirigiremos a la web developer.facebook.com. Si nunca hemos ido a esta web simplemente nos debemos de registrar como desarrolladores. Paso bastante sencillo, que completaremos simplemente pulsando el botón de Registro.

Una vez registrados como desarrolladores de Facebook, nos dirigiremos al apartado de “Apps”. Lo que veremos es una pantalla en donde estarán todas las aplicaciones que hayamos registrado. Para crear una nueva lo único que hay que hacer es pulsar sobre el botón de crear una nueva aplicación. En la pantalla que se nos muestra, obligatoriamente deberemos de indicar el nombre de la aplicación (ídem que en el caso de Live), el resto de datos son opcionales. El campo “Namespace” sirve para que los usuarios puedan acceder a nuestra aplicación con una url directa, del tipo apps.facebook.com/mylistoftasks pero eso solo es necesario si queremos realizar una aplicación 100% embebida en Facebook.

Tras estos pasos ya tenemos la aplicación creada y lo que nos muestra, entre mucha mas información, son los dos datos que nos importan, el App ID y el App Secret. Por ultimo deberemos de indicar, tal y como hemos realizado en Live, la url de nuestro servicio móvil dentro del apartado web de inicio de sesión y por ultimo desactivar el modo SandBox (si no desactivamos este modo, no será posible realizar la autenticación).

Google Account.

Anteriormente deberíamos de dirigirnos a la sección de Apis de Google. Desde hace un tiempo, ya podemos dirigirnos a la consola de administración de la plataforma cloud de Google en cloud.google.com Una vez en dicha web y tras habernos autenticado con una cuenta de google, nos dirigiremos a la consola pinchando el enlace de la parte superior. En la pantalla de la consola, podremos ver todas las aplicaciones que hayamos creado dentro del cloud de google. Si queremos crear una nueva, simplemente deberemos de pinchar en el botón “Crear Proyecto” y en el paso siguiente indicar el nombre de dicho proyecto nuevo a crear.

Una vez creado dicho proyecto accedemos a él y en el menú de la izquierda dentro de la sección “Apis & auth” seleccionaremos la opción de “Apps registradas”. Pulsamos el botón de registrar una nueva aplicación y le damos un nombre. Indicando que la plataforma de dicha aplicación será Web. Tras registrarla, en la sección OAuth 2.0 Client ID, encontraremos los datos que nos hacen falta. Por un lado el Client ID y por otro el Client Secret.

Solo nos faltaría indicar la web de origen, que es la url de nuestro servicio móvil y la uri de redirección, que en este caso es la url de nuestro servicio móvil seguido de la ruta login/google

Twitter.

Dentro de la sección de aplicaciones en la web de desarrollo de Twitter, concretamente en dev.twitter.com/apps y tras autenticarnos con una cuenta de dicho servicio, crearemos desde el botón al efecto una nueva aplicación. Para ello deberemos de indicar un nombre, una pequeña descripción de la misma, la web de la aplicación (una web de información sobre la aplicación, que en nuestro caso si no disponemos de ella podría ser la web de nuestra aplicación en la Windows Phone Store por ejemplo), y por ultimo en el apartado de Callback URL, la dirección de nuestro servicio móvil. Aceptamos las reglas de desarrollo, indicamos el Captcha y creamos la aplicación.

A continuación en la pantalla que se nos muestra del resumen de la aplicación creada, ya tenemos los dos datos necesarios. El Consumer Key y el Consumer Secret. Por ultimo deberemos de indicar un dato más. Para ello nos dirigiremos a la pestaña de “Settings” y justo debajo de donde se indica la URL de Callback, deberemos de señalar el check que indica que permitimos realizar signin desde nuestra aplicación, contra twitter. Grabamos y listo.

Bueno, pues una vez que tenemos los datos necesarios de cada uno de los proveedores, deberemos de indicarlos convenientemente en la sección de Identidad de nuestro servicio móvil tal y como he comentado al principio de este post. Mas o menos la pantalla de Azure Mobile quedaría del siguiente modo:

 

Autenticación desde la aplicación.

Una vez que hemos configurado el o los servicios que queremos usar, pasamos a nuestra aplicación y llevarlo a efecto. Para ello deberemos de usar el método asíncrono LoginAsync, de la clase MobileServiceClient.

Dicha clase, como seguramente que recordáis del post anterior, le hemos creado como propiedad estática dentro de nuestro fichero App.xaml.cs

Para llamar al método de autenticación, como podéis ver en su definición, deberemos de indicar el proveedor de autenticación. Este proveedor no es mas que un elemento del enumerador MobileServiceAuthenticationProvider. Luego para realizar la autenticación en Facebook deberíamos de escribir un código como el siguiente:

Al intentar realizar la autenticación, ya sea el proveedor que sea, nos aparecerá la web de registro de cada uno de ellos.

.Facebook	.Twitter
.Google	.MicrosoftAccount

Este método, como también se muestra en la definición, nos devuelve un objeto del tipo MobileServiceUser.

En el momento en el que nos autenticamos con cualquiera de los proveedores, y aceptamos que nuestra aplicación acceda al perfil de la cuenta usada, es el momento en que el método LoginAsync retorna devolviéndonos el objeto MobileServiceUser. En dicho objeto simplemente disponemos de dos propiedades, por un lado el UserId, del tipo “provider:xxxxxxxx” y por otro lado un token de autenticación.

Debemos de saber que una vez autenticados con cualquiera de los proveedores, cualquier tipo de operación que realicemos referente a Mobile Services, estará autenticada. Quizás ahora mismo no se entienda esto, pero mas adelante será bastante importante.

Pero bueno, vamos a poner todo esto en practica, con el proyecto que tenemos entre manos. La pagina principal de nuestro proyecto, muestra la posibilidad de autenticarnos con cualquiera de los 4 proveedores mencionados anteriormente.

En esta pagina, disponemos de 4 botones, los cuales están enlazados a un comando, pasándole como parámetro un digito.

Dicho digito es el que usaremos para seleccionar el proveedor con el que nos autenticaremos. Nuestra viewmodel será la encargada de realizar esta autenticación a través del Execute del comando. Vamos todo muy MVVM. Mas o menos nuestra view model quedaría de la siguiente forma.

Nota: Es importante basarnos en una implementación del DelegateCommand, al cual podamos pasarle un parámetro o que podamos instanciarle sin dicho parámetro.

Nuestra view model, por un lado dispone del correspondiente ICommand publico enlazado con el DelegateCommand privado, el cual tiene definido el método Execute correspondiente. Vemos también que se ha creado una clase a través del interface usando inyección de dependencias.

Como ya os he comentado en el anterior post, vamos a hacer uso de una clase / servicio para todas las operaciones que realicemos con Mobile Services. Esta clase instanciada como he comentado a través de Inyección de dependencias de AutoFac dispone de un método denominado “Login” el cual le pasamos un valor entero que especifica el proveedor a usar. Y como veis devuelve el correspondiente objeto MobileServiceUser. Vamos a ver la implementación de dicho método en nuestro servicio AzureMobileService.

Nota: Puede parecer un poco enrevesado el pasar un parámetro string en el comando para luego convertirlo en entero, pero bueno no quería complicarlo mas pasando parámetros mas complejos.

Vemos que simplemente llamamos al método LoginAsync, de nuestra clase estática MobileClient (MobileServiceClient), pasándole el proveedor correspondiente en función al entero obtenido como parámetro. En un principio igualamos el valor de la variable provider al proveedor Facebook, porque no es posible asignarle un parámetro nulo a dicha enumeración.

Nos tenemos que dar cuenta de varias cosas, por un lado la asincronia de todo esto. Obviamente cuando nuestra aplicación accede a una web de autenticación y esta retorna, nuestra aplicación esta esperando dicho retorno. Puede ser que el usuario cancele el login, o que no dispongamos de conexión en ese momento o cualquier otra caso que si no encerramos nuestra llamada dentro de un try, puede suponernos un problema.

Con todo esto al retornar el método en nuestra view model lo suyo seria comprobar que dicho valor retornado no es nulo y actuar en consecuencia. En nuestro proyecto en ese caso vamos a navegar a otra pagina, llamada PrincipalPage. Para ello vamos a apoyarnos en otra clase / servicio creado a tal efecto para todos los procesos de navegación en nuestra aplicación. Concretamente llamaremos a un método denominado NavigateToPrincipalPage.

Nota: No es objeto de esta serie de post explicar la navegación o mas características de Windows Phone, pero iré desgranando poco a poco todo lo que me vaya a encontrar por el camino.

Podemos ver en el código anterior por un lado el método de navegación en nuestra clase / servicio de navegación y por otro lado la ejecución del comando un poco mas completa al comprobar que si el retorno del login no es nulo, entonces navegamos.

Realización de Logout.

Ya estamos autenticados en nuestra aplicación, pan comido. ¿Pero que ocurre cuando queremos des autenticarnos? (existe ese palabro?) Podemos observar si hacemos los pasos anteriores, o si simplemente disponemos de una aplicación que haga algún tipo de autenticación contra uno de los 4 proveedores que en el momento de volver a autenticarnos ya no se nos pregunta por nuestro usuario y password, directamente se autentica y accede.

Es decir en nuestra aplicación si nos autenticamos por ejemplo en Facebook y mas tarde salimos de la aplicación y volvemos a entrar, al pinchar en Facebook, la aplicación navega directamente a la PrincipalPage y tan contenta. Bueno pues para realizar dicho logout, simplemente debemos de llamar al método Logout de nuestra clase MobileServiceClient.

Este método reacciona y a partir de entonces todas nuestras comunicaciones con Mobile Service pasan a ser sin autenticar. En nuestra aplicación, vamos a colocar una barra de aplicación en nuestra PrincipalPage, con un menu item para realizar dicho logout. Y vamos a crear un nuevo método en nuestro servicio de Mobile Service llamado Logout, precisamente para realizar esto.

Lo suyo seria, que en el momento de hacer el logout, saltáramos a la MainPage para poder volver a realizar la autenticación correspondiente. Por esa razón hemos creado otro método en nuestro servicio de navegación, que hace exactamente eso y le hemos llamado NavigateToMainPage. Prestos y dispuestos debemos entonces crear la lógica correspondiente en la view model de nuestra nueva pagina (PrincipalPage).

Nota: Podéis ver que es un método publico, no un comando, ya que estoy usando un ApplicationBar normal y corriente y esta como todos sabréis no es bindeable.

A continuación, otra vez en la MainPage, al volver a pulsar sobre la autenticación con Facebook, otra vez se debería de cargar la pagina del proveedor, autenticarnos, bla, bla, bla…. Pues no. automáticamente realiza la autenticación, sin pedirnos nada, y claro está siguiendo la ejecución de nuestra aplicación navega a PrincipalPage. ¿Entonces que demonios de logout hemos echo? Efectivamente es un error en toda regla.

Ya hemos comentado con el equipo de producto este error y parece ser que están en ello. 😛 La causa son las cookies de autenticación que se quedan generadas en nuestro dispositivo y que estas no se eliminan al realizar el logout.

¿Solución?, bueno pues de momento realizar una pequeña ñapa. ¿No se borran las cookies?, pues ya las borramos nosotros. Para ello basta con crear un objeto WebBrowser y llamar a su método asíncrono ClearCookiesAsync. Luego definitivamente nuestro método Logout de nuestro servicio creado para gestionar Mobile Services seria:

Persistencia de la autenticación.

Ya sabemos autenticarnos, ya sabemos desautenticarnos hacer logout. Pero queda un poco raro, que cada vez que entremos en nuestra aplicación tengamos que pulsar el botón de autenticación por ejemplo en Facebook, aunque se realice la autenticación de forma automática y accedamos a la PrincipalPage acto seguido. Lo suyo seria que hasta que no hagamos logout, cuando entremos en la aplicación automáticamente nos autentiquemos sin necesidad de pulsar el proveedor seleccionado.

Para ello basta con guardar los datos de nuestro objeto MobileServiceUser cuando realizamos el login. Cuando, como, donde?? Bueno pues quizás el mejor momento es justo después de autenticarnos y por supuesto el sitio es el isolated storage, yo mas concretamente lo suelo hacer en los settings. (A falta de PasswordVault como en Windows 8, buenos son los settings….)

Como veis lo que estoy haciendo es guardar tanto el userId, como el MobileServiceAuthenticationToken, ambos valores de tipo string. Para hacerlo me he apoyado en otro servicio creado, en este caso un servicio que dispone de unos métodos genéricos para guardar valores en el IsolatedStorageSettings. En concreto la grabación se realiza de la siguiente forma.

Obviamente esto se puede hacer de la forma que a cada uno le parezca mas correcta. Esta es simplemente la mía.

Ya disponemos de los datos de autenticación guardados, por lo que el siguiente paso seria que al entrar en la aplicación comprobemos si disponemos de dichos datos, si es así autenticarnos de forma automática, si no, pedir al usuario que realice la autenticación con cualquiera de los 4 métodos.

Para autenticar de forma automática un usuario, disponiendo de su userId y de su MobileServiceAuthenticationToken, basta como instanciar una nueva clase MobileServiceUser contra la propiedad CurrentUser de nuestro servicio.

Una vez instanciada la clase pasándole el userId, debemos de asignar el MobileServiceAuthenticationToken. En nuestra aplicación de ejemplo al navegar a la MainPage, comprobaremos si existe en las settings algún valor para el registro “token”, si es así procedemos a autenticarnos de forma automática si no es así mostramos los botones de registro.

Como podéis ver igual que existía un método para grabar datos de forma genérica en el servicio de almacenamiento. Existe otro para leer valores de dicho lugar. Así mismo la asignación del CurrentUser esta encapsulado en otro método de nuestro servicio de MobileService.

Por ultimo y simplemente para seguir con el ejemplo, deberíamos de cambiar la forma en la que realizamos logout, ya que a parte de hacer los procesos que hacemos debemos de eliminar los valores guardados en los settings.

Espero que os hayáis enterado de algo. Como veis disponer de una aplicación, la cual pueda pedir o no, autenticación basada en estándares oAuth a través de Azure Mobile Services es bastante sencillo.

El código fuente del ejemplo de como implementar todo esto y alguna cosa más, siguiendo la aplicación comentada lo encontrareis en el siguiente enlace.

Continuares con la serie de post sobre Azure Mobile Services en breve.

Nos vemos!!!

Una vez que hemos visto en el post anterior, que es, que nos ofrece y como podemos crear un servicio de Mobile Services, vamos a meternos manos a la obra y a empezar a tirar alguna línea de código que otra.

Lo primero que tenemos que hacer es descargarnos el cliente manejado de Mobile Services para poder operar con el servicio. Para obtener dicho cliente (o lo que es lo mismo, para obtener el SDK de acceso a Mobile Services) podemos ir a la sección de downloads dentro de la web de Windows Azure, concretamente en la url: http://www.windowsazure.com/es-es/downloads/, dentro de la sección de movilidad. Pero quizás la mejor forma es descargarlo a través de Nuget e incluirlo en nuestra solución. Para obtenerlo en Nuget, y encontrarlo de una forma mas fácil y directa, deberemos de buscar: “WindowsAzure.MobileServices”

Nota: A través de todos los post de esta serie, intentare crear una aplicación tipo. Dicha aplicación se llamará MyListOfTask. Vamos la típica aplicación de ToDo, al que intentare darle alguna nota diferenciadora. Obviamente, como todos sabéis, lo mío es Windows Phone, por lo que ese será el sistema elegido. No descarto en algún momento hacer lo mismo al menos para Windows Store y para Web.

Una vez instalado, el punto inicial para acceder a nuestro servicio en Mobile Services es instanciar la clase MobileServiceClient, contenida en el namespace Microsoft.WindowsAzure.Mobile. Si hemos incluido Mobile Services a través de Nuget no es necesario, pero si no fuera así, si hubiéramos descargado el SDK por otro método, para poder hacer referencia al namespace Microsoft.WindowsAzure.Mobile deberemos de hacer referencia al ensamblado Microsoft.WindowsAzure.Mobile.dll

Esto lo podemos hacer de muchas formas, quizás la mas extendida y la mas común de ver en cualquier tipo de proyecto que nos podamos descargar de la red, es instanciar esta clase como una propiedad estática dentro del fichero App.xaml.cs en Windows Phone.

Como veis en la parte superior, para instanciar esa clase es necesario indicar por un lado la url de nuestro servicio (recordáis la dirección con terminación .azure-mobile.net, que hemos indicado al crear el servicio) y la clave de aplicación. La url es fácil de saber o de recordar, pero en nuestra sección del panel de control de Windows Azure perteneciente a nuestro servicio móvil podemos verla. Por otro lado la clave de aplicación, la podemos encontrar en el mismo lugar, en la parte inferior, tras pulsar el botón de “Administrar Claves”

Una vez pulsado dicho botón, se nos muestran dos claves. Por un lado la clave de aplicación (la que nos interesa ahora mismo) y por otro lado la clave maestra (de la cual hablaremos en otro momento).

Luego nuestra instancia de la clase MobileServiceClient quedaría de la siguiente forma:

Como ya he comentado esta seria la forma de instanciar la clase necesaria para obtener un punto de entrada a nuestro servicio, o por llamarlo de otra forma, es la forma de crear un cliente de nuestro servicio móvil.

Simplemente con esto, ya tenemos nuestra aplicación enlazada. A partir de ahora deberemos de empezar a usar los servicios y las opciones que Mobile Services nos proporciona. Esto lo comenzare a realizar en las siguientes entradas de esta serie. Para realizarlo, me voy a apoyar en una “clase/servicio” a la que he denominado AzureMobileService. Con su correspondiente interface para usar inyección de dependencias, test unitarios y demás historias que iremos viendo con el tiempo.

Toda la estructura de la aplicación de ejemplo, esta montada en base a la utilización de MVVM, por lo que nuestro proyecto, en su punto embrionario quedaría de la siguiente forma.

Muchas cosas os pueden sonar raras en el proyecto si no estáis acostumbrados a trabajar con MVVM. No es este el cometido de esta serie de entradas, pero aprovechare para dar un buen repaso a la forma de trabajar con este patrón de diseño.

Nota: Dentro de nuestro proyecto disponemos de una “clase/servicio” para manejar nuestro dispatcher de forma mas cómoda. Se usa la inyección de dependencias a través de AutoFac, y alguna cosilla mas que quizás se me escape.

Nota 2: Si tenemos la intención de crear dos aplicaciones, una para Windows Store y otra para Windows Phone, y queremos crear el mayor numero de código común para ambas plataformas, lo suyo seria apoyarnos en una Portable Class Library. Desde el mes de marzo de este mismo año (si ahora mismo la memoria no me falla), es posible crear y manejar Azure Mobile Services a través de una PCL. El único problema que tenemos es que existen determinadas operaciones que no es posible realizarlas en la PCL y tendríamos que extenderla en cada uno de nuestros proyectos para realizarlo en Windows Store o en Windows Phone directamente. Esa es la razón por la que de momento no lo voy a crear, ya que complicaría la explicación

Seguido de estas líneas, podéis encontrar el enlace para descargaros el código fuente correspondiente a este segundo capitulo de la serie.

Nos vemos!!

Con esta entrada voy a comenzar una serie de post relacionados con Azure Mobile Services. Seguramente que todos vosotros conozcáis ya que es Windows Azure, y seguramente que también le halláis incado el diente a su pata de servicios móviles. Pero si que es cierto que existe mucha gente que desconoce por completo que es y que nos ofrece de una forma bastante sencilla Windows Azure Mobile Services.

¿Que es?

Para comenzar deberemos de decir que Windows Azure Mobile Services (a partir de ahora Mobile Services), es una parte del gran sistema de Windows Azure. Podríamos decir que Mobile Services es una especie (o sin especiar) de Backend as a Service. Es mas, en la infografía que os presento a continuación, realizada por Kinvey, aparece en dicha pata.

Existen en el mercado muchas alternativas que nos proporcionan lo mismo que hace Mobile Services. Por ejemplo Buddy, al que todos los que por disponer de una subscripción al desaparecido Nokia Premium Developer Program, podíais tener acceso, ya que se proporcionaban una serie de llamadas (creo recordar que unos cuantos millones de ellas) de forma totalmente gratuita. Pero bueno, unas ofertas nos pueden proporcionar una serie de cosas que otras no nos den, pero como somos desarrolladores .Net, quizás nuestra primera tendencia al menos para probarlo debería de ser Mobile Service.

¿Que nos ofrece?

Mobile Service, nos proporciona:

* Autenticación: Podremos configurar y usar de forma muy simple, la autenticación en al menos 4 sistemas de uso común. Facebook, Twitter, Google y Windows Live.

* Datos: Disponemos de una forma fácil de aprovisionar nuestro almacenamiento relacional en una base de datos de SQL Azure.

* Notificaciones: Sistema de envío de notificaciones a los principales servicios, entre los que se encuentran los de Windows (WNS) y Windows Phone (MPNS), Google (GCM) y Apple (APNS).

* Lógica en servidor: A través de scripts podremos generar lógica en el servidor que sea ejecutada al realizar operaciones en nuestros datos, bajo demanda, en periodos controlados, etc.…

* Apis de terceros: Podremos usar en nuestros scripts de servidor, Apis de terceros para realizar ciertas operaciones. Acceder a otras patas de Windows Azure y extender nuestro código.

* Supervisión, alertas y registro: Desde el portal de gestión podremos visualizar el estado de cualquiera de nuestros servicios. Podremos registrar cualquier aviso, o error que se genere en nuestros scripts de servidor y así mismo podremos de forma fácil comprobar la disponibilidad de cualquiera de nuestros servicios.

* Escalado: Cualquier servicio podrá escalar de forma vertical y horizontal de forma automática, siguiendo una serie de reglas prefijadas.

¿Desde que sistemas podemos acceder a este servicio?

Mobile Services es compatible y dispone de soporte nativo para aplicaciones Windows Store, Windows Phone, iOS, Android y HTML5 a través de JavaScript. También disponemos de una API REST con lo que cualquier tipo de sistema que sea capaz de enviar y recibir mensajes HTTP podría usar Mobile Services.

Recientemente se ha incorporado Xamarin como plataforma nativa, con la que poder usar Mobile Service.

¿Cuanto cuesta?

Mobile Services dispone de 3 niveles de servicio. Gratuito, Básico y Estándar. Cada uno de ellos se diferencia obviamente por el coste y por el numero de servicios o llamadas a la Api de Mobile Services que incorporan. En la siguiente imagen podemos ver un resumen de cada uno de ellos.

Podemos ver que disponemos de 10 servicios de forma totalmente gratuita. Los dos niveles siguientes nos muestran el precio por servicio, ojo, no por los 10 servicios. Repito es el precio mensual por cada servicio de forma independiente, ya tengamos 1 o 100.

El servicio o nivel gratuito es muy interesante, ya que sin pagar un solo euro dispondremos de hasta 10 servicios, con una posibilidad de acceso bastante importante al menos para el inicio de cualquier tipo de aplicación.

Como podéis ver aunque dispongamos de varios niveles de precios, en lo que se refiere al almacenamiento debemos de contratarlo por separado. Podemos decir que disponemos de una base de datos con un espacio muy limitado en cualquiera de ellas y que para ampliarlo debemos de contratar cualquiera de las opciones que la plataforma Windows Azure nos ofrece para su servicio de SQL Azure. A continuación os muestro una tabla con los precios de dicho servicio.

Nota: Hasta hace 4 días los niveles se denominaban Gratuito, Estándar y Premium, cambiar los nombres, pasando a ser el nivel Premium, Estándar, me hace pensar que no tardando aparecerá un nuevo nivel Premium con otras opciones y precio. Pero eso solo es pura especulación mía.

Nota 2: Para poder usar Mobile Services, es necesario disponer de una subscripción general a Windows Azure. Dicha subscripción no es gratuita (fuera de su oferta trial), pero en esencia lo es, si no usamos ningún servicio de pago de dicha plataforma. Es decir disponer del nivel gratuito de Mobile Service es 100% gratuito si no usamos otro servicio de Windows Azure.

¿Como empiezo a usarlo?

Para poder usar, configurar y gestionar Mobile Services, deberemos de disponer, como he comentado anteriormente de una subscripción a Windows Azure. Si no disponemos de una podremos crearla y beneficiarnos de su versión de evaluación gratuita de un mes, en la que dispondremos de 150€ gratuitos, para poder consumir en cualquiera de los servicios que nos ofrece.

Dentro de la consola de administración de Windows Azure disponemos de la sección de Mobile Services, tal y como vemos en la imagen de la izquierda. Para crear un nuevo servicio, simplemente deberemos de hacerlo desde la opción de la parte inferior de nuestra consola de administración. Y a continuación indicar que deseamos crear un servicio móvil. Lo primero que deberemos de indicar es la dirección url del servicio a crear. Esta dirección será generada con la terminación .azure-mobile.net. En nuestro caso vamos a crear un servicio cuya url completa seria: http://shaken.azure-mobile.net. También indicaremos que base de datos vamos a usar, si una base de datos creada anteriormente, o por el contrario vamos a crear una nueva base datos, entre las que podemos escoger si dicha nueva base de datos será la base de datos de 20Mb gratuita que se incluye con Mobile Services o una nueva base de datos normal de SQL Azure.

Por ultimo indicaremos en que región se va a ubicar nuestro servicio, dentro de las que Windows Azure tiene montados sus datacenters. Ojo con este dato, ya que dependiendo desde donde vamos a acceder a nuestro servicio ubicar este en una región u otra puede llegar a ser muy importante, debido a la latencia en la resolución y la devolución de datos si el servicio esta en una región y el acceso se realice desde el otro extremo del planeta.

En el caso de que escojamos usar una base de datos existente, se nos solicitara introducir los datos de inicio de sesión de la misma. Si por el contrario creamos una nueva base de datos, sea la opción de esta la que sea, se nos solicitara que indiquemos todos los datos de dicha base de datos, como su servidor, los datos de inicio de sesión en dicha base de datos y la ubicación del servidor que la contendrá.

Una vez rellenados y completados todos estos sencillos pasos y tras unos prudenciales segundos, ya dispondremos de nuestro servicio completamente operativo para poder usarlo a nuestro antojo.

Lo primero que deberíamos de hacer si es la primera vez que nos enfrentamos con Mobile Services es seguir los primeros pasos que se nos muestran en la primera sección de nuestro servicio. En dicha sección podremos descargar y probar de forma totalmente operativa una solución para cualquiera de las plataformas nativas con las que podemos trabajar, las cuales he citado anteriormente.

De forma sencilla se nos muestran los pasos a seguir para poder descargar dicha solución y crear en nuestro servicio una tabla de datos con la que poder interactuar. Así como las instrucciones que debemos de seguir para conectar una aplicación ya generada previamente con este servicio recién creado.

En los siguientes post, hablare de forma extensa, de cada una de las funcionalidades que nos da Mobile Services. Para finalizar os muestro una infografía realizada por Microsoft que resume que es y que nos aporta Windows Azure Mobile Services. Dicha infografía la podéis encontrar aquí.

Nos vemos!!

Muy buenas a todos.

Hace ya mucho, mucho tiempo que no escribo en este, mi santo blog. Y que mejor manera de retomar la actividad editora que anunciándoos un nuevo evento de la comunidad en el que voy a ser participe.

Como bien sabéis todos, mi gran amigo el Josué Yeray, es MVP de Windows Phone. Pues bien, como todos los que forman ese santo grupo son tan frikis o más que él, no se les ocurrió otra cosa mejor que intentar hacer un evento sobre Windows Phone, around de world, en una semana del mes de Octubre. Cada MVP debía de reunir a un equipo capaz de conformar un evento de día completo sobre desarrollo en Windows Phone.

Dicho y echo, comenzó a reclutar gente y a organizar el sarao y eme aquí, que yo mismo y estos otros 4 tarados (yo soy el tarado nº 1) el próximo día 5 de Octubre, en Madrid, te vamos a tener ocupadito todo el puñetero sábado explicándote que es esto del Windows Phone.

Nuestra intención es que las charlas sean algo avanzadas, dejándonos de una puñetera vez de hacer las típicas charlas de getting started y darle un poco mas de chica al asunto. Hablaremos como no de MVVM, de la nueva herramienta de Microsoft, App Studio. Del SDK de imágenes de Nokia, de NFC, de portabilidad de aplicaciones entre la versión 7 y esta nueva versión 8. Etc, etc, etc… Vamos que seguro que no os vais a aburrir.

Empezaremos sobre las 9 de la mañanita, bien temprano para que junto a las charlas y un elegante catering al que os invitaremos para comer, nos den eso de las 9 de la noche para poder ir por supuesto a tomar copas y café in Plaza Mayor.

Queremos que sea un día de charlas, networking, buen royo y sobre todo mucho, mucho Windows Phone. Para ello y para animaros a venir vamos a contar con una pila de regalos que nos facilitaran nuestros simpáticos sponsors. Desde licencias de Sematic Merge por parte de PlasticSCM, licencias de RadarC para Windows Phone por parte de Icinetic, códigos de acceso al App Studio de Microsoft, Componentes para Windows Phone por parte de Infragistics, códigos de registro en Pluralsight y como regalo jugosón un flamante Nokia Lumia 820.

Vamos que no hay excusas para que no podáis estar con nosotros.

Recordad: Sábado 5 de Octubre en Madrid (La ubicación exacta está por confirmar, pero seguro que esta a tiro de boca de metro), desde las 9 de la mañana, hasta las 8 o 9 de la noche (o hasta que nos echen….). Aquí justo debajo tenéis el vincula al registro, no os lo podéis perder……

 

 

Mientras llega el día podéis seguir toda la información puntual en nuestra cuenta de twitter @WinPhoneWeekEs o para cualquier tipo de consulta tenéis nuestra cuenta de correo oficiosa winphoneweekspain@outlook.es

Nos vemos en Madrid!!!!!!

Un año más, vuelve el Hackathon multiciudad simultáneo. El Megathon, durante el fin de semana del 12 al 14 de abril.

Este año se va a cambiar la dinámica del concurso. Por un lado se podrá desarrollar aplicaciones tanto para Windows 8 como para Windows Phone 8, los premios se incrementan, pero seguro que el buen ambiente y el buen rollo durante todo el fin de semana se va a mantener respecto al pasado año.

Yo, en esta ocasión, tengo el gran honor de estar como mentor en la sede de Salamanca. Los chicos del club .NET de la universidad de Salamanca, USAL, han querido que este con ello intentando ayudar en todo lo que pueda. Eso sí, estoy convencido que los ganadores globales del Megathon este año saldrán de Salamanca. No os quepa duda!!!!!

Otra de las cosas que este año han cambiado ha sido la formación. Muchos opinaron que el pasado año, combinar la formación con el tiempo para desarrollar fue algo estresante. En muchas ocasiones los mentores se encontraron dando charlas al limbo ya que todo el personal estaba dale que te dale a programar, lo digo por experiencia. En esta ocasión los chicos de DPE España, han tenido la gran idea de realizar unas formaciones online, los días previos al megathon.

Por lo tanto entre el próximo día 20 de Marzo y el 11 de Abril podéis “disfrutar” de sesiones de formación tanto de programación en Windows 8, Windows Phone, Azure y Team Foundation Services.

Si queréis mas información, no dudéis en acudir a la web habilitada para tal efecto en la web de Microsoft España.

www.microsoft.es/megathon

Allí encontrareis las bases, las ciudades, recursos de formación, etc., etc.….

Nos vemos en el MEGATHON!!!!

Si, lo sé. Gestionar que nuestra aplicación tenga o no capacidad de prueba no deja de ser algo muy trivial. Pero, de cosas triviales siempre se aprende algo…

Lo primero que debemos de hacer es controlar de alguna forma si nuestra aplicación esta en modo trial o no. Para ello usaremos la clase LicenseInformation contenida en el espacio de nombres Microsoft.Phone.MarketPlace.

Algún habido lector, habrá pensado, …..MarketPlace?, pero si eso suena a viejuno. Pues si, aunque con la aparición de Windows Phone 8 y el uso de WinRT existe un nuevo espacio de nombres para cualquier tipo de consulta relacionada con estos menesteres, concretamente Windows.ApplicationModel.Store, la clase LicenseInformation que deriva de dicho namespace no se puede usar en Windows Phone 7.x por lo que la mejor forma para hacer este trozo de código totalmente compatible tanto con Windows Phone 7.x como con Windows Phone 8, es usar la clase LicenseInformation de Microsoft.Phone.Marketplace.

Bueno, entonces está claro. Ahora, ¿cual debería de ser la mejor implementación?. Obviamente no quiero sentar cátedra pero siendo un poquito costosa, hablando de rendimiento, la labor de comprobar si nuestra aplicación es o no una versión de prueba. Lo suyo seria realizar esta consulta una sola vez y “archivar” esta información en algún lugar accesible.

Para ello, una de las mejores formas es disponer en nuestro fichero App.xaml.cs de una variable publica y estatica la cual implemente guarde dicha información.

private static bool isTrial;   

public static bool IsTrial   

{      

   get      

   {   

      return isTrial;      

   }   

}
Así mismo dispondremos de un procedimiento el cual comprobará mediante la clase LicenseInformation comentada anteriormente, si es o no, nuestra aplicación una versión de prueba. Le llamaremos por ejemplo CheckLicense.
private void CheckLicense()   

{   

   LicenseInformation license = new Microsoft.Phone.Marketplace.LicenseInformation();   

   isTrial = license.IsTral();      

}
Ok, perfecto. Simplemente implementamos la clase LicenseInformation y comprobamos su método isTrial, el cual nos devuelve un booleano indicándonos el estado.
Ahora debemos de lanzar en el lugar y momento correcto, el código anterior. Dos son los lugares en donde deberemos de lanzarlo. Por un lado el evento Launching de nuestra aplicación. De esta forma cada vez que lanzamos la aplicación comprobamos el valor. 
private void Application_Launching(object sender, LaunchingEventArgs e)

{

    CheckLicense();

}
El otro punto sería el evento Activated. ¿Para que?, si nuestra aplicación no va a cambiar su estado constantemente. Pues básicamente para poder controlar de forma correcta que se haya podido adquirir la aplicación de forma completa mediante un enlace colocado en nuestra aplicación o cuando nuestra aplicación esta suspendida. De esta manera al volver a activarla desde el estado de tombstoning recogemos el valor de forma correcta y actuamos en consecuencia.
private void Application_Activated(object sender, ActivatedEventArgs e)

{

    CheckLicense();

}
Perfecto ya tenemos controlado el acceso a la comprobación solamente en dos puntos, accediendo a la información en cualquier momento sin consumo de recurso alguno. 
Vamos a plantear una pantalla muy sencilla la cual, recoja este valor y realice una serie de acciones.
<Grid>

    <Grid Margin="0,0,0,0">

        <Grid.RowDefinitions>

            <RowDefinition Height="Auto"></RowDefinition>

            <RowDefinition></RowDefinition>

        </Grid.RowDefinitions>


        <TextBlock Grid.Row="0" Text="Trial version example"

                    VerticalAlignment="Top"

                    Margin="12,12,0,12"

                    FontSize="42">

        </TextBlock>

            

        <StackPanel Grid.Row="1">

            <Button Content="action A"

                    Margin="0,130,0,0"

                    HorizontalAlignment="Center"

                    Width="350"

                    Command="{Binding ActionACommand}">

            </Button>

            <Button Content="action B"

                    HorizontalAlignment="Center"

                    Width="350"

                    Command="{Binding ActionBCommand}">

            </Button>

            <Button Content="purchase complete version"

                    Margin="0,130,0,0"

                    HorizontalAlignment="Center"

                    Visibility="{Binding TrialVersion, 


                                Converter={StaticResource BoolToVisibility}}"
                    Width="350"

                    Command="{Binding PurchaseCommand}">

            </Button>

        </StackPanel>

    </Grid>

</Grid>
Obviamente (faltaría más) todo nuestro XAML usa una ViewModel de MVVM para realizar toda la lógica de nuestra pagina. Como podéis ver disponemos de 3 sencillos botones. El ultimo de los botones usa un converter para convertir la propiedad TrialVersion de nuestra ViewModel en el correspondiente valor de la enumeración System.Windows.Visibility.
Veamos ahora nuestra ViewModel por partes.
public class VMMainPage : VMBase

{

    bool trialVersion = true;

    Lazy<DelegateCommand> actionACommand;

    Lazy<DelegateCommand> actionBCommand;

    Lazy<DelegateCommand> purchaseCommand;


    public VMMainPage()

    {

        this.trialVersion = App.IsTrial;    

        ........

    }


    public bool TrialVersion

    {

        get

        {

            return this.trialVersion;

        }

    }


    ...........

    ...........

}
Hemos creado una variable privada la cual en el momento de instanciar nuestra ViewModel toma el valor de la variable estática contenida en nuestro App.xaml.cs. Por otro lado hemos creado las variables privadas de los DelegateCommands que usaremos a continuación.
Podemos ver también la propiedad publica TrialVersion, que hemos usado en nuestra vista para visualizar o no, a través del converter, el botón de purchase o compra de la aplicación.
    private void ActionACommandExecute()

    {

        MessageBox.Show("Action A");

    }


    private void ActionBCommandExecute()

    {

        MessageBox.Show("Action B");

    }


    private bool ActionBCommandCanExecute()

    {

        return !this.trialVersion;

    }
Ahora vemos la implementación de los comandos asignados a los dos primeros botones. Estos simplemente muestran un mensaje en pantalla (esto lo deberíamos de hacer con un servicio, pero bueno para no complicar mas las cosas…) En la inicialización del primero de ellos, no hemos asignado nada a la función de retorno del CanExecute, pero si en el caso del segundo botón. 
En el ejemplo dejamos el primer botón accesible a cualquiera de los dos tipos de estado de la aplicación, mientras que el segundo botón, estará deshabilitado si la aplicación está en versión Trial. Para ello retornamos el valor contrario a la variable privada isTrial como respuesta en el CanExecute de este segundo botón.
El resultado hasta el momento de nuestro pequeño ejemplo es el siguiente:

La mejor forma de dirigir al usuario a comprar la versión completa de nuestra aplicación es utilizar el lanzador MarketPlaceDetailTask, como podemos ver en la implementación del comando que ejecuta nuestro tercer botón.
    private void PurchaseCommandExecute()

    {

        MarketplaceDetailTask market = new MarketplaceDetailTask();


        market.Show();

    }
Así de sencillo. Simplemente instanciamos el lanzador y lo ejecutamos con su método Show. La clase MarketplaceDetailTask dispone de una propiedad denominada ContentIdentifier, la cual acepta un valor string que representa el ID del producto del cual queremos mostrar sus características para proceder a la compra. Si este valor no es asignado o es asignado un valor nulo, el lanzador muestra los datos de la aplicación la cual le ha llamado.
Lamentablemente si la aplicación no esta publicada, ya estemos ejecutando en el emulador o en un dispositivo físico, la llamada al método show de la clase nos lanzara un error como el que vemos a continuación. Es algo que debemos de tener en cuenta.

Bueno, pues llegados a este punto ya sabemos como controlar si nuestra aplicación esta en versión trial o versión completa. Como de forma muy sencilla poder gestionarlo con MVVM y como poder realizar la compra mostrando la correspondiente pagina de la Windows Phone Store de nuestra aplicación. Pero, ¿como podemos probar para dar valores según nos convenga a la variable IsTrial de nuestro App.xaml.cs? 
Ya que si ejecutamos la aplicación tal y como la tenemos hasta el momento al leer el valor del método isTrial, de la clase LicenseInformation, este siempre nos devuelve false.
Para ello existen principalmente dos formas, que cada uno usa según le parezcan. Por un lado podríamos detectar si estamos en modo debug y preguntar si queremos ejecutar en modo trial o en modo full. 
private void CheckLicenseWithQuestion()

{

#if DEBUG

    string message = "Pulsa 'OK' para simular el modo trial. Pulsa 'Cancel' para ejecutar la aplicación en modo normal.";

    if (MessageBox.Show(message, "Debug Trial",MessageBoxButton.OKCancel) == MessageBoxResult.OK)

    {

        isTrial = true;

    }

    else

    {

        isTrial = false;

    }

#else

    LicenseInformation license = new Microsoft.Phone.Marketplace.LicenseInformation();


    isTrial = license.IsTrial();

#endif

}
En el código anterior hemos modificado nuestro procedimiento CheckLicense para que, mediante el uso de directivas de compilación condicional, en el caso de que estemos compilando en modo debug, nos lance una pregunta para elegir el modo de prueba de la aplicación. Activado o desactivado. En el caso de que estemos compilando en versión release, directamente se comprobara el modo de ejecución a través de la clase LicenseInformation. El resultado seria el siguiente:

Pero este método solo funcionara en aplicaciones para Windows Phone 7.x, ya que la llamada al método Show, de nuestro MessageBox, en Windows Phone 8 no se puede hacer hasta que no se ha inicializado el elemento RootVisual de nuestra aplicación. Es decir para poder usar este método en WP8, no es posible indicar la llamada en el evento Launching, sino que lo deberemos de invocar en el evento CompleteInitializePhoneApplication, tras la asignación del RootVisual.
Esto trae mas problemas, ya que si llamamos en ese lugar al procedimiento CheckLicense, nuestra ViewModel principal ya a sido creada por lo que ya hemos recogido los valores de la propiedad IsTrial, sin haberla dado el valor que queremos. La implementación en este caso debe de ser diferente y deberíamos de comprobar los valores de dicha propiedad sobrescribiendo el evento OnNavigatedTo de nuestra pagina principal.
Otra forma seria seguir implementando el procedimiento CheckLicense como hasta el momento, y simplemente en el modo debug activar siempre el modo trial.
private void CheckLicense()

{

#if DEBUG

    isTrial = true;

#else

    LicenseInformation license = new Microsoft.Phone.Marketplace.LicenseInformation();


    isTrial = license.IsTrial();

#endif

}
Esto tiene un gran inconveniente y es que para poder probar la versión completa, deberemos de compilar en modo release, perdiendo todo lo que el modo debug nos aporta. Para solventar este problema podríamos crear en Visual Studio una nueva configuración de compilación. Para ello debemos de dirigirnos al menú “Build > Configuration Manager”. Dentro de él, seleccionamos del combo “Active solution configuration”, el valor “<New…>”.

En la nueva pantalla que se abre, indicaremos un nombre para la nueva configuración, por ejemplo “Debug Trial” e indicaremos que queremos copiar todos los valores de la configuración ya existente “Debug”.

Una vez creada esta nueva configuración vamos a otorgarla una valor necesario para nuestro cometido. Para ello, entraremos en las propiedades de nuestro proyecto y en la pestaña de “Build” seleccionaremos la nueva configuración que acabamos de crear, en este caso “Debug Trial”.

Una vez seleccionada, solamente deberemos de añadir en la casilla de “Conditional compilation symbols:” la palabra “TRIAL” precedida de un punto y como para separarla de las que ya existen. Ojo en el ejemplo indico la palabra Trial, pero obviamente podríamos usar la que quisiéramos.

Con nuestra nueva configuración ya creada y parame trizada a nuestro gusto, tan solo nos resta modificar definitivamente nuestro procedimiento para adecuarle a los nuevos cambios.
private void CheckLicense()

{

#if TRIAL

    isTrial = true;

#else

    LicenseInformation license = new Microsoft.Phone.Marketplace.LicenseInformation();


    isTrial = license.IsTrial();

#endif

}
Como vemos la directiva de compilación condicional, ahora busca la palabra “TRIAL” en vez de genéricamente “DEBUG” como anteriormente. Ahora cuando queramos ejecutar en modo debug versión trial, seleccionaremos una opción de compilación, en el caso de compilar en modo debug en versión completo, seleccionaremos otra. Según nos convenga en cada caso.

Ya tenemos todo nuestro código implementado. Como comento al principio esta es una de las muchas formas de realizar la gestión de las versiones trial de nuestras aplicaciones. 
Pero una cosa es segura, cualquier aplicación de pago que se precie de disponer si o si de una versión Trial. Los datos aportados por la Windows Phone Store lo indican. Las aplicaciones con versiones trial son descargadas 70 veces mas que las que no las tienen. Con una media de un 10% de conversiones a versión completa. Lo que representa un 10 veces más ingresos que una aplicación que no disponga de versión trial.
Aquí os dejo el enlace a un ejemplo de código que muestra todo lo que he comentado hasta el momento.

Para cualquier cosa, ya sabéis donde estoy….  
A pasarlo bien.
	

Una vez mas vuelve el concurso semanal por excelencia de aplicaciones para Windows Phone de la mano de Microsoft Ibérica. A partir de hoy mismo, 1 de febrero y hasta el 15 de Mayo. Se sorteara una XBOX 360 por semana para todo aquel que desarrolle y publique en la Windows Phone Store una aplicación.

Pero este año disponemos de otra categoría. Y es que también cualquier persona que desarrolle y suba una aplicación para Windows 8, también tendrá su propio sorteo de otra XBOX 360 por semana.

La adjudicación de premios es por riguroso sorteo entre todos los participantes en la promoción, 1 premio para Windows Phone y otro para Windows 8. En esta ocasión no existirá ni jurado ni calificación de la aplicación, quien mas suerte tenga será quien se lleve el gato al agua.

A parte de esto si durante el transcurso de esta promoción es activada una subscripción a Windows Azure, podrás ganar una subscripción a MSDN.

Un aliciente mas para desarrollar……

Suerte a todos.

Bueno, pues lo que comenzó hace ya medio año, y que tuvimos una pequeña previa recientemente, ya es una realidad. Hoy 15 de Enero de 2013, ya esta disponible para su compra nuestro mega libro de desarrollo en C# y XAML.

Recuerdo ahora mismo las muchas conversaciones que Yeray y yo hemos mantenido sobre la escritura de este libro. Sobre disponer en español de una buena fuente de información sobre la programación en estas plataformas siguiendo un patrón de diseño especifico, en este caso MVVM y trabajando siempre con buenas practicas.

Lo que en su momento iba a ser algo sencillo, de distracción para el verano, se fue convirtiendo poco a poco en un mastodonte que no hacia mas que crecer en contenido. Seguramente a ambos nos hubiera gustado contar mas cosas en el libro. Por ejemplo por falta de tiempo nos hemos dejado en el tintero cosas como la gestión de procesos en Background, la gestión de trials, el In-app purchase, y muchos mas etcéteras que seguro poco a poco irán viendo la luz en nuestros respectivos blogs…

Pues nada, lo dicho, aquí podéis adquirir nuestro nuevo libraco y a empezar a degustarlo poquito a poquito, que tiene su miga.

Por cierto, gracias a la colaboración de Nokia España, todos los que compréis el libro el primer mes, entrareis en el sorteo de un flamante Nokia Lumia 820, una subscripción al WP Dev Center, componentes de Telerik y alguna cosilla más.

Con lo que no podéis dejar pasar esta oportunidad. ALE A COMPRAR…..

Antes de terminar, quiero dejar aquí constancia de los agradecimientos expresados por mi parte en el libro. Nunca podre expresar todo lo que mi familia me ha ayudado para poder llegar hasta aquí, por lo que esto es otra pequeña gota de gratitud.

“Cuando hace ya unos cuantos meses, Yeray y yo decidimos escribir este libro, jamás me hubiera imaginado que fuera a ser una de las tareas más costosas de todo cuanto he realizado hasta el momento. Todo el tiempo que he dedicado en su escritura, se lo he tenido que robar al sueño y por supuesto a mi familia. Por esa razón, solo puedo agradecer a mi mujer Susana y a mi hija Celia, su inmensa paciencia al verme un día sí  y otro también pegado al portátil, sin dedicarlas en los últimos meses el tiempo que ambas se merecen. Gracias por vuestro apoyo constante y por creer tanto en mí»

Llevo ya un tiempo dándole vueltas a la cabeza, pensando en que podría proponerme este 2013 como proyecto personal, que me mantuviera un poco alejado del teclado del ordenador. Para mi este 2012 a sido un tanto estresante y muy agobiante, con proyectos nuevos en el trabajo, escritura de libros, preparación de cursos, etc.…

Por ello y tras reflexionar me he marcado el súper objetivo que durante mucho tiempo a rondado mi cabeza. Después de recopilar un millón de tutoriales, planos, experiencias y demás, me lanzo a la piscina y en este 2013 pienso construir mi propia maquina arcade.

Si, lo sé, soy consciente de que por menos de 1000€ tengo uno totalmente renovado y nuevo listo 100% para su uso (precio mas que razonable para un trasto como este, que no deja de ser un capricho como otro cualquiera). Pero quiero hacerlo yo solito y además con esto seguro que consigo matar ese demonio que tengo dentro el cual se empecina en hacerme ver que no llevo un bricomaniaco en la sangre….

Podréis seguir mis avances en mi blog personal www.rafaserna.es ya que poco o nada tiene esto que ver con .Net y la programación. Pero eso si no esperéis que vaya como un rallo. Paciencia, todo lleva su tiempo.

Aprovecho para felicitaros a todos el año y que el 2013 venga, como he leído reciente, con 365 nuevas oportunidades.

FELIZ 2013 A TODOS

Desde hace tiempo, estoy un poco alejado del mundanal ruido de blogs, twitter y demás. La razón no ha sido otra que hacer posible un deseo que tenia desde hace mucho tiempo, escribir un libro.

Antes de nada, que se que nadie lee los post hasta el final. Aquí esta el enlace para que lo podáis comprar YA.

Hace tiempo, nos propusimos el amigo Yeray y yo, que teníamos que escribir algo juntos. Sinceramente jamás creí que me iba a costar tanto poder plasmar en papel todos los conocimientos que tengo en mi cabeza, por que amigos una cosa es escribir un blog y otra muy distinta escribir un libro.

Pero bueno, después de muchas horas de trabajo y muchas horas de sueño perdido, junto con la ayuda de dos cracks, Ibón Landa, nuestro colaborador incansable y José Manuel Alarcón, nuestro editor convencido, este libro puede estar en la calle.

 

Os presento “Introducción al desarrollo en Windows 8 y Windows Phone 8”, este “mini” libro consta de 190 paginas en las que abordamos una introducción a las herramientas de desarrollo para ambos sistemas, descripción de conceptos de programación basados en el patrón Model View ViewModel (MVVM), el lenguaje visual XAML, los principales elementos de una interfaz visual tanto para Windows 8 como para Windows Phone 8 y por ultimo una explicación detallada de que pasos debemos seguir para publicar nuestras aplicaciones tanto en la Windows Store como en la Windows Phone Store.

Pero aquí no acaba la cosa, esto es solo un pequeño aperitivo, es la avanzadilla de algo mucho mas grande, es simplemente una introducción del libro “Desarrollo en Windows 8 y Windows Phone 8”. Un libraco de casi 500 paginas con el que pretendemos guiar a cualquier desarrollador en las nuevas características de programación para ambos sistemas.

Pero para esto aun tenemos que esperar un poco mas. Eso si gracias a Krasis Press, todo aquel que adquiera el libro de introducción, el cual solo esta disponible en versión PDF, dispondrá de un cupón de descuento del importe total si decides comprar el libro grande.

Así que os lo vuelvo a recordar. COMPRAD MI LIBRO, que aunque esto no lo hayamos hecho para salir de pobres (bueno nunca se sabe), al menos nos queremos tomar alguna que otra caña a vuestra salud.

Por ultimo, desde aquí quiero agradecer el inmenso trabajo de mi compañero de fatigas, Josué Yeray, sin mi aportación es muy probable que el libro en algún momento estuviera de todos modos en la calle, pero sin la suya este proyecto jamás hubiera llegado a su fin.

En mis años de juventud en el colegio recuerdo haber plantado mas de 1 árbol. Tengo una mujer estupenda y una hija que es un autentico regalo y un sol de niña. Acabo de escribir y publicar un libro. Si, ya me puedo morir en paz.