Advertisement
  1. Code
  2. Android SDK

Introducción a Componentes de Arquitectura de Android

Scroll to top
Read Time: 13 min
This post is part of a series called Android Architecture Components.
Android Architecture Components: Lifecycle and LiveModel

Spanish (Español) translation by Leareny Guerrero (you can also view the original English article)

Android fue introducido al mundo en 2005, y durante esos 12 años de experiencia la plataforma ha alcanzado un éxito increíble, convirtiéndose en el OS móvil más instalado. Durante ese tiempo, 14 diferentes versiones de sistema operativo han sido lanzadas, con Android siempre volviéndose más maduro. Sin embargo, se ha seguido ignorando un área muy importante de la plataforma: un patrón de arquitectura estándar, capaz de manejar las peculiaridades de la plataforma y lo suficientemente sencillo como para ser entendido y adoptado por el desarrollador promedio.

Más vale tarde que nunca. En el último Google I/O, el equipo de Android decidió por fin abordar este problema y responder a los comentarios de los desarrolladores de todo el mundo, anunciando una recomendación oficial para una arquitectura de aplicaciones Android y proporcionando los bloques de construcción para implementarla: los nuevos componentes de arquitectura. Y lo que es mejor, lo han conseguido sin comprometer la apertura del sistema que todos conocemos y amamos.

Architecture ComponentsArchitecture ComponentsArchitecture Components

En este tutorial, exploraremos la arquitectura estandarizada propuesta por el equipo de Android en Google I/O y veremos los principales elementos de los nuevos Componentes de Arquitectura: Lifecycle, ViewModel, LifeData y Room. No prestaremos demasiada atención al código, sino que nos centraremos en el concepto y la lógica que hay detrás de estos temas. También echaremos un vistazo a algunos fragmentos sencillos, todos ellos escritos usando Kotlin, un lenguaje increíble que ahora es soportado oficialmente por Android.

1. ¿Qué le faltaba a Android?

Si estás empezando tu andadura como desarrollador, es posible que no sepas exactamente de qué estoy hablando. Después de todo, la arquitectura de aplicaciones puede ser un tema oscuro al principio. Pero créeme, ¡pronto aprenderás su importancia! A medida que una aplicación crece y se vuelve más compleja, su arquitectura será cada vez más importante. Puede, literalmente, hacer que tu trabajo sea una bendición o un infierno.

Arquitectura de la aplicación

A grandes rasgos, la arquitectura de una aplicación es un plan coherente que debe realizarse antes de que comience el proceso de desarrollo. Este plan proporciona un mapa de cómo los diferentes componentes de la aplicación deben ser organizados y vinculados entre sí. Presenta directrices que deben seguirse durante el proceso de desarrollo y obliga a algunos sacrificios (generalmente relacionados con más clases y el paquete de desarrollo) que al final le ayudarán a construir una aplicación bien escrita que es más comprobable, ampliable y mantenible.

La arquitectura de aplicaciones de software es el proceso de definir una solución estructurada que cumpla con todos los requisitos técnicos y operativos, al tiempo que optimiza los atributos de calidad comunes, como el rendimiento, la seguridad y la capacidad de gestión. Implica una serie de decisiones basadas en una amplia gama de factores, y cada una de estas decisiones puede tener un impacto considerable en la calidad, el rendimiento, la capacidad de mantenimiento y el éxito general de la aplicación.
- Guía de diseño y arquitectura de software de Microsoft

Una buena arquitectura tiene en cuenta muchos factores, especialmente las características y los límites del sistema. Existen muchas soluciones arquitectónicas diferentes, todas ellas con pros y contras. Sin embargo, algunos conceptos clave son comunes entre todas las visiones.

Viejos errores

Hasta el último Google I/O, el sistema Android no recomendaba ninguna arquitectura específica para el desarrollo de aplicaciones. Eso significa que eras completamente libre de adoptar cualquier modelo que existiera: MVP, MVC, MVPP, o incluso ningún patrón. Además, el framework de Android ni siquiera proporcionaba soluciones nativas para los problemas creados por el propio sistema, concretamente el ciclo de vida de los componentes.

Great news at the Google IO 2017Great news at the Google IO 2017Great news at the Google IO 2017

Así, si querías adoptar un patrón Model View Presenter en tu aplicación, tenías que idear tu propia solución desde cero, escribiendo mucho código boilerplate, o adoptar una librería sin soporte oficial. Y esa ausencia de estándares creaba un montón de aplicaciones mal escritas, con bases de código difíciles de mantener y probar.

Como he dicho, esta situación ha sido criticada durante años. De hecho, hace poco escribí sobre este problema y cómo solucionarlo en mi serie Cómo adoptar Model View Presenter en Android. Pero lo importante es que después de 12 largos años, el equipo de Android finalmente decidió escuchar nuestras quejas y ayudarnos con este problema.

2. Arquitectura de Android

La nueva guía de arquitectura de Android define algunos principios clave a los que debe ajustarse una buena aplicación de Android y también propone un camino seguro para que el desarrollador cree una buena aplicación. Sin embargo, la guía afirma explícitamente que el camino presentado no es obligatorio y que, en última instancia, la decisión es personal; es el desarrollador quien debe decidir qué tipo de arquitectura adoptar.

Según la guía, una buena aplicación Android debe proporcionar una sólida separación de preocupaciones y manejar la UI desde un modelo. Cualquier código que no maneje una interfaz de usuario o una interacción con el sistema operativo no debe estar en una Actividad o Fragmento, porque mantenerlos tan limpios como sea posible te permitirá evitar muchos problemas relacionados con el ciclo de vida. Después de todo, el sistema puede destruir Actividades o Fragmentos en cualquier momento. Además, los datos deben ser manejados por modelos que están aislados de la UI, y por lo tanto de los problemas del ciclo de vida.

La nueva arquitectura recomendada

La arquitectura que Android está recomendando no puede ser fácilmente etiquetada entre los patrones estándar que conocemos. Parece un patrón Modelo-Vista-Controlador, pero está tan estrechamente ligado a la arquitectura del sistema que es difícil etiquetar cada elemento utilizando las convenciones conocidas. Sin embargo, esto no es relevante, ya que lo importante es que se apoya en los nuevos Componentes de Arquitectura para crear una separación de preocupaciones, con una excelente testabilidad y mantenibilidad. Y lo que es mejor, es fácil de implementar.

Para entender lo que propone el equipo de Android, tenemos que conocer todos los elementos de los Componentes de Arquitectura, ya que son los que harán el trabajo pesado por nosotros. Hay cuatro componentes, cada uno con una función específica: Room, ViewModel, LiveData y Lifecycle. Todas esas partes tienen sus propias responsabilidades, y trabajan juntas para crear una arquitectura sólida. Echemos un vistazo a un diagrama simplificado de la arquitectura propuesta para entenderla mejor.

Android ArchitectureAndroid ArchitectureAndroid Architecture

Como puedes ver, tenemos tres elementos principales, cada uno con su responsabilidad.

  1. La Activity y el Fragment representan la capa de la View, que no se ocupa de la lógica de negocio y las operaciones complejas. Solo configura la vista, maneja la interacción con el usuario y, lo más importante, observa y expone los elementos LiveData tomados del ViewModel.
  2. El ViewModel observa automáticamente el estado del Lifecycle de la vista, manteniendo la consistencia durante los cambios de configuración y otros eventos del ciclo de vida de Android. También es demandado por la vista para obtener datos del Repository, que se proporciona como LiveData observable. Es importante entender que el ViewModel nunca hace referencia a la Vista directamente y que las actualizaciones de los datos son siempre realizadas por la entidad LiveData.
  3. El Repository no es un componente especial de Android. Es una clase simple, sin ninguna implementación particular, que se encarga de obtener datos de todas las fuentes disponibles, desde una base de datos hasta servicios web. Maneja todos estos datos, generalmente transformándolos en LiveData observables y poniéndolos a disposición del ViewModel.
  4. La base de datos Room es una biblioteca de mapeo SQLite que facilita el proceso de tratar con una base de datos. Escribe automáticamente una tonelada de boilerplate, comprueba los errores en tiempo de compilación, y lo mejor de todo, puede devolver directamente las consultas con LiveData observables.

Seguro que te has dado cuenta de que hemos hablado mucho de observables. El patrón observable es una de las bases del elemento LiveData y de los componentes conscientes del Lifecycle. Este patrón permite que un objeto notifique a una lista de observadores sobre cualquier cambio en su estado o datos. Así, cuando una Actividad observa una entidad LiveData, recibirá actualizaciones cuando esos datos sufran algún tipo de modificación.

Otra recomendación de Android es consolidar su arquitectura utilizando un sistema de Inyección de Dependencias, como Dagger 2 de Google o utilizando el patrón Service Locator (que es mucho más simple que DI, pero sin muchas de sus ventajas). No cubriremos DI o Service Locator en este tutorial, pero Envato Tuts+ tienes algunos excelentes tutoriales sobre esos temas. Sin embargo, ten en cuenta que hay algunas particularidades de trabajar con Dagger 2 y Android Components que se explicarán en la segunda parte de esta serie.

3. Arquitectura de Componentes

Debemos profundizar en los aspectos de los nuevos componentes para poder comprender y adoptar realmente este modelo de arquitectura. Sin embargo, no entraremos en todos los detalles en este tutorial. Debido a la complejidad de cada elemento, en este tutorial, solo hablaremos sobre la idea general detrás de cada uno y veremos algunos fragmentos de código simplificados. Intentaremos cubrir suficiente terreno para presentar los componentes y comenzar. Pero no temas, porque los artículos futuros de esta serie profundizarán y cubrirán todas las particularidades de los componentes de la arquitectura.

Componentes conscientes del ciclo de vida

La mayoría de los componentes de las aplicaciones Android tienen ciclos de vida asociados, que son gestionados directamente por el propio sistema. Hasta hace poco, era el desarrollador quien debía controlar el estado de los componentes y actuar en consecuencia, inicializando y finalizando las tareas en el momento adecuado. Sin embargo, era realmente fácil confundirse y cometer errores relacionados con este tipo de operaciones. Pero el paquete android.arch.lifecycle cambió todo eso.

Ahora, las Actividades y los Fragmentos tienen un objeto Lifecycle adjunto que puede ser observado por las clases LifecycleObserver, como un ViewModel o cualquier objeto que implemente esta interfaz. Esto significa que el observador recibirá actualizaciones sobre los cambios de estado del objeto que está observando, como cuando una Actividad está en pausa o cuando está comenzando. También puedes comprobar el estado actual del objeto observado. Así que ahora es mucho más fácil manejar operaciones que deben considerar los ciclos de vida del framework.

LifecycleObserver reacts to LifecycleEventsLifecycleObserver reacts to LifecycleEventsLifecycleObserver reacts to LifecycleEvents

Por ahora, para crear una Activity o Fragment que se ajuste a este nuevo estándar, tienes que extender una LifecycleActivity o LifecycleFragment. Sin embargo, es posible que esto no sea siempre necesario, ya que el equipo de Android tiene como objetivo integrar completamente estas nuevas herramientas con su framework.

El LifecycleObserver recibe los eventos del Lifecycle y puede reaccionar a través de la anotación. No es necesario sobreescribir ningún método.

El componente LiveData

El componente LiveData es un contenedor de datos que contiene un valor que se puede observar. Dado que el observador ha proporcionado un Lifecycle durante la instanciación de LiveData, LiveData se comportará de acuerdo con el estado del Lifecycle. Si el estado del Lifecycle del observador es STARTED o RESUMED, el observador está active; de lo contrario, está inactive.

LiveData sabe cuándo se cambiaron los datos y también si el observador está active y debería recibir una actualización. Otra característica interesante de LiveData es que es capaz de eliminar al observador si está en un estado Lifecycle.State.DESTROYED, evitando pérdidas de memoria cuando es observado por Activities y Fragments.

LiveData value updating processLiveData value updating processLiveData value updating process

Un LiveData debe implementar métodos onActive y onInactive.

Para observar un componente LiveData, debes llamar a observer(LifecycleOwner, Observer<T>).

El componente ViewModel

Una de las clases más importantes de la nueva Arquitectura de Componentes es el ViewModel, que está diseñado para mantener los datos relacionados con la UI, manteniendo su integridad durante los cambios de configuración, como las rotaciones de pantalla. El ViewModel es capaz de hablar con el Repository, obteniendo LiveData de él y haciéndolo disponible a su vez para ser observado por la vista. El ViewModel tampoco necesitará hacer nuevas llamadas al Repository tras los cambios de configuración, lo que optimiza mucho el código.

ViewModel is tight to UI LifecycleViewModel is tight to UI LifecycleViewModel is tight to UI Lifecycle

Para crear un modelo de vista, extiende la clase ViewModel.

Para acceder desde una vista, puedes llamar a ViewProviders.of(Activity|Fragment).get(ViewModel::class). Este método de fábrica devolverá una nueva instancia del ViewModel u obtendrá la retenida, según corresponda.

El componente Room

Android soportó SQLite desde el principio; sin embargo, para hacerlo funcionar, siempre fue necesario escribir un montón de boilerplate. Además, SQLite no guardaba POJOs (plain-old Java objects), y no comprobaba las consultas en tiempo de compilación. Ahora llega Room para resolver estos problemas. Es una librería de mapeo de SQLite, capaz de persistir POJOs de Java, convertir directamente las consultas en objetos, comprobar los errores en tiempo de compilación, y producir observables LiveData a partir de los resultados de las consultas. Room es una librería de mapeo relacional de objetos con algunos extras interesantes para Android.

Hasta ahora, se podía hacer la mayor parte de lo que Room es capaz de hacer utilizando otras bibliotecas ORM de Android. Sin embargo, ninguna de ellas está soportada oficialmente y, lo más importante, no pueden producir resultados LifeData. La librería Room encaja perfectamente como capa persistente en la arquitectura Android propuesta.

Para crear una base de datos Room, necesitarás una @Entity para persistir, que puede ser cualquier POJO de Java, una interfaz @Dao para hacer consultas y operaciones de entrada/salida, y una clase abstracta @Database que debe extender RoomDatabase.

Añadir componentes de arquitectura a tu proyecto

Por ahora, para utilizar los nuevos Componentes de Arquitectura, tendrás que añadir primero el repositorio de Google a tu archivo build.gradle. Para más detalles, consulta la guía oficial.

Conclusión

Como puedes ver, la arquitectura estandarizada propuesta por Android implica muchos conceptos. No esperes tener una comprensión completa de este tema todavía. Después de todo, solo estamos introduciendo el tema. Pero seguro que ya tienes suficientes conocimientos para entender la lógica que hay detrás de la arquitectura y los roles de los diferentes Componentes de la Arquitectura.

Hemos hablado de la mayoría de los temas relacionados con la arquitectura Android propuesta y sus componentes; sin embargo, los detalles sobre la implementación de los Componentes y algunos extras, como la clase Repository y el sistema Dagger 2 no pueden ser cubiertos por esta primera parte. Exploraremos esos temas en los próximos posts.

¡Hasta pronto!

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.