MvvmCross 4.0 por fin entre nosotros.

NewLogo

Ayer, 5 de febrero se ha publicado la versión estable de MvvmCross correspondiente a la versión 4.0 de la misma. Y esta vez no es una versión cualquiera, se trata de un giro de tuerca a esta librería tan conocida para usar el patrón MVVM en nuestras aplicaciones Xamarin.

La verdad es que se ha realizado un gran trabajo. Para empezar por darle una vuelta al diseño y branding de todo lo que rodea a MvvmCross, desde su logo, pagina web, blog, ejemplos, etc..

Por otro lado se han renombrado todos los namespaces de la librería, desapareciendo de ellos el nombre de Cirrious (empresa de Stuart Lodge). También han desaparecido de los paquetes toda referencia a HotTuna.

Otras muchas modificaciones y nuevas incorporaciones, han llegado con la nueva versión. De la que se están liberando versiones alpha y beta desde hace mas de 4 meses, hasta llegar al día de hoy en donde tenemos por fin versión estable.

Disponemos de novedades en cuanto a integración con proyectos de UWP y Xamarin.Mac, mejoras en el soporte de Android, soporte para Xamarin.Forms, uso de C# 6, y unas cuantas cosas mas.

Si queréis ver el anuncio de la versión estable y un resumen de todas sus novedades os podéis pasar por el blog de MvvmCross.

http://mvvmcross.com/blog/mvvmcross-40-stable-announcement

Introducción a MvvmCross

mvvmcrossDespués de realizar la charla en el evento Talks4Kids sobre MvvmCross, me he decidido a escribir una serie de post (y quizás algo más), para explicar de forma concisa el uso de esta librería para desarrollar aplicaciones multiplataforma con Xamarin.

En un principio, me voy a ceñir en estos primeros post a explicar el uso de MvvmCross con Xamarin Classic. Es mas complejo de usar, pero quizás es la mejor manera de explicar y entender el uso. Pero lo primero es lo primero, que es MvvMCross.

MvvmCross es una librería de código abierto, creada por Stuart Lodge, allá por el año 2011. Parte de un proyecto anterior que se denominaba MonoCross y fundamentalmente es usada para dar soporte al framework MvvM dentro de aplicaciones desarrolladas con Xamarin, tanto en su versión Classic como Forms y aplicaciones nativas del ecosistema de Windows, tanto escritorio como móvil.

MvvmCross aporta casi todos los artefactos usados en cualquier librería o framework de Mvvm, así como la capacidad de binding sobre elementos tanto en proyectos Android como iOS. Debemos de recordar que en iOS por ejemplo el patrón de creación de aplicaciones es obligatoriamente MVC y en Android no existe un patrón, vamos no existe un patrón de facto, normalmente se usa el patrón ASM, aunque podemos encontrarnos también aplicaciones creadas según MVC como en iOS.

MvvmCross actualmente soporta proyectos de Xamarin.Android, Xamarin.iOS, Xamarin.Mac, WPF, Windows Store, Windows Phone y Universal Windows App.

La estructura básica de cualquier proyecto que use MvvmCross (también conocido como Mvx) se basa en el proyecto o proyectos de cada una de las plataformas, mas otro proyecto central (core) consistente en una librería de código portable o PCL. Por ejemplo, en una solución en la que tengamos un proyecto para desarrollar nuestra aplicación sobre Xamarin.Android, el aspecto mas o menos que nos podríamos encontrar de primeras al crear su estructura básica seria el siguiente:

Solution

Lo primero que debemos de realizar si queremos usar Mvx, es añadir a nuestros proyectos, (tanto los proyectos de plataforma como la PCL) los paquetes necesarios a través de Nuget. Estos paquetes están dentro de MvvmCross.HotTuna.MvvmCrossLibraries. Al instalarlo también se instalaran las librerías del core MvvmCross.HotTuna.CrossCore y MvvmCross.PortableSupport, de las cuales depende.

Nuget

Actualmente se encuentra en fase beta la versión 4.0 de estas librerías. Todos los ejemplos y explicaciones de este y los siguientes post, a no ser que lo comente de forma explicita les crearé usando la versión 3.5.0.

Nota: Como curiosidad, todas las librerías que componen Mvx, tienen como nombre de espacios la denominación de Cirrious.Cirrious Ltd es la empresa que en 2008 creo Stuart Lodge y en la que comenzó a usar MvvmCross.

Bueno, ya tenemos nuestro proyecto para Android en este caso y nuestra PCL. A parte hemos añadido mediante Nuget las librerías necesarias para usar Mvx. Y ahora que hacemos?

Clase App.cs

Lo primero es crear (tal como se ve en la imagen de la solución inicial mas arriba), una clase principal, normalmente denominada App.cs, dentro de nuestro proyecto PCL, que hereda de MvxApplication. MvxApplication se encuentra dentro del nombre de espacios Cirrious.MvvmCross.ViewModels.

MvxApplication, es una clase que implementa el patrón Singleton y será la encargada de ayudarnos con el ciclo de vida de nuestras ViewModels, servicios, modelos, etc.. Ojo, no debemos de confundir esta clase, con los objetos ApplicationDelegate en iOS o Application en Android y Windows, que son los encargados de gestionar el ciclo de vida de la aplicación.

Una vez creada la clase, una de las tareas a realizar es el registro de una clase que implementa la interfaz IMvxAppStart, mediante el método RegisterAppStart. Esto se puede realizar por ejemplo al sobrescribir el método Initialize, aunque existirían otros lugares en donde se podría realizar. De momento nuestra clase App es muy sencilla, vemos como queda finalmente:

namespace MvxExample.Core
{
using Cirrious.MvvmCross.ViewModels;

public class App : MvxApplication
{
public override void Initialize()
{
RegisterAppStart<ViewModels.StartViewModel>();
}
}
}

Nota: Doy por sentado que para seguir este post y los que vendrán, sabes usar MVVM, que significan cada una de las clases y mas o menos cuales son cada una de las partes que lo conforman. Si no fuera el caso, es necesario conocer todo esto, para ello puedes comprar mi libro sobre desarrollo para Windows 8, en el que existen 2 grandes capítulos dedicados a este patrón, visualizar algún video como por ejemplo este en donde explicamos el patrón en los hangouts de Desarrollo Web o leer algún que otro post explicándolo todo.

View Model StartViewModel.cs

Ok, ya tenemos nuestra clase principal, App, que lanza y registra una IMvxAppStart. Que es esto. Pues básicamente la ViewModel o ViewModels (porque podremos asignar mas de una) que se mostraran en el inicio de la aplicación.

Para crear esta o cualquier otra ViewModel, debemos de crear una clase que implemente MvxViewModel del nombre de espacio Cirrious.MvvmCross.ViewModels. La implementación de MvxViewModel, nos aporta la infraestructura como si de una ViewModel Base se tratara. Para este primer ejemplo crearemos esta ViewModel, con una sencilla propiedad, la cual por supuesto implementa notificación de cambios.

namespace MvxExample.Core.ViewModels
{
using Cirrious.MvvmCross.ViewModels;

public class StartViewModel : MvxViewModel
{
private string initialText;

public StartViewModel()
{
InitialText = "Hello MvvmCross";
}

public string InitialText
{
get { return this.initialText; }
set
{
this.initialText = value;
RaisePropertyChanged(() => InitialText);
}
}
}
}

Clase inicial, App, una ViewModel, StartViewModel. Ok, esto va tomando forma, ahora lo que necesitamos es configurar nuestro proyecto de plataforma (en el ejemplo el proyecto Android), para usar toda esta infraestructura. Para ello usando convencionalismos de nombres necesitaremos crear en el proyecto una clase que se denomine Setup.cs.

Nota: MvvmCross esta lleno de convencionalismos de nombres. Debemos de acostumbrarnos a que las clases y demás artefactos necesarios deben de tener unos nombres concretos. Por ejemplo, de no indicar lo contrario por defecto, nuestras ViewModels y nuestras vistas se van a enlazar si tienen el mismo nombre, como veremos mas adelante.

Clase Setup.cs

La clase Setup, sirve de entrada e instalación del sistema de MvvmCross dentro de cada una de las plataformas. Dentro de ella podremos realizar un montón de pasos, todos ellos encaminados en la personalización de MvvmCross. En esta primera aproximación, vamos a dejar nuestra clase Setup del proyecto de Android reducida a la mínima expresión. Ya entraremos en modificarla y añadir una personalización mas profunda en próximos capítulos.

Toda clase Setup de cada una de las plataformas debe de implementar una clase homónima de la plataforma correspondiente. MvxStoreSetup, en el caso de proyectos WindowsStore, MvxPhoneSetup, para Windows Phone, MvxWpfSetup en WPF, MvxTouchSetup para iOS y MvxAndroidSetup en nuestro caso concreto que tenemos un proyecto Android.

namespace MvxExample.Android
{
using Cirrious.MvvmCross.Droid.Platform;
using Cirrious.MvvmCross.ViewModels;
using global::Android.Content;
    public class Setup : MvxAndroidSetup
{
public Setup(Context applicationContext) : base(applicationContext)
{
}

protected override IMvxApplication CreateApp()
{
return new MvxExample.Core.App();
}
}
}

Como comentamos la clase Setup, se encarga por un lado de recibir el contexto, root frame, UIWindow o lo que sea menester en cada plataforma y crear el objeto App implementado en la clase que hemos visto anteriormente.

Como podemos ver en el código superior, instanciamos el constructor de la clase, pasando el contexto de Android a la clase Base MvxAndroidSetup y por otro lado sobrescribimos el método CreateApp para retornar el objeto (recordamos que es un Singleton) App, de nuestra PCL.

De momento, como decimos es lo mínimo necesario para que nuestra aplicación Android, implemente la clase App, necesaria para el control del ciclo de vida de nuestras ViewModels y sea la encargada de realizar la magia necesaria para que todo esto funcione.

Como toma de contacto y para que nuestro circulo esté totalmente dispuesto para funcionar, es necesario implementar la clase Setup en algún lado y lanzar nuestra clase App. En cada una de las plataformas se realiza de una forma diferente, pero veremos ahora como realizarlo en Android, y en un próximo post, ya repasaremos plataforma a plataforma la forma de implementación.

Splash Screen

Como siempre existen varias formas de realizarlo pero en Android una de las mas sencillas es la creación de una Activity que implemente la clase MvxSplashScreenActivity.

Basta con indicar en el constructor cual es el fichero axml del layout y lo mas importante de todo indicar en las propiedades de la Activity que es el MainLauncher. Recordar que solo debe de existir un MainLauncher en toda la aplicación.

namespace MvxExample.Android
{
using Cirrious.MvvmCross.Droid.Views;
using global::Android.App;

[Activity(Label = "Splash Screen", MainLauncher = true,
Icon = "@drawable/icon")]
public class SplashScreen : MvxSplashScreenActivity
{
public SplashScreen() : base(Resource.Layout.SplashScreen)
{
}
}
}

Vistas.

Bueno pues como colofón final, simplemente nos quedaría crear la vista a la cual vamos a llamar en primer lugar. Recordamos que cuando hemos creado en la PCL nuestra clase principal de MvvmCross llamada App le indicamos que la ViewModel principal seria StartViewModel. Pues bien, vamos ahora a crear la vista que enlaza con dicha ViewModel.

En Android las vistas son un conjunto de 2 ficheros. Por un lado una clase que implementa MvxActivity. En este caso por facilitar la comprensión de nuestro proyecto, la vamos a ubicar dentro de una carpeta denominada Views y se llamará igual que la ViewModel que la usará pero sin la palabra Model, es decir en este caso tendrá el nombre de StartView (recordad lo que hemos comentado sobre los convencionalismos de los nombres, para que se haga magia entre todas las piezas).

namespace MvxExample.Android.Views
{
using Cirrious.MvvmCross.Droid.Views;
using global::Android.App;
using global::Android.OS;

[Activity(Label="Start View")]
public class StartView : MvxActivity
{
protected override void OnCreate(Bundle bundle)
{
base.OnCreate(bundle);
SetContentView(Resource.Layout.StartView);
}
}
}

Al igual que la StartScreen esta clase es una Activity a la que únicamente la debemos de indicar cual es su layout. mediante el uso del método SetContentView, le proporcionamos el id del mismo. Seguimos con convencionalismos y al layout le llamaremos de igual forma StartView.

Binding.

Al igual que creamos el fichero axml para el layout de nuestra StartScreen, crearemos el mismo para esta vista. Como hemos comentado anteriormente le llamaremos StartView.axml. En este caso va a tener un poco mas de chicha que la StartScreen y mostraremos el contenido de la propiedad InitialText que hemos creado en su ViewModel.

Para ello, lo primero que debemos de hacer es crear un nuevo namespace, que normalmente es definido como “local”, que apunte a la dirección “http://schemas.android.com/apk/res”, añadiendo el namespace de nuestro proyecto, y por supuesto crear un elemento TextView en donde mostraremos el texto.

Aquí es donde vamos a comenzar a usar los bindings característicos de Mvvm. En nuestra etiqueta TextView, crearemos una nueva propiedad referenciada sobre el nuevo namespace “local” creado anteriormente y “MvxBind”. En su valor indicaremos que queremos bindear, la propiedad Text del TextView con la propiedad InitialText de su ViewModel. > local:MvxBind=”Text InitialText”

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout 
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:local="http://schemas.android.com/apk/res/MvxExample.Android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    <TextView
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:textSize="40dp"
        local:MvxBind="Text InitialText" />
</LinearLayout>

Para que podamos usar estas propiedades y podamos realizar los bindings en Android es necesario crear un fichero de recursos en donde le indicaremos la definición de las etiquetas de atributos “MvxBind” y alguna otra. Para ello crearemos el fichero XML, el cual denominaremos “MvxBindingAttributes.xml” y el que colocaremos en la correspondiente carpeta “values”. El contenido completo de este fichero es el siguiente:

<?xml version="1.0" encoding="utf-8" ?>
<resources>
<declare-styleable name="MvxBinding">
<attr name="MvxBind" format="string"/>
<attr name="MvxLang" format="string"/>
</declare-styleable>
<declare-styleable name="MvxControl">
<attr name="MvxTemplate" format="string"/>
</declare-styleable>
<declare-styleable name="MvxListView">
<attr name="MvxItemTemplate" format="string"/>
<attr name="MvxDropDownItemTemplate" format="string"/>
</declare-styleable>
<item type="id" name="MvxBindingTagUnique"/>
<declare-styleable name="MvxImageView">
<attr name="MvxSource" format="string"/>
</declare-styleable>
</resources>

Con todos los ficheros que hemos creado, finalmente nuestra solución queda de la siguiente forma.

Solution Final

Bueno, pues ya tenemos todo lo necesario para usar MvvmCross en un proyecto Android con Xamarin. Podemos crear nuestras ViewModels y enlazarlas mediante bindings a sus correspondientes vistas (recordad que a no ser que indiquemos lo contrario, el enlace entre ViewModel y View es por convencionalismo de nombres). En posteriores post, veremos como a parte de bindear propiedades, podemos crear comandos, usar servicios y mil y una cosa mas.

Como resumen, os muestro a continuación un esquema del ciclo de vida de la app Android que acabamos de crear.

Esquema

Espero que os haya servido de ayuda como primera aproximación al uso de MvvmCross, puede parecer un poco lioso, pero como casi cualquier cosa, una vez que lo entendemos y lo dominamos la gran ventaja de usarlo en nuestros desarrollos multiplataforma con Xamarin es brutal.

Aquí os dejo el código de ejemplo de este primer proyecto.

1d_folder

Nos vemos.

[MATERIALES] Evento Talks4Kids – MvvmCross para dominarlos a todos.

touch-icon-ipad-retinaEl pasado 4 de diciembre celebramos en el auditorio principal de las oficinas de Microsoft en Pozuelo, un evento diferente, Talks4Kids. Con la escusa de ayudar a los niños, reunimos a 9 ponentes para dar un día de charlas sobre temáticas variopintas. Pero la cosa no quedo ahí. Pusimos precio a las entradas y organizamos patrocinios para intentar recaudar lo mas posible y ayudar a una ONG involucrada con los niños. Como aliciente, todos los ponentes nos comprometimos a disfrazarnos y hacer el “ridicalo” si conseguíamos una cantidad de dinero.

IMG_20151204_142237

Y vaya que si conseguimos recaudar. Al final entre asistentes y aportaciones de patrocinios nos juntamos con la friolera cantidad de 1900€ para donar a la Fundación Theodora para que siga llevando sonrisas a todos los niños hospitalizados de España. Una labor que seguro muchos de nosotros no somos consciente del valor que tiene.

Por mi parte, ataviado de las vestimentas de Gandalf, estuve explicando (lo mejor que esos largos pelajos me dejaron) como usar MvvmCross en el desarrollo de nuestras aplicaciones multiplataforma con Xamarin Classics.

A continuación tenéis disponible el video de la charla (si, nos grabaran……), las ppts y el proyecto de ejemplo que usé.

Gracias a todos los que asististeis, el año que viene pensamos volver a dar la misma guerra o más……..

Proyecto de Ejemplo:

1d_folder

[MATERIALES] Evento Hel10 Windows 10!! – Un mundo de notificaciones

Hace ya tiempo que en Madrid se celebro el evento Hel10 Windows 10. Pero como soy un autentico desastre aun no había colgado por aquí tanto las ppts como el proyecto de ejemplo que use para mi presentación. En esta ocasión hablé sobre las nuevas notificaciones interactivas, y el nuevo sistema de templates tanto para la creación de Tiles como para las notificaciones Toast.

Quisiera agradecer a Microsoft la oportunidad de dar esta charla en el pedazo de auditorio principal del teatro Goya de Madrid. La verdad es que impresiona.

WP_20151022_11_33_55_Pro

Aquí os dejo el video de la charla que le tenéis colgado en channel9, las slides y el código de ejemplo que use para esta presentación.

Nos vemos en la próxima.

Proyecto de ejemplo:

1d_folder

[Evento] 8º BetaBeers de Santander

El próximo 19 de Noviembre de 2015, a partir de las 19:15 horas se celebrará en Santander la 8ª edición del encuentro BetaBeers.

Voy a participar en esta edición realizando una pequeña introducción a las aplicaciones universales de Windows 10.

BetaBeers_59896839

A parte de mi, el evento va a contar con la presencia de dos Technical Evangelist de Microsoft. Isabel Cabezas y Gorka Madariaga, ambos pertenecientes al equipo de DX España. Los cuales hablaran sobre las posibilidades de compilación y creación de aplicaciones universales de Windows 10, a través de los nuevos “Bridges” que se han introducido en la plataforma.

Para poder asistir al evento y tomaros unas buenas cervezas Dougall’s, registraros en el siguiente enlace:

https://betabeers.com/event/8-betabeers-santander-3222/

[Evento] Hel10 Windows 10!

El próximo 22 de Octubre, tendrá lugar en Madrid, concretamente en el Teatro Goya. Uno de los mayores eventos sobre desarrollo e IT del año.Hel10

Creo que junto al evento de la DotNet Conference que se celebró a principios de año, este va a congregar a un montón de apasionados y profesionales de la tecnología en torno al nuevo sistema operativo de Microsoft, Windows 10.

Dividido en 4 tracks, vamos a tener la oportunidad de ver charlas sobre las nuevas Universal Windows Apps, temas de IoT, charlas sobre IT o sobre Windows 10 y entornos profesionales.

Por mi parte tengo la suerte de poder dar una charla sobre las notificaciones en Windows 10. Hablaré de los nuevos sistemas para crear templates de live tiles, sobre las notificaciones toast interactivas y sobre el control del nuevo Action Center.

Badge

Nos vemos en Madrid!!!!

[OFFTOPIC] Retrospectiva

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.

MVP_Logo_Horizontal_Preferred_Cyan300_CMYK_300ppi

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.

WP_20141102_15_19_46_Pro

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…….

WP_20141102_09_47_31_Pro

WP_20141105_09_58_39_Pro

 

 

 

 

 

 

 

 

 

 

 

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.

Microsoft y el Internet de las cosas – IoT

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.

LastWODWeb

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.

NewWODWeb

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.

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

El Hub de Notificaciones

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.

PushNotificationChannelManager
  1. var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
  2.  
  3. string channelUri = channel.Uri.ToString();

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.

NotificationHub
  1. NotificationHub hub = new NotificationHub(            
  2.     "shaken3nethub",
  3.     "Endpoint=sb://shaken3nethub-ns.servicebus.windows.net/;SharedAccessKeyName=DefaultLis……..");
  4.  
  5. Registration registration = await hub.RegisterNativeAsync(channelUri);

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)

MobileService_NotificationHubs

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.

NotificationController
  1. public async Task<RegistrationDescription> Post([FromBody]JObject registerCall)
  2. {
  3.     string notificationHubName = "shaken3nethub";
  4.     string connectionString = "Endpoint=sb://shaken3nethub-ns.servicebus.windows.net/;SharedAc……";
  5.  
  6.     var hubClient = NotificationHubClient.CreateClientFromConnectionString(connectionString, notificationHubName);
  7.  
  8.     var platform = registerCall["platform"] != null ? registerCall["platform"].ToString() : null;
  9.     var channelUri = registerCall["channelUri"] != null ? registerCall["channelUri"].ToString() : null;
  10.  
  11.     if ((platform == null) || (channelUri == null))
  12.     {
  13.         return null;
  14.     }
  15.  
  16.     RegistrationDescription registrationDescription = null;
  17.  
  18.     switch (platform)
  19.     {
  20.         case "windowsphone":
  21.             registrationDescription = await hubClient.CreateMpnsNativeRegistrationAsync(channelUri);
  22.             break;
  23.         case "windows":
  24.             registrationDescription = await hubClient.CreateWindowsNativeRegistrationAsync(channelUri);
  25.             break;
  26.         case "android":
  27.             registrationDescription = await hubClient.CreateGcmNativeRegistrationAsync(channelUri);
  28.             break;
  29.         case "ios":
  30.             registrationDescription = await hubClient.CreateAppleNativeRegistrationAsync(channelUri);
  31.             break;
  32.         case "kindle":
  33.             registrationDescription = await hubClient.CreateAdmNativeRegistrationAsync(channelUri);
  34.             break;
  35.     }
  36.  
  37.     return registrationDescription;
  38. }

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.

NotificationHubByZuMo
  1. var registerCall = new Dictionary<string, string>() {
  2.                      {"platform", "windows"},
  3.                      {"channelUri", channelUri}
  4.                    };
  5.  
  6. string registerUri = "https://shaken3net.azure-mobile.net/api/Notification";
  7.  
  8. var client = new HttpClient();
  9. var request = new HttpRequestMessage(HttpMethod.Post, new Uri(registerUri));
  10.  
  11. request.Content = new StringContent(JsonConvert.SerializeObject(registerCall),
  12.                                     Encoding.UTF8, "application/json");
  13. string messageDescription;
  14.  
  15. try
  16. {
  17.     HttpResponseMessage response = await client.SendAsync(request);
  18.  
  19.     messageDescription = await response.Content.ReadAsStringAsync();
  20. }
  21. catch (Exception ex)
  22. {
  23.     messageDescription = ex.Message;
  24. }
  25.  
  26. return messageDescription;

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.

Through ZuMo
  1. var channel = await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
  2.  
  3. string channelUri = channel.Uri.ToString();
  4.  
  5. MobileServiceClient zuMoClient = new MobileServiceClient("https://shaken3net.azure-mobile.net", "Password");
  6.  
  7. await zuMoClient.GetPush().RegisterNativeAsync(channelUri);

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.

ServiceBusExplorer

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.

NotificationHub with tags
  1. string userName = zumoClient.CurrentUser.UserId.Replace(":", "_");
  2.  
  3. List<string> tags = new List<string>();
  4. tags.Add("News:Economics");
  5. tags.Add("News:Sports");
  6. tags.Add(string.Format("User:{0}", userName));
  7.  
  8. Registration registration = await hub.RegisterNativeAsync(channelUri, 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.

Controller with tags
  1. switch (platform)
  2. {
  3.     case "windowsphone":
  4.         registrationDescription = await hubClient.CreateMpnsNativeRegistrationAsync(channelUri, tags);
  5.         break;
  6.     case "windows":
  7.         registrationDescription = await hubClient.CreateWindowsNativeRegistrationAsync(channelUri, tags);
  8.         break;
  9.     case "android":
  10.         registrationDescription = await hubClient.CreateGcmNativeRegistrationAsync(channelUri, tags);
  11.         break;
  12.     case "ios":
  13.         registrationDescription = await hubClient.CreateAppleNativeRegistrationAsync(channelUri, tags);
  14.         break;
  15.     case "kindle":
  16.         registrationDescription = await hubClient.CreateAdmNativeRegistrationAsync(channelUri, tags);
  17.         break;
  18. }

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.

Through ZuMo with tags
  1. List<string> tags = new List<string>();
  2. tags.Add("News:Economics");
  3. tags.Add("News:Sports");
  4.  
  5. await zuMoClient.GetPush().RegisterNativeAsync(channelUri, tags);

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.

NotificationHandler
  1. public class NotificationHandler : INotificationHandler
  2. {
  3.     public Task Register(ApiServices services, HttpRequestContext context, NotificationRegistration registration)
  4.     {
  5.         registration.Tags.Add("SomeTag");
  6.         return Task.FromResult(true);
  7.     }
  8.  
  9.     public Task Unregister(ApiServices services, HttpRequestContext context, string deviceId)
  10.     {
  11.         return Task.FromResult(true);
  12.     }
  13. }

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.

Skydrive Folder

Nos vemos!!!

Debug en Azure Mobile Services para Backend .NET

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.

Start

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.

Publish1 Publish2

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.

Try

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.

Attach

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

Debug

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.

PublishDebug RemoteDebug

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