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 ;)
ليست هناك تعليقات:
إرسال تعليق