Windows Phone & Azure. Shaken, not stirred.

Lo normal en estos casos hubiera sido comenzar este post escribiendo: “Como veíamos ayer” o mejor dicho: “Como comentaba en el anterior post”, pero es que desde que escribí mi ultimo post en este blog ha pasado ya tanto tiempo que me da vergüenza.

Demasiado trabajo quizás, ganas de compartir mi poco tiempo libre con la familia, dedicarle ratos mas largos a mi hija….. No sé, un cumulo de cosas, que llevan a uno a despistarse un poco y ver un día que hace mas de 4 meses que no escribo en el blog.

Bueno, pues en este 2015 pienso volver a los buenos hábitos y desde ya a ponerme a punto con este tema. No es que ahora vaya a volverme loco, escribir un post cada día o algo así. Pues no. Pero al menos si intentar volver a este blog de forma mucho mas asidua.

Pero también antes de empezar quisiera dejar aquí plasmado todo eso que me ha pasado en estos últimos meses. Cosas impresionantes para mi.

Lo primero de todo es que, allá por el 1 de Octubre, recibí en mi buzón de email, El Correo. Y no, no era la nueva edición del diario vasco, era simplemente el correo con mayúsculas. El reconocimiento por parte de Microsoft como nuevo y flamante MVP en la división de Windows Platform Developer.

Vamos, que pasaba a formar parte de ese nutrido grupo de gente a la que siempre había admirado y porque no, envidiado. No por nada, sino simplemente por que sabia que era gente con unos conocimientos técnicos increíbles, y mira tu por donde a partir de ese momento pasaba yo a ser uno de ellos. Obviamente, aunque ya lo hice en su momento en persona, quiero dejar aquí escrito mi agradecimiento a 3 personas.

Primero a Juan Carlos González, lo mas parecido a lo que podría ser mi padrino en todo este sarao de las comunidades técnicas, las charlas, los eventos… El fue quien me introdujo y el fue el que siempre me ha animado a seguir y a compartir. Quizás sin el jamás hubiera dado el paso de ponerme delante de gente a contarles batallitas sobre Windows Phone o lo que se tercie. Gracias chaval.

Segundo a Josué Yeray, mi gran amigo, casi mi hermano (metafóricamente hablando). Este tipo si que es un grande. No he visto nunca a nadie mas respetuoso, entregado y apasionado por la comunidad. De el he aprendido una barbaridad, a moverme en estos saraos con soltura, a saber comunicar, y sobre todo a pasármelo de miedo evento tras evento. A parte de a no abandonar nunca por muy cansado que estuviera y por muchas otras responsabilidades que tenia que cumplir. Gracias Master.

Y tercero, pero no ultimo a Cristina González. Responsable de mantener a ralla a todos estos locos que forman (formamos) la familia de MVPs en España. Cualquier cosa que la pidas, allí esta. Y sobre todo gracias por confiar en mi y por brindarme esta oportunidad.

Bueno pues después de este subidón de moral y casi sin poder darme cuenta, llegó noviembre y con ello el MVP Summit. Así que nos cogimos las maletas y para Seattle que nos marchamos.

La verdad es que fue una semana inolvidable. No solo por las charlas técnicas con las que allí nos obsequiaron, sino por el ambiente, la gente, los pedazo de cracks a los que conocí en persona y con los que tuve la suerte de compartir cuatro palabras. Y sobre todo por la compañía. El frente de liberación canaria, representado por Alberto Díaz, Santiago Porras, David Rodríguez y su mujer Carmen. Junto con Adrián Díaz y Juan Carlos González fueron los que me tuvieron que aguantar en mi periplo Summitero. Eso sí, se echaba en falta a uno…….

 

 

 

 

 

 

 

 

 

 

 

Pero seguro que 2015, va a ser también un año estupendo. Muchas cosas geniales se divisan por el horizonte……… Pero de momento a escribir en el blog como primera intención del año. Así que…. recomencemos.

Un saludo a todos.

Se dice que el internet de las cosas, será el próximo boom dentro de la industria de la informática. Llevamos ya un tiempo a rastras con estos temas, esperando a que nuestra nevera nos realice el pedido automático cuando se quede sin comida, o que la lavadora nos avise cuando haya terminado de realizar la colada, etc.. Pero realmente este sector, por una cosa u otra no acaba de despegar. También se debe de tener en cuenta que yo no veo a mi madre indicando que programa de lavado es el mas optimo para la ropa desde el móvil, cuando no fue capaz nunca de poder programar el video para grabar la telenovela….

Si que se hacen cosas por supuesto, si no que se lo digan a Bruno Cendon que trabaja diariamente con ello o a la gente que esta detrás de las Smart Cities, como la gente de SmartSantander. Pero el tema es que no es algo masivo de momento.

Pero vamos que esto parece que es hasta ahora. Muchas de las grandes compañías, se están poniendo las pilas ya. Muchas posicionándose en el sector a golpe de talonario, como el mas o menos reciente caso de Google con la adquisición de Nest Labs o la actual compra de Dropcam. Y otras adaptando sus entornos al uso de tecnología enfocada al IoT.

Microsoft por su parte, en la pasada conferencia //Build celebrada en San Francisco en abril de este 2014, ya realizo una primera charla enfocada directamente a este tema. Steve Teixeira, que lo mismo podría ser de Cambados con ese apellido, nos enseño en que estaba trabajando Microsoft con respecto al IoT, Windows Embedded y .NET Micro Framework.

A la vez se hacia publica la web WindowsOnDevices en la que a modo de preview se nos instaba a registrarnos y esperar mas noticias sobre el tema.

Bueno, pues ese momento parece ser que acaba de llegar. Este pasado viernes, la web windowsondevices.com a sido finalmente liberada en su totalidad y ya podemos saber que es eso que han venido a llamar Windows Developer Program for IoT.

Seguramente que todos conocéis que es una placa de Arduino, o al menos os suena ese nombre. Bueno pues Microsoft nos insta a que nos apoyemos en una placa parecida y sobre todo totalmente compatible en cuanto a pines de conexión. La Intel Galileo.

Cuenta con un micro controlador con procesador Intel Quark SoC X1000, procesador Pentium de 32Bits. Viene incluida una ranura mini PCI Express, puerto Ethernet de 100Mb, ranura Micro-SD, puerto serie RS-232, puertos USB tanto host como cliente, y una NOR Flash de 8Mb. Su tamaño es de 10cm de longitud por 7cm de ancho.

Pero como he comentado anteriormente lo mas importante de todo es que es compatible tanto con el software de desarrollo de Arduino, como con el hardware, por lo que son compatibles cualquier “shield” que lo sea de un Arduino Uno R3.

Lo primero y mas importante de todo es que podemos conseguir una placa Intel Galileo totalmente gratuita, si nos damos prisa claro, a través del programa de IoT de Microsoft. Simplemente regístrate en la web y pide tu placa para comenzar a crear tus propias “things”….

Otra de las cosas que el equipo de IoT de Microsoft quiere es que sean los desarrolladores los que apoyen y creen contenido. Por lo que toda la información y los Apis de desarrollo estarán basadas en el código abierto. Por poner un ejemplo, casi todo el contenido de la web WindowsOnDevices esta alojado en GitHub.

En cuanto al desarrollo, de momento, Intel Galileo soporta el set completo de instrucciones de la API Wiring de Arduino (casi sin un solo cambio) y un subconjunto de instrucciones de Win32, sobre C++. En un futuro seguro que no muy lejano podremos crear nuestros propios desarrollos en C#, ya que se pretende que vayan de la mano del concepto de Aplicación Universal (eso lo quiero ver yo).

Pero bueno, como vemos es solo el principio. Un principio que espero sea algo grande en no mucho tiempo.

Por otro lado, este próximo lunes en la conferencia de Partners de Microsoft, la WPC. Está previsto que se presente un nuevo servicio de Azure enfocado directamente a IoT. Windows Azure Event Hubs, se espera que sea un lugar en donde nuestros sensores podrán ir dejando información para que luego pueda ser procesada por otros sistemas y procesos. Pero eso, de momento, esperaremos un poco mas para verlo.

Bueno pues a partir de ahora, tendremos que estar muy atentos a la gente del equipo de IoT para ver que nos van contando. Pete Brown, Daniel Rosenstein o el propio Steve Teixeira.

Nos vemos!!

Todo el mundo sabe que una de las características de Azure Mobile Services es la posibilidad de enviar notificaciones a los 3 servicios principales (Microsoft, tanto WNS para aplicaciones Windows Store y Windows Phone 8.1 como MPNS para Windows Phone 8.0 y anteriores. Notificaciones de Apple y notificaciones de Google Cloud para Android). Pero el ecosistema de Microsoft Azure, dispone también de un servicio denominado Service Bus, que contiene una característica llamada hubs de notificaciones y que en esencia tiene la misma capacidad.

Hace ya un tiempo que existe la posibilidad de enlazar nuestros servicios móviles con los hubs de notificaciones. Y ahora mismo con la ultima actualización realizada en Azure Mobile Services, cada vez que creamos un servicio con backend .NET, también se nos crea un hub de notificaciones.

El hub de notificaciones, ni mucho menos esta pensado solamente para ser usado con Mobile Services. Es un servicio pensado para que cualquier tipo de backend o de aplicación pueda gestionar y enviar notificaciones de una forma sencilla y sobre todo transparente.

Si nos ponemos ahora en el lado del uso de Mobile Services, es lógico que nos asalte una gran duda. ¿Cual de los dos sistemas es el que debemos de usar para enviar notificaciones? Bueno, pues en este post, voy a contar como se usa el hub de notificaciones, por lo que podremos ir viendo que características aporta este frente a Mobile Services y tomar así una decisión.

Registro de dispositivos.

En el hub de notificaciones, disponemos de la capacidad de registrar los dispositivos a los cuales vamos a enviar notificaciones en el futuro. Este registro se puede realizar, desde dos lugares distintos. Desde el propio dispositivo, conectándonos directamente al hub de notificaciones o desde nuestro servicio móvil, el cual enviará la información al hub de notificaciones. Realizando esto crearemos un PNS handle (Platform Notification Service handle), expresión o acrónimos que simplifican y agrupan los distintos tipos de handles o tokens de identificación usados en las diferentes plataformas soportadas. ChannelUri para dispositivos Windows, GCM para dispositivos Android, etc.…

Tenemos que tener en cuenta que al igual que expiran los PNS, también lo hacen las inserciones de dispositivos en este servicio. Disponemos de un máximo de 90 días de retención. Pasado ese tiempo serán eliminadas de forma automática. Por este motivo debemos de refrescar periódicamente desde el dispositivo cliente esta información.

Vamos a ver como podemos desde una aplicación de Windows Phone 8.1, registrarnos en el hub de notificaciones.

Nota: Existen librerías cliente de este servicio tanto para Windows Store (WNS), Windows Phone (MPNS), Objective-C (APNS de Apple) y Java (GCM para Android). Pero estas APIs o librerías de dispositivo solo nos dan la facultad de registrar dispositivos, nada más. Con estas librerías no podremos en ningún momento enviar notificaciones.

En el caso de Windows Phone 8.1, o de Windows Store, deberemos de descargarnos el paquete nuget correspondiente a “WindowsAzure.Messaging.Managed”. Ojo, este paquete, nos da acceso a todo lo relacionado con Service Bus. Nosotros solo veremos aquí, lo correspondiente al hub de notificaciones.

Aunque no es materia de este post, vamos a ver como registrar nuestra aplicación de Windows Phone 8.1 para que funcione y para obtener un canal de notificaciones.

Una vez que disponemos de ese canal / uri de notificaciones, este es el que pasaremos para registrar nuestro dispositivo en el hub de notificaciones.

Lo primero que debemos de hacer es crearnos una referencia al hub de notificaciones a través de la clase NotificactionHub. Para posteriormente registrar nuestro dispositivo a través del método asíncrono RegisterNativeAsync. Debemos de saber que este método, se usa tanto para registrar un dispositivo nuevo, como para la actualización de uno ya existente.

Vemos que al crear la clase NotificationHub, debemos de especificar el nombre de nuestro hub de notificaciones, y como segundo parámetro la cadena de conexión segura al mismo. Cadena de conexión de DefaultListenSharedAccessSignature. Este dato está accesible en el portal de Azure, en la información de conexión, dentro de nuestro hub de notificaciones.

Si este proceso le quisiéramos realizar directamente en nuestro backend de Mobile Services, con tecnología en .Net deberíamos de realizar lo siguiente.

Primero debemos de comprobar que nuestro servicio tiene de forma correcta configurado el enlace con el hub de notificaciones. Como he comentado anteriormente al crear un servicio móvil con tecnología en .Net automáticamente se nos crea un hub de notificaciones, pero el lugar en donde este esta enlazado con el servicio es en la pestaña de inserción (Hub), en la sección de la base de datos central de notificaciones (xxxxxxxxx)

Ya dentro de nuestro servicio, vamos a crear un ApiController para gestionar la inserción de nuestros dispositivos. En este controlador vamos a interactuar con el hub de notificaciones desde WebApi, por lo que deberemos de descargarnos el paquete de nuget correspondiente. “WindowsAzure.ServiceBus” es el que debemos de instalar.

Vamos por partes (como dijo el señor Jack). Lo primero de todo es que nuestro controlador va a recibir un objeto Json. Esto lo podemos hacer así para facilitar la llamada desde cualquier plataforma a este servicio y lo homogeneizamos. Pero vamos que cualquier otro sistema para enviar los datos de entrada, por supuesto que es valido.

Como vemos, debemos de crear un objeto NotificationHubClient, perteneciente al namespace Microsoft.ServiceBus.Notifications, indicando la cadena de conexión y el nombre de nuestro hub de notificaciones. La cadena de conexión debe de ser la misma que usamos si accedemos directamente desde un dispositivo cliente, DefaultListenSharedAccessSignature.

Extraemos los datos de nuestro objeto Json y dependiendo de la plataforma de la cual estemos realizando la llamada usaremos un método del objeto NotificationHubClient u otro. Como podemos ver disponemos de Mpns, para Windows Phone hasta la versión 8.0 (incluido 8.1 para Silverlight), Windows para aplicaciones Windows Store y Windows Phone 8.1 (Store). Gcm para dispositivos Android, Apple para dispositivos iOS y Adm (Amazon Device Message) para dispositivos Kindle. (sí, sí, has leído bien…. Kindle)

Una vez ejecutado el método CreateXXXXNativeRegistrationAsync nos devuelve un objeto del tipo RegistrationDescription, objeto de contenido similar que el objeto Registration que nos devuelve el método de registro en el hub cuando estamos usando el cliente en el propio dispositivo.

Nota: Aunque en el objeto Json que paso como parámetro al controlador disponga de un parámetro denominado ChannelUri, esto lo hago así por sencillez. Pero en cada caso introduzco en dicho parámetro lo necesario para el registro. El ChannelUri en el caso de Windows, el DeviceToken en el caso de Apple, etc…

A continuación muestro un ejemplo de como podríamos enviar la información desde una aplicación Windows Phone a través de nuestro servicio móvil.

Ya he comentado que el registro de los dispositivos es totalmente transparente para el programador. De todo se encarga azure. Dependiendo del canal de registro, ChannelUri, DeviceToken o el que corresponda en cada caso, el hub de notificaciones usa concurrencia optimista para realizar el control del registro. En algún caso nos podría dar algún tipo de excepción por este control, pero será el propio servicio el que se encarga de reintentar el registro o la actualización de forma también transparente.

En la llamada al método de registro, el objeto que nos devuelve, tanto en la clase Registration, como en la clase RegistrationDescription podemos ver una propiedad llamada ETag (entity tag). Esta propiedad es el identificador único que denomina el registro de cada uno de los dispositivos.

Hasta ahora hemos visto como poder registrar dispositivos directamente con las clases que nos proporciona el espacio de nombres de Services Bus. Pero si el registro lo realizamos a través de Azure Mobile Services, este, puede ser aun mucho mas sencillo y transparente. Basta con implementar la clase MobileServiceClient encargada de todas las operaciones entre nuestro dispositivo y Mobile Services.

Dentro de dicha clase, llamaremos a la extensión GetPush(), para finalmente invocar el método RegisterNativeAsync, pasándole como parámetro nuestra Uri de notificaciones.

Con esta simple llamada estaremos registrando el dispositivo, sin necesidad de usar ninguna Api de Service Bus directamente.

Dentro del namespace de ServiceBus disponemos de métodos para consultar todos los registros de los diferentes dispositivos, comprobar que estos se han registrado de forma correcta, el numero de ellos, etc., etc.… Pero como muchas otras cosas, existen atajos que nos pueden ayudar mucho. Paolo Salvatori, Principal Program Manager de Windows Azure, a desarrollado una aplicación denominada Service Bus Explorer. Con ella, entre otras muchas cosas podremos visualizar de forma rápida los dispositivos registrados en nuestro hub de notificaciones.

El registro de dispositivos es una gran diferencia entre Notification Hubs y Mobile Services. En Mobile Services, somos nosotros los que nos tenemos que encargar de crear una tabla para guardar el registro de los canales de notificación, mantenerle en condiciones (actualizar las uris de conexión o tokens de direcciones, borrarles cuando estos estén caducados, …..)  Con el hub de notificaciones, esto es totalmente transparente para nosotros. Tiene todo lo necesario para realizar estas operaciones con garantías.

Offtopic: en muchos lugares os podéis encontrar la denominación de Azure Mobile Services como ZuMo.

Tags.

Mobile Services esta pensado para realizar el envío de notificaciones de forma individualizada. Notificación a notificación. Sin embargo, el hub de notificaciones esta diseñado para ser un transmisor a gran escala, un broadcasting. Lo veremos mas adelante pero si quisiéramos realizar el envío de una notificación, por defecto el sistema no discriminaría  y realizaría el envío a todos los dispositivos registrados que fueran de la plataforma indicada. Para evitar esto y poder de alguna forma “categorizar” estos envíos se usan los tags.

Un tag no es mas que como digo una categorización. Por ejemplo, si nuestra aplicación muestra un listado de noticias podemos registrarnos para que nos lleguen notificaciones de cambios en las noticias de deportes y / o en las de economía. 

Por supuesto que otra categorización podría ser nuestro propio usuario. Al registrar un dispositivo en ningún momento estamos diciendo a que usuario pertenece, simplemente registramos el token de conexión. Pero ¿y si necesitamos enviar una notificación a un usuario en concreto?. No tendríamos forma de identificarlo dentro de todos los dispositivos registrados (no de una manera directa, al menos). Podemos usar un tag para este fin.

Existe una sobrecarga en el método de creación del registro de un dispositivo, tanto si este le realizamos a través del cliente directamente o a través de nuestro servicio móvil. Esta sobrecarga acepta como segundo parámetro una lista de string, que son los tags que identifican y categorizan a ese dispositivo. Obviamente un dispositivo puede tener asociado uno o n tags.

En el código anterior, realizamos el registro directamente desde una aplicación de Windows Phone 8.1, añadiendo nuestro usuario (una vez autenticados a través de mobile services) y un par de categorías de noticias a las cuales queremos estar “subscritos”.

Como se puede ver no es mas que una lista de strings. En el caso del nombre de usuario, me permito la licencia de convertirlo de “provider:userId” a “provider_userId” básicamente por tener controlado en todo momento el signo de ‘:’ para futuros usos.

Tenemos que tener en cuenta que al registrar o actualizar un dispositivo debemos de pasar en todo momento todos los tags que queramos asociarle. Al actualizar un dispositivo este no conserva los tags que tuviera y añade los nuevos que le pasemos. Borra toda la información y la substituye por la nueva que le pasamos, por lo que siempre es necesario pasar todos los tags.

En el caso de realizar el registro a través de una Api dentro de Mobile Services el sistema seria similar. Por cada uno de los métodos de cada tipo de dispositivo también disponemos de las sobrecargas correspondientes para añadir tags al registro de nuestro dispositivo.

Por ultimo si el registro le realizamos directamente a través de la clase MobleServiceClient, también existe dicha sobrecarga para indicar los tags asociados al dispositivo.

En este ultimo caso existe una consideración a tener muy en cuenta. Cuando es el propio servicio móvil el que registra el dispositivo a través de la clase cliente en cada plataforma podemos “subscribirnos” a dicho proceso de registro y modificar, añadir o incluso cancelar dicho registro desde el propio servicio. Para ello deberemos de crear una clase en nuestro Mobile Service que implemente el interfaz INotificationHandler.

Al implementar este interfaz, nuestra clase dispone de 2 métodos. Register el cual es invocado al registrar un dispositivo y Unregister que se invoca justamente en el caso contrario. En el ejemplo anterior simplemente lo que estamos realizando es a todo dispositivo que se registre añadirle a las tags que ya incorpora en el proceso de registro una nueva (“someTag”).

Como podemos ver el objeto que nos interesa es el parámetro registration del tipo NotificationRegistration. En este parámetro es donde podemos comprobar por ejemplo la plataforma con la propiedad Platform, los Tags como hemos visto, etc.. También disponemos de la propiedad services que nos proporciona acceso al entorno de Mobile Services desde esta clase.

Nota: El backend en .NET para Azure Mobile Services, dispone de una manera peculiar, bueno o mas bien fija, de registrar los componentes que le conforman. Entre ellos esta la clase que he comentado anteriormente. Nuestro backend en el momento que encuentra una clase publica, no estática que implemente el interfaz INotificationHandler, la registra de forma automática para que sea invocada cuando corresponda. Vamos, todo un poco mágico.

Bueno hasta aquí la forma de registrar nuestros dispositivos al Hub de notificaciones. En el siguiente post mostrare como se realizan los envíos de estas notificaciones a los dispositivos registrados.

Aquí os deja el código fuente de una solución en la que implemento todo lo que hemos visto hasta ahora.

Nos vemos!!!

Una de las tareas mas frustrantes a la hora de manejar y utilizar Azure Mobile Services, ha sido hasta ahora la depuración de los servicios. Con la llegada de la posibilidad de crear nuestros servicios con .NET, esto ha pasado a la historia. Vamos a ver en este pequeño tutorial, (de los que no me gustan, ya que no tiene ni una sola línea de código, pero bueno), como hacerlo.

De una manera muy muy sencilla podemos publicar, y subscribirnos al proceso en la nube para poder depurarlo. A parte, con la llegada del update 2 (aunque de momento en versión RC) es aun mas sencillo si cabe.

A parte de esto, Visual Studio 2013 Update 2 RC, ha traído un montón de nuevas características para interactuar con nuestros servicios móviles en la nube.

Para ver todo esto, vamos a comenzar creando un servicio móvil con tecnología .NET, en nuestra subscripción de Azure. Una vez creado, hasta ahora deberíamos de descargarnos el proyecto del mismo desde el propio portal, pero ahora ya podremos crearlo directamente desde Visual Studio. Ya que incorpora una nueva plantilla que nos facilita la creación.

Una vez nuestro proyecto en marcha, y tras realizar las mejoras que necesitemos lo primero será publicarle. Hasta ahora, deberíamos de acudir al portal de Azure, descargarnos el perfil de publicación y publicar. Otra de las mejoras introducidas en Visual Studio, es que podremos seleccionar el servicio en donde queremos publicar de forma automática, sin descargar ningún tipo de fichero de publicación.

Para ello, al seleccionar la opción de publicar, sobre nuestro proyecto de backend de Azure Mobile Services, nos aparecerán las opciones del mismo. Entre ellas la opción de Azure Mobile Services. Una vez seleccionada, nos solicitara que hagamos login y que seleccionemos el servicio sobre el cual queremos publicar. A parte de esto disponemos también de la posibilidad de crear el propio servicio desde aquí, sin necesidad de ir para nada al portal de Azure.

Una vez desplegado, ya podríamos testearlo. Para realizar esto, el servicio no nos permite realizarlo si no estamos autenticados, siempre y cuando estemos dirigiéndonos a https. Para ello basta con insertar la clave de aplicación (conseguida en el portal de Azure) en la contraseña, dejando el usuario en blanco.

Bueno, pues desplegado y pudiendo testearlo sin problemas, vamos ahora a realizar el debug del servicio. Anteriormente era algo un poco mas tedioso, pero ahora, otra de las nuevas características de VS 2013 Update 2 RC es poder hacer esto de forma fácil. Para ello, en la pestaña de Server Explorer, dentro de Visual Studio, desplegamos la sección de Windows Azure, y dentro de ella la de Mobile Services. Con todos los servicios de los que disponemos visibles, pulsamos sobre el que queremos realizar el debug y con el botón izquierdo, desplegamos el menú contextual y seleccionamos que queremos “adjuntarnos” al depurador.

Al realizar cualquier tipo de interacción con el servicio salta Visual Studio y podemos realizar sin problema la depuración.

Una cosa deberemos de tener en cuenta. Por defecto la depuración se realiza siempre y cuando hayamos desplegado el servicio en modo debug y que en el portal de Azure hemos indicado que la depuración esta activa (dentro de la pestaña de configuración de nuestro servicio). Sin estos dos requisitos no funcionará dicha depuración en remoto.

Después de este tutorial sencillito, seguro que ahora ya ves con mejores ojos esto de Mobile Services. Si, lo sé, node.js y Javascript, es……….

Nos vemos!!!!

El pasado sábado 29 de marzo, tuve la suerte de ser participe de un gran evento a nivel global sobre Azure. Grandes ponentes de la talla de Ibón Landa, David Nudelman, Rodrigo Corral, Pablo Doval, etc.. compartieron cartel, junto a mi amigo Santiago Porras (por cierto recientemente nombrado nuevo MVP, felicidades Champion!!!) y un servidor. En nuestro caso, pudimos explicar a grandes rasgos que es y como se debe de usar Azure Mobile Services. El evento fue un autentico éxito, ya que conseguimos juntar a mas de 150 personas un sábado en un evento de jornada completa.

A continuación os dejo la presentación y las demos que usamos para la parte de Windows Phone y la parte Web. El proyecto que utilizamos para mostrar las «bondades» del enlace con Mobile Services en Android. Y tengo que decir que para demostrar como se puede acceder a Azure Mobile Services a través de peticiones REST, usé Embarcadero Delphi XE5. También os dejo un enlace a este proyecto.

Como ultima parte, existe un fichero zip, que contiene los scripts usados en la parte servidor.

Proyecto Visual Studio (Windows Phone 8.0 y HTML – Angular.js) > AzureBootCamp.zip

Proyecto Embarcadero Delphi XE5 (Rest) > Delphi_AzureBootCamp.zip

Proyecto Eclipse (Android) > Android_AzureBootCamp.zip

Scripts en servidor (Node.js) > Scripts_AzureBootCamp.zip

Nos vemos!!!

El pasado 20 de febrero el señor Scott Guthrie presentaba en su blog, como suele ser normal, las novedades incorporadas a la plataforma Azure. Y entre dichas novedades se colaba de rondón la nueva posibilidad de realizar nuestro backend en la nube con Azure Mobile Services, desarrollando este con .NET a parte de la opción actual de Node.js (JavaScript)

Esta característica es algo que los desarrolladores estábamos demandando desde hace bastante tiempo y la cual habían anunciado que estaría disponible pero que se resistía.

No es que la característica de tener un pedazo de soporte para backend en JavaScript fuera malo. Ni mucho menos. Pero poder desarrollar en .Net nos da una potencia y sobre todo una capacidad de depuración que hasta ahora no teníamos.

Entre tanto viaje, tanta charla y demás tampoco me ha dado tiempo a hincarle el diente a fondo a esta nueva característica. Tengo que decir que esta en modo preview y que por tanto puede que nos de algún que otro problemilla. Desde que salió, he debido crear unos 20 servicios de los cuales 3 no se han generado, mostrando un magnifico error 500 en el proceso de creación. Pero bueno como todo en modo preview, ya sabemos que tiene estas cosas.

Otra cosa que está también un poquito a medias es la documentación sobre el servicio, disponible en el sitio de Azure. De momento es escasa, pero algo es algo.

Pero bueno vamos al lio. Una vez creado nuestro servicio e indicando que queremos que este sea con el backend en .Net podemos descargarnos una solución de ejemplo del mismo desde la pestaña inicial, para manejarla con nuestro Visual Studio. Tenemos que tener en cuenta que ahora Azure Mobile Services con soporte para .Net en esencia es un contenedor de soluciones ASP.Net Web API. Por lo que podremos combinar la potencia de este tipo de soluciones con la potencia que persé, nos proporciona el servicio.

Lo primero que llama la atención es que de momento este tipo de servicio solo tiene soporte para aplicaciones Windows Store, Windows Phone 8 e iOS. De momento nada de Android, Xamarin, etc….

Nada mas descargar el servicio demostración desde el portal, deberemos de cargar todas las referencias de los paquetes usados en dicha solución a través de Nuget.

A primera vista podemos ver varias cosas. Por un lado, el servicio que nos podemos descargar de ejemplo es MVC5. Por otro lado las referencias especificas a Mobile Services son las librerías:

• Microsoft.WindowsAzure.Mobile.Service.dll
• Microsoft.WindowsAzure.Mobile.Service.Entity.dll
• Microsoft.WindowsAzure.Mobile.Service.Tables.dll

Todas ellas en la versión 1.0.195 beta. Si quisiéramos instalarnos estas librerías desde Nuget, para añadirlas a un proyecto MVC, que queramos usar en Azure Mobile Services, deberemos de buscar por “WindowsAzure.MobileServices.BackEnd”.

Lo siguiente que podríamos hacer, para probar, es enlazar una aplicación Windows Phone por ejemplo con este servicio. Pero en este caso para poder depurarlo de forma correcta, la referencia al mismo se la debemos de indicar en nuestro propio localhost. Es decir en el momento de instanciar la clase estática MobileServiceClient, asignaremos la URL de nuestro servicio a nuestro localhost.

Deberemos de actualizar las librerías de enlace cliente con Mobile Services, concretamente la librería Microsoft.WindowsAzure.Mobile, dentro del paquete de Nuget WindowsAzure.MobileServices a la versión 1.1.4 del mismo día 20 de febrero.

Una vez realizada esta actualización podemos ver que la creación de la clase MobileServiceClient acepta un solo parámetro. En este caso la Url local.

El funcionamiento interno, dentro de nuestra aplicación cliente es mas o menos similar a cuando disponíamos del servicio con backend JavaScript. Pero como todo, existen variaciones y formas diferentes de realizar las cosas.

Para subir este servicio desarrollado en .Net a su correspondiente Mobile Service, basta con publicarlo a través del perfil de publicación que nos podemos descargar desde el portal de Azure.

Vamos como si de una Website hospedada en Azure se tratara. El funcionamiento es el mismo.

Scott Guthrie a “prometido” que en un futuro no muy lejano (no como la galaxia de StarWars 😉 dispondremos de herramientas especificas para trabajar con estos servicios, depurarlos y hacer mas cositas directamente desde el propio Visual Studio. Esperaremos a ver que nos proporcionan entonces los chicos de Azure.

En los próximos post, intentare mostrar que cosas han cambiado con respecto a esta nueva forma de generar nuestros backends en Mobile Services.

Nos vemos!!!

El otro día junto a mis compis del grupo hispano de Windows Phone y Quique, tuvimos un estupendo hangout sobre Azure Mobile Services y App Insight. Aquí os dejo todo el material que usamos. Mi presentación, el código de ejemplo que utilice y el video del hangout.

A disfrutarlo.

HangOut:

 

Presentación:

WPSUG Azure Mobile Services from Rafa Serna

 

Código de ejemplo:

 

Nos vemos!!!

Recientemente ha visto la luz una nueva comunidad hispana sobre Windows Phone. WPSUG. Junto a Josué Yeray, Santiago Porras y Javier Suarez, me he embarcado en la organización y coordinación de este grupo de usuarios.

Hemos cogido la comunidad de Google Plus ya existente (sí, G+ existe…) en la cual ya éramos mas de 400 usuarios y queremos dinamizarlo mucho mas. Por lo que lo primero ha sido crear nuestro propio dominio, el cual simplemente apunta a dicha comunidad de Google. www.wpsug.net

A todo esto le hemos añadido nuestra propia cuenta de twitter @wpsug un canal en youtube y una lista de correo.

Para empezar de una forma correcta, hoy lunes 30 de diciembre de 2013, a las 18:00h (hora peninsular española) estaremos los 4 moderadores (Yeray, Santi, Javier y yo) presentando la comunidad en un hangout, al cual podéis apuntaros en el siguiente enlace.

https://plus.google.com/events/c40eihnjuice0fo7kvavml6aqg0?authkey=CIOqqr_chvXXcA

Nos vemos.

El pasado martes 10 de Diciembre, participe en una de las sesiones de webcast que junto a unos grandes amigos estamos realizando en torno al desarrollo para Windows Phone. Josué Yeray, Alejandro Campos, Javier Suarez, Santiago Porras y Roberto Luis Bisbé, son mis compañeros en esta nueva iniciativa.

Bueno pues como digo mi webcast en este caso, fue sobre el desarrollo con NFC. Aquí os dejo tanto la presentación que utilice como el pequeño ejemplo que desarrolle en vivo.

Podéis ver en este enlace la grabación del webcast.

Código de ejemplo:

Nos vemos!!!!