AndroidBlogDesarrollo Móvil

Descubre la arquitectura recomendada por Google para el desarrollo de tus app

Aprende más sobre el patrón de arquitectura MVVM en el desarrollo de tus aplicaciones Android. 

 El equipo de desarrolladores de Google recomienda este patrón para el desarrollo de nuestras aplicaciones Android.

Introducción

Hola amig@s, en este artículo trataremos de explicar más sobre el patrón de arquitectura MVVM (Model-View-ViewModel). Pero antes de comenzar, ¿qué es un patrón de arquitectura?, pues técnicamente se define como un esquema de organización estructural. O lo que es lo mismo unas pautas y prácticas cuyo objetivo es optimizar, organizar y estandarizar el desarrollo.

MVVM, el elegido por Google para Android

El equipo de desarrolladores de Google recomienda el patrón MVVM (Model-View-ViewModel) para el desarrollo de las aplicaciones en Android, ¿Qué significa esto, todas mis aplicaciones deben de cumplir este patrón?, ¿Y si no uso este patrón, estoy haciéndolo mal? No y no. La utilización de un patrón viene recomendada como buena práctica, pero puede que la lógica de tu aplicación no exija la complejidad que tiene implementar este patrón o lo mismo tienes conocimientos de otros patrones (como puede ser MVP) y prefieres utilizarlo.

Por lo tanto, usar o no este patrón es decisión nuestra. Google simplemente te recomienda a usarlo

A continuación se muestra un diagrama de como los módulos debería de interactuar entre ellos si seguimos este patrón en nuestra app.

En el diagrama observamos que los niveles dependen uno de otros, y divide en un primer bloque las vistas (Activities, Fragments…) que se enlazan directamente con el ViewModel, que es el encargado de enlazar los datos del repositorio con las vistas. Pero vamos a verlo pasa a paso.

La interfaz de usuario.

La interfaz de usuario no es más que lo que usuario ve, las pantallas o fragmentos de ellos con sus componentes como botones, cajas de textos, etc… En nuestras app las vistas hacen referencia a los activities y fragments, y la idea que sugiere el patrón MVVM es asilar toda  lógica de esta capa, la vista será la encarga simplemente de mostrar o recoger la información del usuario.

El objeto ViewModel.

Este objeto es el que se encarga de proporcionar los datos obtenidos del repositorio a la IU correspondiente. En este punto se incluye lógica empresarial del manejo de datos.

 

 

Bien, hagamos un alto en el camino para pararnos en este punto, quizás el más importante, y entenderlo bien. 

Podemos definir en pocas palabras que las funciones del ViewModel son dos, obtener datos del repositorio y proveer a las vistas de dichos datos. ¿Más claro verdad? Pero existe una necesidad para que esta teoría funcione perfectamente, debemos informar a nuestra IU cuando se obtienen datos y cuando surgen cambios en ellos para que estos se actualicen independientemente de que componente de la aplicación realizan cambios. Para cubrir esta necesidad es necesario hacer uso del componente LiveData.

LiveData.

Como dijimos anteriormente el ViewModel está capacitado para obtener los datos de un repositorios y proveerlos a las IU. El papel del componente LiveData no es más que convertir los datos en observables (patrón observer) permitiendo que cualquier componente de la app pueda realizar cambios sobre estos datos y mantenerlos actualizados en todo momento.

Entre muchas características, cabe destacar que LiveData que respeta el ciclo de vida y optimiza el consumo de memoria.

Si ya estás usando, o conoces RxJava y te preguntas si puedes usarlo en vez de LiveData la respuesta es que sí. Es posible usar esta librería en lugar de LiveData, pero deberás de gestionar y administrar correctamente el ciclo de vida de tu aplicación.

Crear un repositorio para obtener datos.

Ahora que tenemos enlazados la UI y el ViewModel toca obtener los datos que van a compartir. Para ello un caso práctico sería consumir una API con Retrofit o similares. En este punto se crearía una interface que realice las peticiones a la API y una clase que hará de repositorio implementado la interfaz anterior. 

Una vez tenemos diseñado nuestro repositorio la forma de conectar este con el ViewModel será creando una instancia del objeto repositorio anterior y haciendo uso de las funciones correspondientes.

¿Algo más claro el concepto de MVVM?

En este artículo se pretende dar una explicación teórica y global del patrón MVVM, una vez comprendido ese concepto estáis list@s para dar el paso a la práctica. Para ello os recomiendo la guía de arquitectura que los amigos de Google comparten en su web.

Arquitectura de app recomendada

Y si lo que queréis es pasar a la acción, no os podéis perder el CodeLab de Google donde te enseñarán a usar el patrón MVVM desde cero con una aplicación de prueba.

CodeLab MVVM con Room

Conclusiones

Recordad, la programación es creativa, esto significa que hay muchas formas de resolver una problema. Implantar un patrón, las recomendaciones de Google o el uso de una librería u otra no son una obligación. Trabajar con una arquitectura MVVM en nuestras app convertirá nuestras app en más confiable, solidas, con un mantenimiento y un fácil uso. 

En mi opinión, empecé a implantar en mis aplicaciones este patrón y una vez superas la curva de aprendizaje noté una gran mejoría a la hora de desarrollar. Limpieza en mi código, fácil de escalar y mantener, mejor rendimiento… Esto no quiere decir que siempre vaya a usar este patrón, pero la experiencia de trabajar con él es gratificante.

¡Os animo a investigar, conocer un poco más sobre él, y valoréis vosotr@s mism@s!

 

Si te ha gustado este Post comparte con tus amigos/as de Facebook y Twitter.

Deja un comentario

Tu email no será publicado, debes de rellenar los campos obligatorios indicados con el *