Hola En I/O 17, Google hizo dos anuncios importantes para los desarrolladores de aplicaciones de Android. El primero fue, por supuesto, Kotlin y el segundo, componentes de arquitectura. De hecho, los componentes de Arquitectura no recibieron mucha atención porque, cuando se anunció, la mayoría de los desarrolladores se habían ido para aprender Kotlin 🙂 Primero abordemos el elefante en la habitación. y el elefante es: Lifecycle. La característica única y desafiante del marco de Android.
En el escritorio, un usuario hace clic en una aplicación, la abre, funciona en ella y la cierra. Ese es el ciclo de vida, pero en Android una actividad que es una representación de una aplicación puede crearse varias veces durante una sola experiencia de usuario. Veamos qué tipo de desafíos nos trae esto. Fuga de memoria Hay un objeto que contiene una referencia de una actividad y, por alguna razón, esa actividad se vuelve a crear para que la instancia anterior se destruya, pero no se puede recolectar basura porque la referencia de esa actividad está en manos de otro objeto.
Esto conduce a la fuga de memoria. De hecho, este es un problema tal que los principiantes en una etapa temprana deben aprender a evitarlo. AsyncTask en estos días se usa principalmente para enseñarnos cómo ocurre la fuga de memoria 🙂 Persistencia de datos Suponga que en su Actividad en el método onCreate () Está obteniendo algunos datos y, por alguna razón, la Actividad se recrea Tal vez el usuario cambió la orientación. Se vuelve a llamar a onCreate() y se vuelven a recuperar los datos que no eran necesarios. El usuario no lo solicitó, por lo que esto conduce a la ineficiencia. ¿ Qué ha ofrecido Google? Google quiere ser más obstinado sobre cómo se deben desarrollar las aplicaciones y más orientación para los desarrolladores. No proporciona una solución, sino una herramienta en forma de componentes de arquitectura con los que podemos crear mejores aplicaciones. Componentes de arquitectura, hay dos secciones. Una está relacionada con el ciclo de vida y contiene clases como LifecycleOwner, LifecycleObserver y luego hay componentes relacionados con la persistencia de datos como LiveData, ViewModel y Room.
Analicémoslos brevemente uno por uno. ¿ Qué es LifecycleOwner? LifecycleOwner es una interfaz y cualquier clase que la implemente se convierte en LifecycleOwner Actualmente, Google nos proporciona dos clases. LifecycleActivity y LifecycleFragment que son LifecycleOwner Lo importante es que LifecycleOwner contiene un LifecycleObject que envía una notificación sobre los eventos de Lifecycle a su Observer LifecycleObserver Esta es una interfaz e implementada por aquellas clases que desean recibir eventos de ciclo de vida y esos eventos se reciben a través de anotaciones Analicemos las clases de ciclo de vida con un poco más de detalle Lifecycle es una clase abstracta.
Tiene dos enumeraciones y pocos métodos. Enum State tiene valores INITIALIZED, CREATED, STARTED, etc. Esto es algo nuevo. Solíamos obtener eventos que eran por un momento, pero ahora hay estados en los que podemos consultar y encontrar en qué estado se encuentra un ciclo de vida. La enumeración de eventos tiene valores ON_CREATE, ON_START, etc. que generalmente obtenemos en nuestra Actividad o Fragmento y luego hay métodos para administrar los observadores. La clase LifecycleRegistry amplía la clase Lifecycle. Administra observadores y transmite eventos del ciclo de vida a esos observadores. LifecycleOwner es una interfaz que tiene solo un método getLifecycle() y devuelve un objeto de Lifecycle LifecycleregistryOwner, amplía la interfaz de LifecycleOwner y anula el método getLifecycle() y devuelve el objeto LifecycleRegistry. y finalmente viene LifecycleActivity que vamos a usar como LifecycleOwner. Implementa LifecycleRegistryOwner. Anula el método getLifecycle() y devuelve un objeto mRegistry de la clase LifecycleRegistry.
Veamos cómo funcionan LifecycleObserver y LifecycleOwner. MyLifecycleObserver implementa la interfaz LifecycleObserver. La interfaz LifecycleObserver no contiene cualquier método Solo está ahí para marcar esta clase como un LifecycleObserver En su constructor, estamos pasando el objeto LifecycleOwner y luego llamamos al método getLifecycle() que devuelve un objeto Lifecycle y luego llamamos al método addObserver() del objeto Lifecycle y pasamos la instancia de esta clase LifecycleObserver, los eventos del ciclo de vida se reciben a través de anotaciones. Como vio, no sucedió ningún milagro. Ya tenemos eventos de ciclo de vida en nuestra Actividad y Fragmento Ahora podemos obtenerlo en las clases de LifecycleObserver No es gran cosa, pero luego proporciona una mejor separación.
Nuestro OnStart() onStop() de Activity y Fragment, estos métodos no estarían desordenados. Esta separación desde el punto de vista arquitectónico es un buen movimiento y conducirá a un código limpio. Ahora analicemos los componentes de datos. LiveData es una clase con un tipo genérico, es un contenedor de datos que se pueden observar. Es consciente del ciclo de vida, lo que significa que recibe eventos del ciclo de vida. Aquí hay un ejemplo. Creamos un objeto Observer, MyObserver, luego llamamos al método observe() de LiveData y pasamos el objeto LifecycleOwner así como el objeto myObserver. Ahora este objeto LifecycleOwner que hemos pasado LiveData lo usa para observar eventos del ciclo de vida, así es como sabe cuándo enviarnos datos. y cuando no. CORRECCIÓN: Lo mejor de la clase ViewModel es que ayuda a separar los datos. La forma en que obtenemos un objeto de la clase ViewModel en nuestro Fragmento o Actividad es que llamamos al método ViewModelProviders of() y luego pasamos la instancia de Fragmento o Actividad, luego llamamos al método get() y pasamos MyViewModel.class ViewModel es el contenedor perfecto para LiveData como persiste el cambio de configuración, por lo que resuelve nuestro problema de obtener los mismos datos una y otra vez.
Compartir datos entre fragmentos de una actividad es fácil. En Fragment, en lugar de pasar la instancia de Fragment en el método of(), pasamos la instancia de Activity usando getActivity() para que devuelva el objeto ViewModel de Activity. No ponga ninguna referencia de Actividad o Fragmento para evitar pérdidas de memoria. ViewModel conserva el cambio de configuración, por lo que no coincide con el ciclo de vida de Actividad o Fragmento. Room es una biblioteca de mapeo de objetos para SQLite. Aquellos de nosotros que recuperamos el cursor de SQLite sabemos que tenemos que iterar a través del cursor, extraer los datos, ponerlos en POJO y tal vez crear una Lista de POJO. Lo bueno es que Room hace todo esto automáticamente. Room tiene menos código repetitivo en comparación con lo que usamos para SQLite. La habitación también es inteligente. entonces, con este código de dos líneas, obtenemos una lista de usuarios que coinciden con un nombre con una palabra clave en particular.
Room también verifica el error en el momento de la compilación, por lo que esto debería ayudarnos a encontrar errores. Observability Room también puede devolver LiveData y así es como se conectan todos estos componentes. Entonces, tenemos LifecycleActivity / LifecycleFragment que contiene ViewModel que contiene LiveData devuelto por Room. y luego Room también es compatible con RxJava2. Aquí está la descripción general de los componentes de la arquitectura. Tenemos Activity / Fragment que observa LiveData contenido dentro de ViewModel. ViewModel lo obtiene del repositorio y el repositorio lo obtiene de Room o de una fuente de datos remota.
Aquí el repositorio es una capa de abstracción. Podríamos haber llamado Room directamente desde ViewModel, pero al usar esta capa de abstracción, el repositorio estamos siendo flexibles con las fuentes de datos. La biblioteca Road Map Architecture está en versión alfa en este momento, con suerte pronto podremos obtener una versión estable. Requiere Android Studio versión 2.3 o superior. Actualmente, se han introducido dos clases nuevas, LifecycleActivity y LifecycleFragment, que son LifecycleOwner. Posteriormente, estas clases se fusionarán respectivamente con AppCompatActivity y Fragment para que podamos usarlas normalmente como lo hacemos ahora. ¿ Qué sigue? Google ha recogido prácticas populares y ha tratado de implementarlas en el marco de Android. Esto reducirá la curva de aprendizaje y, con suerte, motivará a más desarrolladores a usarlos. Diría nuevamente que estas no son soluciones a un problema, sino herramientas para mejorar nuestras aplicaciones. Sugeriría seguir adelante y leer la guía de arquitectura, leer la documentación, probar los laboratorios de código. He puesto algunos enlaces en el cuadro de descripción. Puede que los encuentre útiles.
Gracias..