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

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso de Arquitectura de Android

Curso de Arquitectura de Android

Anahí Salgado Díaz de la Vega

Anahí Salgado Díaz de la Vega

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

10/30
Recursos

Esta arquitectura resuelve varios detalles que se presentan cuando tienes una aplicación con MVC. No toda la responsabilidad debe caer en nuestro MainActivity porque esto podría ocasionar errores de fluidez haciéndola colapsar al haber un proceso pesado en el hilo principal de la aplicación.

MVP organiza mejor la distribución de archivos y define las responsabilidades de otra forma.

Aportes 8

Preguntas 5

Ordenar por:

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

En resumen:
Model View Presenter trabaja en:
• Evita que nuestra aplicación colapse por el exceso de responsabilidad a Main Activity
• Trabaja en hilos diferentes cada uno

Basando en la diagrama, hay cosas que hay saber separar, tenemos
MVP basico y no requiere de interactor y resporitory pero podemos caer en MVC, para ir desacoplando mucho mas usamos el interactor y repository.
MVP + Interactor/UseCase.
MVP + Repository.
MVP + Interactor + Repository.

Comentaste que 1Activity + 1Presenter o 1Fragment + 1Presenter, a veces esto no es tan cierto, hay casos que activity que tiene mucha lógica de vista o muchas interactiones con un Api que puedes llegar a tener muchos mas presenter en una activity o fragment… Todo depende mucho de los casos de usos que puede tener la aplicación…

¿La relación entre Presenter y Model no es bidireccional?

MVP no es una arquitectura sino un patron de diseño

En otro comentario leí que el Presenter y la View tienen comunicación bidireccional. Entiendo que la View debe transmitir sus peticiones al Presenter, por tanto me es logico pensar que debe tener un objeto Presenter. Sin embargo cuando trabajo con una biblioteca como Volley o Retrofit para el consumo de servicios Rest, estas delegan su proceso a un hilo nuevo ¿Cual es la manera más eficaz de que ese hilo sepa que vista debe actualizar? Yo lo hago pasandole el Context o la Activity. Pero siento que no es la mejor manera y produce codigo confuso. Me regalan su experiencia por favor 😄

Yo lo veo muy parecido a un MVC

MODEL VIEW PRESENTER

Model: Doscomponentes: interactor y repositorio. El interactor decide 
que tipo de fuente de datos se va utilizar. Hay varios tipos de repositorios
uno puede ser una APIRest, BD, sharedPreferences. 

View: Activitys, fragments, view. La vista no tiene conocimiento de los modelos.

Presenter:  Para cada activity o fragment, hay un presenter. Se encarga de
    recibir lo que la vista le solicite, primero pasando por el interactor.