Introducci贸n

1

Qu茅 aprender谩s sobre Clean Architecture en Android

2

驴Qu茅 es clean architecture?

Repaso de Conceptos Generales

3

Principios SOLID

4

Repository Pattern

Presentaci贸n del proyecto

5

Presentaci贸n del proyecto: Rick and Morty

6

Uso de RxJava y RxAndroid en el proyecto

Capa de Presentaci贸n

7

Introducci贸n a la capa de presentaci贸n

8

Implementaci贸n de la capa de presentaci贸n

9

Soluci贸n del reto

Capa de Casos de Uso

10

Introducci贸n a la capa de casos de uso

11

Soluci贸n del reto: capa de casos de uso

Capa de Dominio

12

Introducci贸n a la capa de dominio

13

Implementaci贸n de la capa de dominio: mappers

14

Migraci贸n entidades de framework a dominio

15

Soluci贸n del reto: capa de dominio

Capa de Datos

16

Introducci贸n a la capa de datos

17

Implementaci贸n de la capa de datos: repositorio

18

Implementaci贸n de la capa de datos: fuente de datos

19

Soluci贸n del reto: capa de datos

Extras: Migraci贸n de Capa de Casos de Uso

20

Migraci贸n de la capa de casos de uso

Capa de Framework

21

Introducci贸n a la capa de framework

22

Implementaci贸n de Image Manager (Glide)

23

Implementaci贸n de Database Manager (Room)

24

Implementaci贸n de Request Manager (Retrofit)

Inyecci贸n de Dependencias

25

Introducci贸n a la inyecci贸n de dependencias

26

Implementaci贸n de Dagger (M贸dulos)

27

Implementaci贸n de Dagger (Componente)

28

Soluci贸n del reto: inyecci贸n de dependencias

Pruebas unitarias a nivel general

29

Implementaci贸n de pruebas unitarias (conceptos generales)

30

Pruebas unitarias en la capa de presentaci贸n

31

Pruebas unitarias en las capas de casos de uso y datos

Conclusiones

32

C贸mo seguir mejorando la arquitectura

Repository Pattern

4/32

Lectura

En esta clase te hablar茅 de un concepto muy importante que manejaremos en la capa de datos: el patr贸n de repositorio (Repository Pattern).

El patr贸n de repositorio es un patr贸n de tipo estructural cuyo objetivo es abstraer cada operaci贸n que se realiza sobre la capa de datos.

Ventajas

Algunas de las ventajas que te da este patr贸n estructural son:

  • Las capas superiores no conocen los detalles de la implementaci贸n de las operaciones dentro de la capa de datos.
  • Cada operaci贸n est谩 encapsulada en un solo sitio, y con ello el c贸digo se puede reusar f谩cilmente.
  • Se vuelve f谩cil de aislar y realizar pruebas unitarias para comprobar su funcionamiento.
  • Puedes reemplazar f谩cilmente la implementaci贸n que ocurre en el repositorio, ya que se manejan interfaces (esto va de la mano con el Principio de Inversi贸n de Dependencia de SOLID).

Ejemplo

En el siguiente fragmento de c贸digo, hay dos interfaces que indican dos fuentes de datos de un jugador (Player): local (LocalPlayerDataSource) y remoto (RemotePlayerDataSource). Con estas interfaces solo sabes qu茅 comportamiento esperar de una fuente local y una remota, pero la implementaci贸n depender谩 de otra capa m谩s especializada (la fuente local puede ser una base de datos o un archivo, mientras que la fuente remota puede ser una API web utilizando Retrofit o Volley).

interface LocalPlayerDataSource {
    fun saveFavoritePlayer(player: Player): Boolean
}

interface RemotePlayerDataSource {
    fun getPlayerList(playerList)
}

A continuaci贸n tendr谩s tu clase del repositorio para el jugador (PlayerRepository), el cual utilizar谩 estas dos fuentes de datos, y decidir谩 en qu茅 flujos utilizarlos (se obtiene la lista de jugadores de la fuente remota mientras que se guarda un jugador favorito usando la fuente local).

class PlayerRepository(
    private val localPlayerDataSource: LocalPlayerDataSource,
    private val remotePlayerDataSource: RemotePlayerDataSource
){
    fun getPlayerList(): List<Player> = remotePlayerDataSource.getPlayerList()
    
    fun saveFavoritePlayer(player: Player): Boolean = localPlayerDataSource.saveFavoritePlayer(player)
}

Finalmente quien utilice el repositorio (usando Clean Architecture ser谩 un caso de uso) no tiene idea del detalle de la implementaci贸n, tan solo se limitar谩 a pedir la informaci贸n que necesita.

class GetPlayerListUseCase(private val repository: PlayerRepository){
    fun invoke(): List<Player> = playerRepository.getPlayerList()
}

class SaveFavoritePlayerUseCase(private val repository: PlayerRepository){
    fun invoke(player: Player): Boolean = playerRepository.saveFavoritePlayer(player)
}

En conclusi贸n, el patr贸n de repositorio es una excelente opci贸n para manejar el flujo de datos de tu proyecto, haciendo el proceso m谩s f谩cil tanto de implementar como de reemplazar fuentes de datos.

Si a煤n no tienes claro el concepto de arquitectura limpia, puedes leer m谩s en: Qu茅 es Clean Architecture.

Aportes 2

Preguntas 1

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Reg铆strate o inicia sesi贸n para participar.

Tambi茅n se puede leer en la documentaci贸n de Android aqu铆. Para profundizar un poco sobre el patr贸n repositorio del uso que se le da. Aunque la explicaci贸n que nos dan es muy consisa.

En palabras simples el patron repository es el uso de interfaces para definir de donde van a venir los datos, y luego implementar esas interfaces para obtener los datos.