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.
No hay comentarios:
Publicar un comentario