Implementación de MVP para Android, Clean y SOLID

1. Cómo implementar MVP sin
morir en el intento
David Luque Quintana

3. ¿Qué tengo que saber?
Clean
SOLID
MVP

4. Quien soy
David Luque Quintana
Android & iOS Signlab
GDG Córdoba Organizer
@TwitDavids

5. Índice
● Qué es Clean
● 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?
“Clean code” es código fácil de entender y fácil
de cambiar

7. ¿Qué es Clean?
“Clean code 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?
Son cincos principios básicos de la programación orientada a objetos.

11. S - Principio de 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 - Principio de responsabilidad única

13. S - Principio de 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 - Principio de 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 - Principio de 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 - Principio de 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 - Principio de 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 - Principio de 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. MVC vs MVP

22. MVC
● Modelo: clases que
representan las entidades.
Por ejemplo, clase Usuario.
● Vista: archivos XML del
layout
● Controlador: básicamente
Actividades o Fragments

23. MVC - Pros y 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: el modelo 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 - Pros y 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?
● Los datos 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. Android Architecture Components

28. Cómo implementar MVP

30. UI (Activity)

31. A dumb UI is 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. Presenter

34. Presenter
● Recibe las interacciones 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?
Es un bus de eventos para simplificar componentes. Es muy simple de usar pero
debemos tener cuidado al usarlo.

36. ¿Qué es EventBus?

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. Data Model
(No interactors)

39. Repository
● El repositorio es 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
● A detailed guide on developing Android apps using the Clean Architecture
pattern
● A dumb UI is a good UI
● Model-View-Presenter: Android guidelines