El nuevo reto es aprender el patrón MVVM (Modelo Vista, Vista Modelo) y para esto vamos a empezar de cero el lector RSS que habiamos construido antes, aprendiendo y repasando cosas en el camino. Seguro no soy la más experta en esto, pero espero que la sencilla implementación de MVVM que vamos a realizar sirva a principiantes a empezar el camino del desarrollo de aplicaciones más profesionales.
Nota Importante: Si recién estás aprendiendo Windows Phone te recomiendo mirar los tutoriales en video de la Serie Windows Phone y los Hands on Labs creados para la Maratón de Windows Phone en Colombia. Esta serie de post no será tan detallada ya que asumiré que ya se tienen conocimientos previos.
Vamos a empezar por dibujarnos un mapa mental de un escenario típico de una aplicación móvil, detallando un poco más en la parte del dispositivo, la notación es UML (Perdón a los amantes de UML por lo minimalista)
Ahora bien, el principal problema al que nos enfrentamos es que tanto entendemos lo que vemos, y que de toda esa complejidad se derive nuestra necesidad de usar MVVM para mejorar la experiencia de los usuarios en nuestras aplicaciones.
Otra nota importante: Si no entiendes la mayoría de cosas que ves, te recomiendo ver al menos la presentación de Aplicaciones Distribuidas que tiene la teoría correspondiente y el primero de los videos de Programación en Capas que hice alguna vez, ya tiene su tiempo, pero al inicio conceptualmente puede servirte bastante.
Resumiré de forma atrevida el tema, diciendo que, el que no podamos controlar lo que sucede cuando hacemos una invocación a través de una red (internet o local) desde nuestros dispositivos, hace que nos veamos en la necesidad de que nuestras aplicaciones respondan y notifiquen a través de la interfaz de usuario lo que está ocurriendo o minimamente que muestren un mensaje indicando que aun estamos trabajando y debemos esperar, hoy en día eso es minimamente lo que espera un usuario, que tal fácil es de lograr de la forma adecuada lleva a cosas que hay que aprender.
Esta es una necesidad típica que se experimenta hace tiempo en la llamada Web 2.0 que ha creado una nueva tendencia en los usuarios de ser más exigentes con las experiencias que ofrecen las interfaces en todo tipo de aplicaciones, por lo que hoy en día muchos pueden estar familiarizados ya con el concepto puesto que han usado el patrón MVC (Modelo Vista Controlador).
Para empezar entonces debemos tener en cuenta 2 puntos, el primero es que trabajar con MVVM nos crea 3 capas lógicas dentro de una capa que conocemos como "Presentación" en el modelo tradicional de Programación en Capas, el segundo, dependiente de este primer punto, es que en estas capas abandonamos de cierta forma los llamados a métodos que estamos acostumbrados a realizar, ya que invocamos métodos que no tienen un retorno directo, si no que envian notificaciones usando eventos y delegados. ¿Que, qué? Si, eso mismo, de entender estas dos ideas es que se va a tratar esta serie de post, la siguiente imagen es el reflejo de lo que dije, y si miran bien es una de las partes del despliegue que les mostré previamente:
Para quienes les gusta leer en inglés, la imagen pertenece al libro gratuito "Developing an Advanced Windows Phone 7.5 App that Connects to the Cloud" publicado por Microsoft, una fuente increible para desarrolladores con ya conocimientos, si te pierdes allá, aquí te espero de vuelta.
Vamos a empezar resumiendo de manera muy sencilla las responsabilidades de las 3 capas lógicas que éxisten dentro de MVVM y poco a poco en la serie de post iremos entendiendo los detalles de cada una. (A los expertos en MVVM espero no molestarlos igual con mi minimalismo, esto es para principiantes)
Vista: La vista es la responsable de contener todos nuestras interfaces de usuario, en el caso de Windows Phone todos los elementos que contienen el marcado XAML. Aqui nos preocuparemos exclusivamente por lo que ve el usuario (etiquetas, listas, cuadros de mensajes, cajas de texto, etc...) y los elementos con los que interactúa para solicitar acciones a la aplicación (botones, gestos, menus, etc...). Ojo, que no nos preocupamos por el código que se ejecuta cuando el usuario solicita algo, solo por proveer el mecanismo para que el usuario pueda solicitarlo.
En este punto cabe aclarar que cada XAML tiene su Code Behind, la mayoría de desarrolladores .NET estan acostumbrados a usar este código que se genera automáticamente al presionar los controles, para implementar allí lógica de la interfaz, y otros un poco menos experimentados lo usan incluso para procesar lógica de negocio.
Si bien MVVM no implica cero Code Behind, si nos lleva necesariamente a usarlo muchisimo menos, sobre todo cuando los controles que usamos tienen la posibilidad de ser usados por el patrón naturalmente.
Por ejemplo (espero no sea un error de mi parte), el Application Bar de Windows Phone 7.5 no permite enlazarlo a las Vistas Modelos a través de comandos (terminos que detallaremos luego), razón por la cual tenemos que implementar algo de Code Behind si queremos dar un comportamiento apropiado a los llamados asincrónicos desde un botón o menú del Application Bar.
Vista Modelo: Estas clases son las encargadas de notificar a las vistas los datos que deben mostrarse o actualizarse y solicitar al modelo cargar datos desde las fuentes de datos. Sin embargo su principal función será tomar los datos que entrega el modelo y traducirlos en estructuras de datos que las vistas puedan mostrar, es allí donde todo se vuelve mágico, si pensamos correctamente en cuales estructuras crear para nuestra aplicación.
Modelo: Esta clases son las encargadas de acceder a las fuentes de datos bien sean locales (en el dispositivo) o remotas, de ahí que necesitemos entender el primer diagráma que les mostré al inicio del post.
Tener fuentes locales es sencillo, hay cientos de tutoriales que enseñan a hacerlo, sin embargo la tendencia actual de las aplicaciones nos llevan a tener aplicaciones conectadas a la nube, y bien alojados en un servidor o hosting tradicional, y este esquema implica tener una aplicación desplegada y disponible para consultar y modificar los datos centrales. Qué tan escalable sea tu aplicación ante un crecimiento inesperado, dependerá mucho más de que tanto hiciste ahí, en tu backend.
Además es importante considerar, que los llamados que hace el modelo a servicios remotos, deben ser realizados en forma asincrónica, y que hay comportamientos de las interfaces que pueden requerir que se desarrollen servicios que despachen a los dispositivos la cantidad de datos apropiada y de acuerdo a las solicitudes de los usuarios, puesto que debemos considerar que muchos de ellos usan las aplicaciones a través de planes de datos con cobro por bytes, cuantos bytes consumen desde nuestroa aplicación es importante, si queremos no queremos quejas al respecto por parte de los usuarios de nuestras aplicaciones.
Bien, por este post, de mi parte es todo.
Les comparto un post con una explicación muy agradable del patrón MVVM y para quienes quieran ir un poco más rápido que mis post, les recomiendo empezar por este video de Josue Yeray, tiene su tiempo pero seguramente despues de verlo varias veces con atención encontrarán que en realidad no es tan dificil.
Nos vemos la próxima
Sorey ;)
3 comentarios:
A seguir tus tutoriales Sorey, excelentes como siempre :)
Respecto al Code Behind en MVVM, es un tema de nunca acabar. En mi experiencia (poca pero válida creo), una de las ventajas más grandes de MVVM ha sido la reutilización de componentes y separación de responsabilidades.
No obstante también me he dado varias veces contra la pared por ser "un buen chico" tratando de evitar al Code Behind. El problema es que cuando no hay otra opción que implementarlo, surge la migraña de estar buscando cierto código en una clase u otra (en el CB y VM).
Al final me he empezado a hacer amigo de MVVM Light que me ha facilitado mucho la vida con caracs como Messenger, EventToCommand, RelayCommand, etc.
BTW con el AppBar, efectivamente no es posible hacer binding, espero que para WP8 sea un DependencyObject (o que no lo sea pero que aparente serlo ante nos.) porque sin lugar a dudas es ¡otro dolor de cabeza!. Al menos Prism nos hace el favor de crear un behavior para eso.
Un gran saludo mi estimada Sorey :)
Gracias Jimmy, bueno no creo que tu necesites mucho de estos post, pero será lindo tenerte como compañia por para aquello de que aprendimos hace poco :P.
Además de que me encanta la buena vibra de tus comentarios.
Con respecto a usar un MVVM Light te cuento que en efecto lo estuve mirando, pero bueno tu ya sabes que algunos temas de .NET abstrae a los desarrolladores de mucha carpinteria y por eso muchos terminan por no entender lo que hacen y hacerlo de forma mecánica.
Cuando vi a algunos devs con ya un par de años de experiencia trastabillando en las aplicaciones de Windows 8, es más, en las simples plantillas generadas por Visual Studio, en donde si o si debes entender MVVM, fué que pensé en retomar la vieja promesa de enseñar MVVM.
Windows Phone representa un poco de menos retos que Windows 8 con respecto al manejo de espacios y estilos para XAML, así que aprender la base desde aquí me pareció divertido, además de que un proyecto de estos tarda mucho menos en ser terminado y aceptado en la tienda.
Un abrazo para tí, mi estimado Jimmy :)
Saludos Sorey.
Estoy leyendo tu post desde España y me está resultando bastante interesante.
Gracias por compartir tus conocimientos y felicidades por el blog.
Publicar un comentario