Patrones de Arquitectura aplicados a Android

Los patrones de arquitectura existen para ayudarlo a diseñar su app, de tal manera que te permita mantener la app a medida que crece. Siempre hubo el debate sobre cuál es el mejor, actualmente se utiliza mucho el MVVM, pero necesitas saber cómo funciona, ventajas y desventajas de cada patrón para tomar la mejor decisión de acuerdo al problema que afrontes.

Charla para GDG Cusco - 2020 "Patrones de arquitectura aplicados a android".
Publicaciones y repositorios asociados a este charla.

¿Por qué no funciona MVC en Android?
https://medium.com/@fahedhermoza/por-qué-no-funciona-mvc-en-android-d0b747a823c0

Android y el patrón MVP
https://medium.com/@fahedhermoza/android-y-el-patrón-mvp-4b9ddf377185

Android y el patrón MVVM
https://medium.com/@fahedhermoza/android-y-el-patrón-mvvm-b5e71f5e8ec7

Repositorio:
https://github.com/FahedHermoza/PatronesDeArquitectura-Android

Transcript

1. Patrones de Arquitectura aplicados a Android Dado por: Fahed Hermoza
2. Un poco de mi persona Apasionado por las tecnologías móviles. Apasionado por escribir código de calidad. Fundador de DevArt Perú y del startup Me Apunto. +4 años de experiencia como Android Dev.
3. ¿Qué pasó durante varios años en las comunidades Android?
4. Patrones de Arquitectura Patrones de Presentación Patrones de UI Patrones de Diseño Arquitectónico Patrones de Diseño de Arquitectura de UI
5. Patrones de Arquitectura Todos existen para ayudarlo a diseñar su app, de tal manera que te permita mantener la app a medida que crece. Es decir separa la funcionalidad de la app, para que sea fácil de probar y proporciona un mantenimiento de bajo costo
6. ¿Cual es el mejor? MVC, MVP, MVVW, MVI, VIPER Depende de tu app en particular y sus necesidades
7. Importancia 1. Separación de intereses: “Es un principio de diseño para separar un programa informático en secciones distintas, tal que cada sección enfoca un interés delimitado” - Wikipedia Separación de componentes por responsabilidades.
8. Importancia 22. Pruebas de Unidad: “Es una forma de comprobar el correcto funcionamiento de una unidad de código” - Wikipedia A medida que crece, probara su app para asegurarse de no romper la lógica de las funcionalidades existentes.
9. MVC - Modelo Vista Controlador Patrón de arquitectura separa los componentes de un sistema de software en función de las responsabilidades: • Modelo: Es la capa de datos que incluye los objetos de datos, las clases de BD y otras lógicas de negocio, relacionadas con el almacenamiento de datos.
10. MVC • Vista: Es responsable de representar los datos de una manera legible para las personas a través de una pantalla. • Controlador: Encapsula la lógica del sistema y controla tanto el Modelo como la Vista. El usuario interactúa con el sistema a través del controlador.
11. MVC aplicado a la web
12. MVC adaptación a Android
13. MVC - Problemas
14. MVC - Problemas • No cumple con el objetivo del MVC de separar las responsabilidades en 3 componentes distintos. • Tener la Actividad como controlador en MVC plantea un problema para las Pruebas de Unidad. Este patrón de arquitectura solo te permite probar el Modelo. • Extra: Debido a la naturaleza de la clase Activity, que contiene tanto la lógica del controlador y la vista, terminas con enormes clases de Activity.
15. MVP - Modelo Vista Presentación Patrón de arquitectura se compone de las siguientes partes: • Modelo: Responsable de recuperar datos, almacenarlos y cambiarlos. • Vista: Responsable de mostrar la UI, este rol se designa a una Activity o Fragment.
16. MVP • Presentador: El presentador es la clase que habla tanto con el Modelo como con la Vista. Cualquier código que no maneje directamente la UI u otra lógica específica del marco de Android, debe moverse de la Vista a la clase Presentador. Lógica de Presentación: Cualquier mapeo o formateo adicional de los datos es responsabilidad del Presentador. MVP hace uso de interfaces para cumplir sus objetivos.
17. MVP comprobable
18. MVP adaptación a Android
19. MVP - Ventajas • Logra la separación de intereses es su app. • Los Modelos y Presentadores son partes comprobables por unidad.
20. MVP - Desventajas Cuando se destruye su activity, debe incluir a su Presentador la destrucción de cualquier suscripción o AsyncTasks, de lo contrario causará problemas cuando la tarea sea completada y la Activity ya no esté allí.
21. MVP - Solución Si desea que la memoria retenida por el Presentador se libere y sea recolectada por el Garbage Collector, debe tener en cuenta que no haya referencias al presentador en ninguna otra clase que continúe viviendo en la memoria. Si desea que su presentador sobreviva a la destrucción de la Activity puede intentar guardar algún estado a través de onSaveInstanteState o usar cargadores, que sobrevivan a los cambios de configuración.
22. MVVM - Modelo Vista ViewModel Patrón de arquitectura se divide en 3 componentes: • Modelo(DataModel): Recupera información de su fuente de datos y lo expone a los ViewModels. • Vista: Muestra la UI e informa a las otras capas sobre acciones del usuario. • ViewModel: Recupera información necesaria del Modelo, aplica las operaciones necesarias y expone los datos relevantes a través de eventos que las Vistas pueden observar.
23. MVVM Principal Diferencia: • El ViewModel no debe contener ninguna referencia a la Vista. • ViewModel solo proporciona información y no le interesa quien lo consuma. Relación de uno a muchos entre la Vista y el ViewModel
24. MVVM
25. MVVM - Responsabilidad única Debe esforzarse por apegarse al principio SOLID. • Creando un objeto para cada objeto lógico en su dominio (data class kotlin), esto facilitará la creación de los ViewModels necesarios. SOLID: Son 5 principios para construir software siguiendo buenas prácticas.
26. MVVM - Ciclo de vida Si Android destruye o recrea una Activity o Fragment, todos los datos contenidos en sus componentes se pierden. • Ejem: Si su app incluye una lista de productos en una de sus actividades. Si la activity se destruye y se vuelve a crear, la lista de productos deberá recuperarse nuevamente. Problema: Esto puede ralentizar su app si la lista se encuentra en una API externa.
27. MVVM - Ciclo de vida Soluciones: • Guardar los datos en su método onSaveInstanceState() y restaurarlo más tarde en su método onCreate() (onRestoreInstateState ó onViewStateRestored). Desventaja, solo funciona para datos primitivos, como enteros o clases simples que pueden serializar o deserializar. • Usar los Componentes de Arquitectura de Android: ViewModel y LiveData.
28. MVVM - Ciclo de vida • La clase ViewModel diseñada para administrar y almacenar información de manera conciente del ciclo de vida, significa que los datos almacenados en su interior pueden sobrevivir a los cambios de configuración como las rotaciones en pantalla. • La clase LiveData permite que cualquier Vista observe cualquier cambio en datos relevantes y actualice la UI. Flujo: ViewModel expone los objetos LiveData y actualiza sus valores. Las Vistas deben comenzar a observar a estos objetos LiveData.
29. MVVM - Ciclo de vida
30. MVVM - Función Principal de la vista Observar uno o más ViewModels para obtener la información necesaria que necesita y actualizar la UI en consecuencia. • Las vistas pueden tener una referencia a una o más ViewModels, pero un ViewModel nunca puede tener ninguna información sobre las Vistas. Tip: En Android, generalmente comunicará los datos entre las Vistas y los ViewModels con observables (RxJava, LiveData o DataBinding). .
31. MVVM - Ventajas • Logra la separación de intereses es su app. • Los Modelos y ViewModels son partes comprobables por unidad.
32. MVVM - Ventajas Frente a MVC Fat Controller: A veces, cuando el código no cabe en el Modelo o la Vista, se coloca en el Controlador. En consecuencia la clase Controlador se vuelve demasiado grande y difícil de mantener. MVVM resuelve este problema al proporcionar una mejor separación de intereses.
33. MVVM - Desventajas MVVM puede ser demasiado complejo para una app cuya UI es bastante sencilla
34. MVP VS MVVM- DIFERENCIAS MVP relación de uno a uno entre la Vista y el Presentador. MVVM la relación es de uno a muchos entre entre la Vista y el ViewModel. MVP el presentador tiene referencia a la vista. MVVM el ViewModel no tiene referencia a la vista. MVP puede producir más clases(interfaces) y código. MVVM también produce más clases pero menos código en cada clase. MVP es fácil de aprender, modificar, agregar funciones. MVVM agregar nuevas funciones puede requerir algo de experiencia con la biblioteca. MVC y MVP debe escribir código adicional para mantener el estado. MVVM tiene un mecanismo para mantener el estado que está listo para usarse.
35. DEMO
36. Conclusión • MVC en Android no logra los objetivos de un patrón de arquitectura. • MVP logra la separación de intereses y pruebas de unidad. Desventaja, cuando se destruye una activity en su presentador debe destruirse las llamadas a suscripcion o asyntask. • MVVM logra la separación de intereses y pruebas de unidad. Tiene un mecanismo para manejar el estado de la app. Desventaja puede llegar a ser complejo para una app con UI sencilla. • Para crear apps de calidad, un requisito importante es aprender los patrones de arquitectura que se debaten en las comunidades Android desde hace varios años como MVP, MVVM, MVI y VIPER.
37. ¡GRACIAS! Fahed Hermoza