Taller MVVM Imagine Camp Medellín

El día de ayer estuve participando como Speaker en el Imagine Camp Medellín, enseñando a los estudiantes que se preparan para participar en el Imagine Cup, como aplicar MVVM en aplicaciones portables. El reto era lograr que comprendieran todos los conceptos, y aunque de entenderlo a hacerlo hay todavía camino, seguramente que es más fácil cuando entiendes a que te enfrentas.

Quería compartirles la presentación cuyo nivel es intermedio. El código fuente pueden encontrarlo en el repositorio de Github de Avanet y estudiarlo. Además dí una charla sobre UX para Windows Phone y Windows 8, así que espero que todo les resulte de utilidad. :)

Modelos y arquitectura de software

Hola

Ayer algunos de mis ex-alumnos me pidieron darles una entrevista para una de sus tareas de la universidad y me pareció un bonito ejercicio. Por ahí de los nervios no respondí a una pregunta y dije algo como genérico (me disculparán), pero en términos generales para quienes esten empezando con ingeniería de software o arquitectura de software puede que les sea de ayuda en algún momento, también a los que hacen software o tienen cargos en la industria de software y no tienen la más remota idea de en que consisten ciertas cosas.

Por favor en sus mentes cambien la palabra "nomenclatura" por "notación" :( #LoSiento

No está editado pero ojalá les sirva :)

PD: No apto para expertos.
 

Startups, Cross-platform y Azure Mobile Services

Actualización importante 2014/04/05: Hace unos días iniciando la creación de la versión Xamarin en Android y iOS con un amigo, el encontró que Autofac no era compatible con la version Xamarin de iOS hasta el momento. Al revisar el codigo nos encontramos que el contenedor de dependencias estaba acomplado al codigo portable, para solucionar este problema hicimos un servicio con su propia interfaz que sepa recuperar instancias desde el contenedor de dependencias ubicado a nivel de la UI, lo cual solucionó el problema y además ahora nos permite incluso tener el contenedor de dependencias recomendado en cada plataforma sin alterar el código portable.

Hace unos días empecé un proyecto con el ánimo de aprovechar el tiempo libre y aplicar todo lo aprendido en nuestra anterior y detenida serie de post de MVVM Avanzado.

Aprovechando todo el ánimo que tenía decidi iniciar varios proyectos y uno de ellos es el que vengo a comentarles hoy. Esta noche cumplo exactamente 15 dias desde que llegó el correo donde nos proponian crear una app para el mundial. Mi amigo @HernanDGR y yo empezamos la app e iniciamos con la BETA a los 10 días, y hoy en el día 15 estamos listos para nuestro primer release, con feedback de varios BETA Testers.

Nuestra app, un proyecto simple de Trivias de Futbol llamado Trivium Cup con una mecánica de juego basada en jerga del fútbol. Pues bien, no vengo a contarles de la app especificamente si no de que usamos y como podría esa manera de trabajar ayudarlos con proyectos rapidos o con sus Startups.

La primera herramienta que nos ayudo a tener un backend robusto y seguro en 10 días es Azure Mobile Services, servicio que provee Microsoft en Azure y que nos ayuda en temas de base de datos, almacenamiento, tareas en background, validación de identidad con los proveedores más comunes (Google, Facebook, Twitter, Live) y notificaciones push.

Lo mejor de Azure Mobile Services es que a hoy está disponible para ser usado en aplicaciones Windows Store, Windows Phone, iOS, Android, HTML, Xamarin.iOS, Xamarin.Android, Sencha y PhoneGap. Para añadir, lo que tenemos con estos es servicios es la seguridad de que tendremos datos protegidos y una infraestructura sólida para nuestro backend.

Por supuesto cuando pensamos en usar servicios en la nube es importante que consideremos el hecho de que debemos mantener un flujo constante de ingresos por lo que nuestra app ya estaría condicionada a ser por publicidad (si tienen un escenario para tener suficiente) y/o con In App Purchases que garanticen el soporte la infraestructura en el tiempo. Así que es importante enterarse y entender el costo, así que no olviden leer la letra pequeña.

A hoy, esta es la tabla de precios de Azure Mobile Services.

Los servicios gratis son a nivel de suscripción téngalo presente. Si tomamos planes anuales o semestrales probablemente bajemos los costos pero tendriamos que hacer un pago por adelantado, asi que según nuestro modelo de startup quizá nos resulte mejor ir viendo que pasa con nuestra app en el camino, después de todo si comparamos 25 USD versus todos los servicios que ofrece la plataforma, lo que nos corresponde es sacarle el mejor provecho posible.

Actualización 19 de Marzo de 2014: En los recientes días continue mejorando el código, ya que la mejora es pequeña no actualizaré el post y solo haré mención. De los servicios a nivel de la UI solo deje el timer, los demás los pase a la librería propia del teléfono y los generalizé para que me sirvan a cualquier otra app. También en esta librería cree una carpeta de "Converters" para colocar ahí los de uso común en mis apps y los de uso específico los deje a nivel de la UI.

Recuerden que todos los tutoriales necesarios para empezar con esto están disponibles en el sitio de Azure Mobile Services. De hecho para que vean lo sencillo que es les dejo un insert, con el fin de que observen como es tan sencillo como usar un ORM.

Pues bien, aunque Azure Mobile Services está muy bien para empezar, si sentimos algo de miedo de acoplar nuestra solución a esto, la solución es bastante simple. Hay que programar bien y tener buenas estrategias crossplatform. Estas estrategias no solo aislan la complejidad de reutilizar codigo en todas las plataformas, tambien nos ayuda cuando tenemos que aislar nuestro codigo de alguna implementación en particular sin que el resto de la aplicación dependa de ello.

Es por esa razón que retomaremos en este post el tema del crossplatform mirando como resolvimos el tema en Trivium Cup, que si bien a hoy está solo para Windows Phone, el código está listo para ser usado en Windows 8 y tambien en Xamarin con iOS y Android, que es basicamente lo que veniamos hacer en nuestra serie anteior.

Empezaré por mostrarles la radiografía del proyecto a este momento, puesto que desde ya hace varios días no tiene cambios importantes. Como verán si siguen mi blog, tiene una estructura similar a la que veniamos construyendo en la serie de MVVM Avanzado, pero definitivamente más afinada y diria definitiva, así que voy a explicarles cada uno de los paquetes y carpetas y sus responsabilidades.

Infraestructure.Common es una libreria portable a la que le corresponde a todo el codigo que puede ser utilizado no solo por esta app si no por todas las apps que construyamos bajo este esquema. De allí que lo principal sean las clases reutilizables RelayCommand y Bindable Base, y todo lo generico a usar como estructuras de validación de los formularios y los servicios para consumir datos.

Infraestructure.Phone es una librería de plataforma (Windows Phone en este caso) que contiene todas las clases de servicios que necesitan clases específicas que no se encuentran en clases portables. Yo no soy muy amante de los condicionales de compilación, prefiero dejarle la tarea de resolver la implementación de un servicio específico a el ViewModelLocator como vimos en la serie de MVVM Avanzado o en el Hangout de estrategias cross platform. Sin embargo esto es una decisión propia, como veran en la serie o el hangout pueden tener archivos compartidos y condicionales de compilación para hacer esto mismo, de mi parte prefiero código más ordenado y fácil de leer.

Espero que se hayan preguntado por que las interfaces de estos servicios estan en otro proyecto, eso es sencillo, las interfaces son lo que las Vistas Modelo necesitan conocer para desacoplarse de las implementaciones especificas que deban hacerse en cada plataforma. Sin embargo la idea de este proyecto Infraestructure.Phone es que estas clases puedan reusarse en la creación de otras apps.

Trivias.Models tiene el conjunto de clases que nos ayudan a serializar las tablas y vistas de Azure Mobile Services.

Las clases son simples POCO con un atributo de serialización 

La razón por la que las pusimos en un assembly separado fue más algo práctico, ya que tenemos otra app que no tiene toda esta arquitectura y a través de la cual administramos los datos de las tablas maestras, si no tienen este caso o si prefieren administrar los datos por SQL Management Studio tambien es posible hacerlo.

Trivias.Logic es la librería portable que contiene lógica propia de nuestra aplicación. Como ven justo en este punto solo hay un servicio, a Azure Mobile Services, es esta clase la que puede ser reemplazada en implementación por otra que consuma servicios Json por ejemplo.

Además en esta librería tenemos los contratos que usan Vistas Modelos y Modelos en sus firmas (ya que recuerden si quieren poner sus modelos aquí es una opción valida) y tambien tenemos el ViewModelHelper cuya responsabilidad es poblar las Vistas Modelos con los datos de los Modelos que retorna el servicios de Azure.

También ubicamos en esta librería todos los recursos que requieran localización y así nos evitamos un dolor de cabeza de repetirlos todos en cada proyecto :)

Trivias.WorldCups es la app Windows Phone propiamente, la cual tiene recursos propios de front end tales como Datos de ejemplo, Paginas, Convertidores, Recursos Localizados, Controles de usuario y ademas los Templates de XAML agrupados en Recursos. 

Si observan con cuidado verán que tenemos una clase de Infraestructura que es nuestro punto de resolución de dependencias, el ViewModelLocator, que insisto si aún no entienden no dejen de ver el Hangout que les publique hace unos dias, y además notarán que tengo algunos servicios a nivel de aplicación, esto se debió a que en las librerías no tenia acceso a algunas cosas o incluso a temas de distribución de código para tener más cosas reusables en las librerías y las particulares de la app en el nivel correspondiente.

Por favor, no sigan el consejo de que para sacar algo pronto hay que hacer código mal hecho, una vez interiorizado este tema de distribuir código, son muchos más los beneficios incluso rinde mucho más construir la primera versión.

Por último recuerden que siempre hay cosas que mejorar así que si encuentran alguna no duden en decirmelo, que yo también aprendo cada día.

Saludos y hasta la próxima.

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.