Descargar como PDF, PPTX
Subido porDavid Luque Quintana
Como implementar MVP sin morir en el intento
Este documento describe cómo implementar el patrón MVP (Model-View-Presenter) sin problemas. Explica las diferencias entre MVC y MVP, los principios SOLID y Clean de programación, y cómo dividir la aplicación en capas de UI, Presenter y Modelo. También cubre el uso de EventBus para comunicar entre capas y recomienda artículos adicionales sobre arquitectura limpia en Android.
Como implementar MVP sin morir en el intento
- 1. Cómo implementar MVPsin morir en el intento David Luque Quintana
- 3. ¿Qué tengo quesaber? Clean SOLID MVP
- 4. Quien soy David LuqueQuintana Android & iOS Signlab GDG Córdoba Organizer @TwitDavids
- 5. Índice ● Qué esClean ● Qué es SOLID ○ S - Principio de Responsabilidad única ○ O - Principio de abierto-cerrado ○ L - Principio de sustitución de Liskov ○ I - Principio de segregación de dependencias ○ D - Principio de inversión de dependencias ● Qué es MVP ● MVC vs MVP ○ MVC ○ MVC - Pros y contras ● MVP vs MVP ○ MVP ○ MVP - Pros y contras ● ¿Y Google? ○ Android Architecture Components ● Cómo implementar MVP ○ UI ○ Presenter ■ Qué es EventBus ○ Data Model ● Artículos interesantes
- 6. ¿Qué es Clean? “Cleancode” es código fácil de entender y fácil de cambiar
- 7. ¿Qué es Clean? “Cleancode is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.” Robert C. Martin
- 8. ¿Qué es Clean? ●Código separado por capas, como una cebolla. ● Una capa no debe de saber cómo está implementada otra capa. ● Las capas son aisladas, si modificamos una no se deben de modificar las demás.
- 9. ¿Qué es Clean? ●Independiente del Framework. ● Testable. ● Independiente de la UI. ● Independiente de la base de datos. ● Independiente de algo externo.
- 10. ¿Qué es SOLID? Soncincos principios básicos de la programación orientada a objetos.
- 11. S - Principiode responsabilidad única Una clase debe tener una y sólo una razón para cambiar, entendiendo que una clase está destinada a una sóla función
- 12. S - Principiode responsabilidad única
- 13. S - Principiode responsabilidad única El objeto que instanciemos debe realizar una única cosa. ● A más métodos más probable es que no haga una única cosa. ● Cuidado con los imports. ● Cuando cambiamos algo en nuestro código no se debe ver afectado.
- 14. O - Principiode abierto-cerrado Los objetos o entidades deben estar abiertos a la extensión, pero cerrados a la modificación. Hay que ser capaz de ampliar la implementación de la clase sin modificar lo que ya hay. Las interfaces son nuestras amigas.
- 15. L - Principiode sustitución de Liskov Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
- 16. L - Principiode sustitución de Liskov Si yo tengo una clase A que implementa una interfaz I, yo puedo declarar un objeto I que instancie a la clase A
- 17. I - Principiode segregación de interfaces Una clase no debe depender de métodos que no usa. Cuando usamos interfaces, tenemos que tener cuidado de no implementar en una clase una interfaz que tenga métodos que no vamos a usar.
- 18. D - Principiode inversión de dependencias Con el principio de inversión de dependencias queremos que nuestro código core no dependa de otros detalles de implementación, cómo puede ser el framework o alguna conexión a base de datos. La idea es no tener new en nuestro código, sino un inyector de dependencias que nos dará todos esos objetos cuando nuestra clase se declare. Así nos ahorramos todas las instancias, el código es más testable y podemos ahorrar problemas de memoria. Por tanto, las clases de nuestra aplicación tendrán dependencias abstractas.
- 19. ¿Qué es MVP? ●Es una derivación de MVC ● Toda la lógica de presentación se va al Presenter
- 20.
- 22. MVC ● Modelo: clasesque representan las entidades. Por ejemplo, clase Usuario. ● Vista: archivos XML del layout ● Controlador: básicamente Actividades o Fragments
- 23. MVC - Prosy contras Pros: ● Una arquitectura usada en muchos lenguajes y bastante común. ● Fácil de implementar. ● La aplicación queda medianamente bien estructurada. Contras: ● Código espagueti. ● Poco modular. ● No ayuda a la hora de depurar.
- 24. MVP ● Modelo: elmodelo son las entidades y la lógica de negocio que nos permite interaccionar con servicios externos o internos para la representación de datos (Clean o Repository). ● Presenter: es el cerebro de la lógica de la aplicación, conecta la vista con el modelo y sólo él puede hacerlo. ● Vista: al igual que en MVC son los archivos XML de los layouts y las Actividades o Fragments.
- 25. MVP - Prosy contras Pros: ● Aplicación mucho más modular. ● Más testable. ● Reducción considerable de código espagueti. ● Mayor limpieza de código. Contras: ● Más capas de abstracción. ● Al principio se hace complejo. ● Si te gusta jugar con Context lo vas a echar de menos.
- 26. ¿Y Google? ● Losdatos deben “sobrevivir” al ciclo de la actividad. ● No escribir todo el código en la Actividad. Código que no sea de UI no debe ir ahí.
- 27.
- 28.
- 30.
- 31. A dumb UIis a good UI ● La actividad, Fragment o DialogFragment SÓLO IMPLEMENTA UI. ● La vista delega las interacciones al Presenter. ● El Presenter ya se encargará de gestionar las interacciones cómo él vea. ● Cuando se genere algo desde el Presenter nos lo hará llegar a la vista View Presenter
- 32.
- 34. Presenter ● Recibe lasinteracciones del usuario a través de la vista. ● Instancia EventBus para recibir eventos. (IMPORTANTE) ● Comprueba si la vista existe antes de hacer algo. ● Mantiene una instancia de la vista mientras está presente, se encarga de eliminarla cuando se produce un onDestroy() ● Al recibir un evento ejecuta algo en la vista
- 35. ¿Qué es EventBus? Esun bus de eventos para simplificar componentes. Es muy simple de usar pero debemos tener cuidado al usarlo.
- 36.
- 37. ¿Qué es EventBus?- Alternativas ● Podemos usar callbacks para retornar lo que nos haga falta. ● Dobles interfaces, una para llamar y otra para recibir.
- 38.
- 39. Repository ● El repositorioes la zona de nuestra app que se encarga del “trabajo sucio” ● Llama a la API, parsea los datos, lee de un JSON interno… ● Puede ser muy modular si lo codificamos de esta forma. ● Simple y fácil de debuggear
- 40. Artículos interesantes ● Adetailed guide on developing Android apps using the Clean Architecture pattern ● A dumb UI is a good UI ● Model-View-Presenter: Android guidelines