Estrategias para desarrollo crossplatform en Windows Phone 8 y Windows 8

El día de hoy fuí invitada a dar un #DevHangout en DevAcademy.la sobre Windows Phone 8 y Windows 8. Me propuse a mi misma procurar comunicar todos esos temas que necesitamos que los desarrolladores de estas tecnologías empiecen a aplicar en sus apps y bueno el resultado fue muy bonito.

La charla es un compendio principalmente de buenas prácticas enfocadas al uso de MVVM partiendo de prácticas básicas hasta prácticas avanzadas sugeridas. 

Un consejo adicional que les puedo dejar, es que si no entienden mucho que son las vistas modelo o como definirlas se vean el post que publique antes sobre tema, explicandolo detalladamente.

Espero que les sirva mucho y que los anime a profundizar en los temas que les haga falta aprender, recuerden igual que tenemos un proyecto en construcción aquí en el blog donde justamente hemos estado aprendiendo todas las cosas que menciono en la charla.

Les comparto además las diapositivas de la presentación

 

Estrategias para desarrollo crossplatform en Windows Phone 8 y Windows 8 from Sorey Garcia

Creando Test Unitarios para consumo de datos usando HttpClient

La serie se ha visto detenida debido a que se desarrolla en tiempo libre, en especial los fines de semana y lastimosamente los fines de semana los servidores de Congreso Visible estan siendo sacados del aire.

Uno de los escenarios más comunes en las aplicaciones móviles es realizar peticiones para consumir servicios web, y el proyecto de nuestra serie no es la excepción. Hasta el momento solo hemos creado algunos pocos Test Unitarios para las Vistas Modelos, sin embargo la cantidad de servicios que hemos creado, ameritan muchos Test Unitarios.

En este post nos enfrentaremos a unos test particulares, y son los test de aquellos servicios que usan la clase HttpClient. Pues bien, buscando por ahí encontre un par de alternativas, ambas se ven bien sin embargo un poco más elaboradas. Les comparto los post

• Unit testing classes with HttpClient dependence + using Autofixture
• TaskCompletionSource in real life 

Al ver ambos post opté por mi propia implementación mucho más sencilla, la forma de resolver el problema es básica, si encapsulamos en una clase el llamado a HttpClient y a dicha clase le creamos una interfaz, esta podrá ser "Mockeada" por Moq y resolveremos fácilmente el problema.

Para esto nuestros aliados seán Moq y Autofixture, este último lo presenté en una actualización del primer post de refinamiento de arquitectura ya que es de mucha utilidad para crear datos dummy. Empezaré por decir que cree el servicio e interfaz en el proyecto de Infraestructura por que dicho proyecto pretende justamente agrupar el código que podría ser reusado en otros proyectos.

La implementación de la interfaz es bastante simple

Y la implementación del servicio también

Luego de esto fue necesario cambiar la implementación del servicio JsonService particular para el proyecto, con el fin de que usara la nueva dependencia que claramente fue necesario registrar en el ViewModelLocator como vimos en post anteriores.

Hecho esto lo que resta es poco, primero configuramos las fuentes de donde nuestro servicio obtendrá algunos datos es decir el TestDataHelper en el cual usamos Fixture

Observen con especial cuidado las partes donde se usa Autofixture para crear los datos. Para simular la respuesta de un servicio Json, lo que hice fue crear instancias de las clases Modelo con Autofixture y luego serializarla. Esta porción de código seguro se puede generalizar más para serializar cualquier tipo de objeto.

Luego ensamblamos nuestros test usando Moq.

En primer lugar inicializamos la instancia de JsonService que estamos probando tomando de una clase generíca la instancia de los servicios "Moqueados". Luego usando Moq, configuramos la respuesta que darán cada uno de los llamados que usa el método que vamos a probar y por último invocamos el método y analizamos la respuesta que espera nuestro test.

Observen bien las diferentes formas de llamar un método sincronico y un método asincrónico usando Moq, tenemos como les he insistido antes, que conocer bastante bien lo que vamos a probar.

Si les extraña la clase MocksContainer, simplemente decidi tener un punto central donde inicializar todos los servicios, para que estén disponibles para todas las clases de test de mi proyecto de pruebas, colocandolas estáticas y publicas.

Refinando la arquitectura de nuestro proyecto - Usando MVVM Light (2/2)

Bien empecemos por reconocer la parte que de nuestro codigo que reemplazará MVVM Light, esa parte es el BindableBase y el DelegateCommand, mi opinión, que ampliaré al final de este post es que no es tanto codigo ni tan dificil para que sea tan dramático el desviarse a usar una libreria de tercero sin embargo cada quien sopese sus prioridades, MVVM Light les evitará tener que crear estas clases.

Otro par de caracteristicas restables de MVVM Light es que tiene su contenedor de dependencias, llamado SimpleIoC el cual ya veremos como reemplazar por Autofac que es mucho más recomendado. Por otro lado uno de los patrones interesantes cuando se trabaja con MVVM es el patrón Messenger, pues bien MVVM Light tiene una implementación ya de este patrón lista para ser usada, y también una implementación de EventToCommand, lo cual sirve para enlazarlos a comandos (ICommand) en aquellos controles y/o eventos que no proveen en mecanismo en XAML para hacerlo directamente.

Para empezar a utilizar MVVM Light es necesario instalarlo en nuestra máquina, descargando la última versión estable desde alguno de los repositorios oficiales, como es https://mvvmlight.codeplex.com

Luego de esto, reiniciamos el Visual Studio y podemos proceder a agregar la referencia a los proyectos desde Nuget. En proyectos como el nuestro debemos poner un tanto de atención, ya que el que debemos instalar es el MVVM Light PCL

Ahora bien, para reemplazar SimpleIoC por Autofac que ya lo tenemos en nuestro proyecto debemos instalar un extra para Autofac que nos permitirá cambiar el contenedor de dependencias en donde sea que MVVM Light lo use

Esto trae un pequeño inconveniente y es que se agrea  la clase ServiceLocator de Microsoft Patterns and Practices, por lo que para no tener confusiones y siguiendo el estandar propuesto por ellos, nuestro ServiceLocator anterior pasará a llamarse ViewModelLocator y tendremos que cambiarla en los recursos generales de la aplicación.

En ViewModelLocator procedemos a cambio el contenedor de dependencias, les dejo en comentarios lo que tendrian que dejar si deciden usar SimpleIoC

Aunque no es necesario cambiar más código en ViewModelLocator les comparto la manera como pueden recuperar instancias usando el ServiceLocator que fue añadido a nuestro proyecto

Ahora continuemos con los cambios que generá haber removido nuestro DelegateCommand. La clase en MVVM Light se llama RelayCommand

Para finalizar debemos hacer los cambios de haber en BindableBase para no duplicar corportamiento con MVVM Light. Con el animo de no dañar toda nuestra implementación decidi conservar BindableBase y poner una herencia a la clase base que propone MVVM Light la cual es ViewModelBase y remover todo el codigo doble, conservando solo las caracteristica propias de la arquitectura propuesta en este ejercicio.

Por lo demás nuestras Vista Modelo se ven impactadas debido a que MVVM Light hace los Set de las propiedades diferente y tenemos que cambiarlas todas.

Esos serían todos los cambios, como ven nada de otro mundo. La reflexión es que si se usa MVVM Light sin saber todo lo que hemos aprendido en esta serie, pues basicamente no se comprenderá el código que se escribe.

La verdad es que usar MVVM Light es algo que no va mi forma de trabajar, soy alguien que prefiere tener el control de su código, sin embargo entiendo que es un tema personal y que cuando existen buenas librerías pues está bien si alguien decide no empezar siempre de ceros. 

Yo pienso que es una cuestion de equilibrio, de plantearse si uno quiere depender de un tercero o no para su software, en algo tan básico como esto, es tan simple como esto que es tan simple como tener a mano nuestro propio proyecto de infraestructura. Es por esta razón que verán en el repositorio como deje un branch con el cambio a MVVM Light pero al menos en un principio espero quedarme con mi propia implementación que se me hace suficiente por ahora, lo que hice por si más adelante quisiera pasarme a MVVM Light nuevamente en el branch principal, fue renombrar mi DelegateCommand por RelayCommand, y cambiar el SetProperty de mi BindableBase para que tenga una firma similar a la de las clases de MVVM Light.

Refinando la arquitectura de nuestro proyecto - Usando Autofac y Moq (1/2)

Después de algunos días retomo la serie de Congreso Visible, y no precisamente por que haya estado detenida en su totalidad, más bien estuve en el proceso de resolver algunos escenarios para el tema de acceso local a la base de datos, lo cual al momento es un post pendiente, pero que no quiero continuar sin antes aplicar al proyecto todas las mejoras que tengo planeadas a nivel de arquitectura, ya que espero llegar un día a una que pueda ser seguida como ejemplo por ustedes y además ofrecer alternativas.

Diré que el ejercicio hasta el momento me dejo demasiados aprendizajes, pero sobre todo una alta comprensión de lo que suponen cada uno de los escenarios que vimos, ya que estuvo complejo resolver de forma manual cada uno de los retos:

• Tener codigo compartido por todas las plataformas
• Tener codigo especifico para cada plataforma sin salirse del esquema general.
• Aplicar pruebas unitarias a los dos escenarios anteriores bajo el mismo esquema.
• Disminuir el acomplamiento entre las vistas y las vista modelo. Además de usar la menor cantidad de CodeBehind posible.

Todo esto fue una grata experiencia ya que evitamos al máximo usar librerías de terceros, lo que nos hizo tener un mayor entendimiento de la solución dada a cada escenario, sin embargo hoy después de ese proceso considero que podemos con mayor conciencia y aprovechar las ventajas que nos dan al crear código más limpio. En el repositorio quiero conservar los tags tanto a los intentos de no usar librerias como al cambio que realizaré a partir de este momento.

Al empezar este post pensé que podría mostrarles paso a paso el cambio, pero fue tan grande que ahora solo me queda enumerarles los cambios y compartirles los modelos actualizados y el código.

En este primer refinamiento vamos a usar las librerías Autofac para Injección de Dependencias y Moq para Mocking o creación de objetos dummy para los Test Unitarios.

Recuerden que cualquiera de estas librerías se instala en el proyecto que sea necesario a través del menú contextual Manage Nuget Package en la cabecera de sus proyectos.

Se consulta la librería que se desea añadir en las librerías en línea y se da Instalar

Ahora bien veamos cada uno de los cambios de este primer paso. Los cambios más evidentes se resumen en 3:

La eliminación de los servicios fake

Esto fue de los temas más interesantes debido a que comparar los test implementados con Moq versus los Test implementados a mano con Callbacks y Variables adicionales, se nota como el trabajo con Moq hace los Test menos mecanicos y más pensandos, es decir de verdad se necesita saber lo que se está haciendo para ensamblar los Mocks usando Moq

Espero que esten notando claramente la diferencia con la forma de crear Mocks, antes, si nó aquí les comparto una imagen del post en que iniciamos con TDD

De hecho si analizamos detenidamente en una línea haciamos la inyección de dependencias de la instancia de un Fake. Ahora vemos como hacemos la instancia usando Mocks. ¿Y la inyección de dependencias? Pues bien eso es el siguiente punto, por ahora veamos como se ven nuestros Test con Moq.

Si me permiten decirles, bastante bonitos, si desean ver los anteriores dirijanse al post en que iniciamos el montaje de los Test y verán la gran diferencia.

Actualización 10 de Febrero de 2013: Algo muy útil que encontré como compañero de Moq fue una librería adicional llamada Autofixture la cual nos permite añadir datos Fake para las pruebas. Si observa el tercer test de la tabla anterior en el tengo un DataTestHelper en el que uso Autofixture para generar datos y espero que les sea útil conocerlo. Para instalarlo en conjunto con Moq deben seleccionar el paquete correcto.

Luego de esto estarán listos para genera su Helper de generacion de datos Dummy, aquí un pequeño ejemplo, mejorado por mi amigo @HernanDgr

Cambio del manejo manual de dependencias

En este punto se implementó Autofac como contenedor de dependencias. Me hubiese gustado usar Unity, lastimosamente aun no tiene soporte para clases portables como si lo tiene Autofac.

Bien, Al mirar los test vemos como la inyección de dependencias cambió, ahora en vez de registrar una nueva instancia de un Fake, registramos el objeto que Moq crea.

Quisiera resaltar la última línea de la inicialización ya que esta es la manera como decidi resolver el acoplamiento entre las VistasModelo y el contenedor. Siendo que todas las Vistas Modelos heredan de la misma clase padre, dicha clase ahora tiene una referencia al contenedor haciendo que todas tengan la posibilidad de resolver correctamente las dependencias sin saber directamente de donde ellas provienen.

Otra cosa importante es ver como quedó en la aplicación implementado, cambiaron pocas cosas pero son importantes. Antes de mirar el cambio les mostraré que separé el ServiceLocator de las clases de Servicios creadas por ser propias de la plataforma.

En el futuro veremos cuan importante es tener en mente la estructura del proyecto, incluso el hecho de que por ejemplo estos servicios y el Service Locator compartan namespaces con los servicios que estan fuera de las clases. En Windows 8 tendremos que crear la mistra estructura Adicionar como Link el Service Locator y re implementar los servicios propios de la plataforma. Si en un futuro parte de estos servicios se vuelve común, será tan sencillo como implementarlo y pasarlo al assembly de servicios compartidos.

Por lo pronto conocer la reubicación de estas clases es importante debido a que para inicializar las dependencias en la app, es el ServiceLocator quien además de registrar las clases concretas, inicializa el contenedor de Autofac y observen la diferencia con como registramos las dependencias en los Test

Aquí vemos como en vez de registrar una instancia de Moq, registramos las clases concretas. Ahora bien la clase de infraestructura BindableBase quedó igual que antes responsable del contenedor pero esta vez del contenedor de Autofac.

El contenedor de Autofac se usa por las VistaModelo en el constructor, cuando se inicializan los servicios que dicha VistaModelo necesite

Es necesario decir que con este esquema los servicios podemos inicializarlos en el constructor o particularmente en los métodos que los usemos, finalmente siempre se recuperan del mismo contenedor de dependencias y se inicializarán solo una vez ya que solo existe una instancia de la Vista Modelo en el Service Locator. ¿Bonito eh? ¡Muy bonito!

Refactorización general

Se realizaron muchos cambios en nombres de clases, eliminación de interfaces innecesarias y reacomodación de clases en los assemblies. Hoy definitivamente valio la pena la pausa, aprender y pensar en mejores formas de hacer las cosas. Finalmente todos los cambios y el mismo proceso de ajustar el código ha quedado reflejado en el repositorio, un ejercicio interesante puede ser bajar los dos tags hasta el momento y observar las diferencias.

Por el momento en el solo modelo de paquetes, las diferencias son obvias.

Para finalizar quise dejar una reflexión sobre el por que intentar realizar tanto trabajo manual en los 9 post anteriores para no dejar demasiado texto al inicio, sin embargo como siempre me gusta compartirles mis posiciones.

Básicamente lo que más me inquieta de algunos de los devs Windows Phone que conozco son dos temas: Uno, no usan en absoluto ninguna buena práctica de MVVM y tienen vacios enormes a nivel de Programación Orientada a Objetos, o dos usan todas las buenas prácticas a través de librerías, sin entender lo que hacen, lo cual no redunda más que en lo mismo de los primeros, una falencia enorme de conceptos. 

Es importante entender que esto no es una crítica, es un llamado de atención. Como desarrolladores cada día deberiamos preocuparnos por mejorar nuestras habilidades para crear mejor código, todos aprendemos cada día, y deberíamos querer mejorar y avanzar, en la ruta correcta.

Conociendo el ecosistema de Windows Phone 8 y Windows 8

El día de hoy realizé una charla de contextualización para SUMA Conectivo de Mar de Plata Argentina, hablando de las plataformas móviles de Microsoft vistas como ecosistema. El hangout ha quedado publicado para que puedas reproducirlo, y compartirlo

A continuación comparto las diapositivas que espero les resulten útiles para refrescarse un poco.

Conociendo el ecosistema de Windows Phone 8 y Windows 8 from Sorey Garcia