Arquitectura de Software

1

Arquitectura en Android

2

Patrón de diseño vs. Arquitectura de Diseño

3

¿Qué es la Arquitectura de Diseño?

4

SOLID: Single Responsability y Open/Closed Principles

5

SOLID: Liskov substitution, Interface segregation y Dependency Inversion principle

6

Evolución de la Arquitectura en Android

Arquitectura Model View Controller (MVC)

7

¿Qué es la aquitectura Model View Controller (MVC)?

8

MVC en un Proyecto Android: Analizando el código en capas

9

MVC en un Proyecto Android: Llevando el código a sus responsabilidades

Arquitectura Model View Presenter (MVP)

10

¿Qué es la aquitectura Model View Presenter (MVP)?

11

¿Qué es Clean Architecture?

12

Composición en Clases

13

Model View Presenter explicado

14

Capa Model

15

MVP en un Proyecto Android: Presenters y Views

16

MVP en un Proyecto Android: Model

17

Ubicando el código en MVP

Arquitectura Model View ViewModel (MVVM)

18

¿Qué es la arquitectura Model View ViewModel (MVVM)?

19

¿Cómo funciona MVVM Data Binding?

20

MVVM Data Binding estructurando nuestra aplicación y migrando a AndriodX

21

MVVM DataBinding creando un ViewModel

22

Patron Observer en MVVM

23

MVVM Data Binding: integrando ViewModel a View

24

MVVM Data Binding: RecyclerView Adapter

25

MVVM Data Binding: RecyclerView CardView

Android JetPack Arquitectura

26

¿Qué es Android JetPack Arquitectura?

27

¿Cómo funciona la arquitectura de componentes?

28

Arquitectura Componentes Lifecycle ViewModel

29

Arquitectura Componentes Lifecycle Observe

Fin del curso

30

Conclusiones

Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Curso de Arquitectura de Android

Curso de Arquitectura de Android

Anahí Salgado Díaz de la Vega

Anahí Salgado Díaz de la Vega

MVP en un Proyecto Android: Presenters y Views

15/30
Recursos

Aportes 7

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Hay dos cosas que creo que se pueden mejorar.

  1. No pasar ArrayList por parámetros, lo recomendable es pasar List, tiene que ser un objeto inmutable.

  2. Pasar el interator por el constructor del presenter en conjunto de la view, no estamos aplicando inyección de dependencia al 100%, esto mas va perjudicar si queremos hacer un test unit al presenter, no vamos a tener forma…

es mucho mas ordenado esta arquitectura que la de clases anteriores

Para desacoplar de mejor forma el presentador , se deben agregar dos interfaces distintas:

  1. CouponPresenterView,
  2. CouponPresenterInteractor

De esta forma desde el view no verémos el método showCoupons y desde el interactor no verémos el método getCoupons

Esta quedando excelente el proyecto con la nueva arquitectura y se ve mucho mas ordenado

lo que aún no entiendo es… porque solo couponView va en el constructor y no couponInteractor. Que significa que vaya o no vayan dentro del constructor? la app explota?

Solo como recomendación, deberíamos de utilizar data class para el mapeo de datos de una Api o cuando se utiliza una base de datos local con Room por ejemplo. Esto lo menciono porque en el modelo anncode utiliza algo parecido a las clases de java donde se necesitaba hacer uso de getters y setters…

No entiendo un jo… (creo que esto no es lo mío) 😭