Tweet
Tweet

Slide 1

Slide 1 text

Arquitectura de soluciones móviles con Android

Slide 2

Slide 2 text

Pablo Johnson @pablojohnson88 [email protected] https://github.com/pablo-johnson Desarrollador Android en Belatrix

Slide 3

Slide 3 text

Software de calidad

Slide 4

Slide 4 text

Software de calidad ● Robusto

Slide 5

Slide 5 text

Software de calidad ● Robusto ● Testeable

Slide 6

Slide 6 text

Software de calidad ● Robusto ● Testeable ● Flexible

Slide 7

Slide 7 text

Software de calidad ● Robusto ● Testeable ● Flexible ● Escalable

Slide 8

Slide 8 text

Arquitecturas Hexagonal Architecture Screaming Architecture Onion Architecture BCE DCI

Slide 9

Slide 9 text

Clean Architecture

Slide 10

Slide 10 text

Clean Architecture

Slide 11

Slide 11 text

Clean Architecture ● Independiente de algún framework

Slide 12

Slide 12 text

Clean Architecture ● Independiente de algún framework ● Testeable

Slide 13

Slide 13 text

Clean Architecture ● Independiente de algún framework ● Testeable ● Independiente de la UI

Slide 14

Slide 14 text

Clean Architecture ● Independiente de algún framework ● Testeable ● Independiente de la UI ● Independiente de la BD

Slide 15

Slide 15 text

Clean Architecture ● Independiente de algún framework ● Testeable ● Independiente de la UI ● Independiente de la BD ● Independiente de cualquier agente externo

Slide 16

Slide 16 text

La regla de la dependencia Las dependencias del código solo deben apuntar hacia el interior.

Slide 17

Slide 17 text

Entities Las entidades encapsulan las reglas de negocio de toda la empresa

Slide 18

Slide 18 text

Use Cases Los casos de uso son los encargados de orquestar el flujo de data desde y hasta las entidades y dirigen estas entidades con el fin de conseguir los objetivos del caso de uso.

Slide 19

Slide 19 text

Adaptadores de interfaces - Presenters Los adaptadores son los encargados de convertir la data de la forma más conveniente para las entidades y casos de uso hacia la forma más conveniente para algún agente externo (UI, DB, etc).

Slide 20

Slide 20 text

Frameworks y drivers - UI Es la capa encargada de interactuar con el usuario.

Slide 21

Slide 21 text

Android -> La propuesta

Slide 22

Slide 22 text

Capa de Presentación Aquí es donde reside la lógica de las vistas y animaciones

Slide 23

Slide 23 text

Capa de Presentación Aquí es donde reside la lógica de las vistas y animaciones Se puede implementar haciendo uso de algún patrón como MVC, MVVM o MVP (imagen).

Slide 24

Slide 24 text

Capa de Presentación Aquí es donde reside la lógica de las vistas y animaciones Se puede implementar haciendo uso de algún patrón como MVC, MVVM o MVP (imagen).

Slide 25

Slide 25 text

Capa de Dominio En esta capa se encuentran las reglas de negocio. Toda la lógica de negocio sucede acá.

Slide 26

Slide 26 text

Capa de Dominio En esta capa se encuentran las reglas de negocio. Toda la lógica de negocio sucede acá. Esta capa puede estar enteramente en Java (o Kotlin :O )

Slide 27

Slide 27 text

Capa de Dominio En esta capa se encuentran las reglas de negocio. Toda la lógica de negocio sucede acá. Esta capa puede estar enteramente en Java (o Kotlin :O )

Slide 28

Slide 28 text

Capa de Datos Esta capa es la encargada de proveer toda la data necesaria para la aplicación.

Slide 29

Slide 29 text

Capa de Datos Esta capa es la encargada de proveer toda la data necesaria para la aplicación. Se implementa el patrón Repository que, junto a una estrategia, escoge distintos tipos de fuente de los datos.

Slide 30

Slide 30 text

Capa de Datos Esta capa es la encargada de proveer toda la data necesaria para la aplicación. Se implementa el patrón Repository que, junto a una estrategia, escoge distintos tipos de fuente de los datos.

Slide 31

Slide 31 text

¿Cómo separar nuestro software en capas?

Slide 32

Slide 32 text

Programacion reactiva Es un paradigma de programación orientado al flujo de datos y a la propagación del cambio.

Slide 33

Slide 33 text

Programación Imperativa vs Programación Reactiva

Slide 34

Slide 34 text

Programación Imperativa vs Programación Reactiva Imperativa int a = 3 int b = 4 int x = a + b print(x) => 7

Slide 35

Slide 35 text

Programación Imperativa vs Programación Reactiva Imperativa int a = 3 int b = 4 int x = a + b print(x) => 7 a=4 print(x) => ….

Slide 36

Slide 36 text

Programación Imperativa vs Programación Reactiva Imperativa int a = 3 int b = 4 int x = a + b print(x) => 7 a=4 print(x) => 7 !!!!

Slide 37

Slide 37 text

Programación Imperativa vs Programación Reactiva Imperativa int a = 3 int b = 4 int x = a + b print(x) => 7 a=4 print(x) => 7 !!!! Reactiva int a = 5 Func b = { 2 * a + 1} print(b) => 11

Slide 38

Slide 38 text

Programación Imperativa vs Programación Reactiva Imperativa int a = 3 int b = 4 int x = a + b print(x) => 7 a=4 print(x) => 7 !!!! Reactiva int a = 5 Func b = { 2 * a + 1} print(b) => 11 a = 10 print(b) => ….

Slide 39

Slide 39 text

Programación Imperativa vs Programación Reactiva Imperativa int a = 3 int b = 4 int x = a + b print(x) => 7 a=4 print(x) => 7 !!!! Reactiva int a = 5 Func b = { 2 * a + 1} print(b) => 11 a = 10 print(b) => 21

Slide 40

Slide 40 text

RxJava RxAndroid RxJava es una implementación para Java de ReactiveX, una librería para realizar programas basados en eventos asíncronos haciendo uso del patrón Observer.

Slide 41

Slide 41 text

RxJava RxAndroid RxJava es una implementación para Java de ReactiveX, una librería para realizar programas basados en eventos asíncronos haciendo uso del patrón Observer. RxAndroid es una librería que adiciona a RxJava clases que hacen posible manejar los componentes reactivos en las aplicaciones Android de una manera más fácil y sin complicaciones.

Slide 42

Slide 42 text

Rx ejemplo

Slide 43

Slide 43 text

Rx ejemplo

Slide 44

Slide 44 text

Rx ejemplo

Slide 45

Slide 45 text

Beneficios ● Desacoplamiento entre Observables y Subscribers hace que el testing y el mantenimiento sea más fácil.

Slide 46

Slide 46 text

Beneficios ● Desacoplamiento entre Observables y Subscribers hace que el testing y el mantenimiento sea más fácil. ● Simplifica tareas asincronas.

Slide 47

Slide 47 text

Beneficios ● Desacoplamiento entre Observables y Subscribers hace que el testing y el mantenimiento sea más fácil. ● Simplifica tareas asincronas. ● Composición y transformación de la data.

Slide 48

Slide 48 text

Beneficios ● Desacoplamiento entre Observables y Subscribers hace que el testing y el mantenimiento sea más fácil. ● Simplifica tareas asincronas. ● Composición y transformación de la data. ● Manejo de errores.

Slide 49

Slide 49 text

Inyección de dependencias Es un patrón de diseño en el que se provee de objetos a una clase y se libera a ésta de la responsabilidad de crear o instanciarlos.

Slide 50

Slide 50 text

Ejemplo de inyección de dependencias

Slide 51

Slide 51 text

Ejemplo de inyección de dependencias

Slide 52

Slide 52 text

Dagger 2 Dagger es un framework de inyección de dependencia en tiempo de compilación para Java y Android.

Slide 53

Slide 53 text

Beneficios ● Favorece el reuso de los componentes debido a que las dependencias pueden ser inyectadas y configuradas externamente.

Slide 54

Slide 54 text

Beneficios ● Favorece el reuso de los componentes debido a que las dependencias pueden ser inyectadas y configuradas externamente. ● Hace posible el uso de mockear las dependencias, lo cual facilita el testing.

Slide 55

Slide 55 text

Testing Se sugiere utilizar lo siguiente: ● Para la capa de presentación: UI tests con Espresso 2 y Android Instrumentation. ● Para la capa de dominio: jUnit y Mockito ● Para la capa de datos: Roboelectric 3, jUnit y Mockito.

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

Organización de Paquetes Por capas ● Componentes no necesariamente relacionados dentro de un mismo paquete ● Paquetes con poca cohesión y modularidad y con gran acoplamiento entre paquetes. ● Editar una funcionalidad conlleva a editar archivos en distintos paquetes

Slide 58

Slide 58 text

Organización de Paquetes Por capas ● Componentes no necesariamente relacionados dentro de un mismo paquete. ● Paquetes con poca cohesión y modularidad y con gran acoplamiento entre paquetes. ● Editar una funcionalidad conlleva a editar archivos en distintos paquetes. Por funcionalidad ● Se trata de colocar todos los archivos relacionados a una funcionalidad en un mismo paquete. ● Paquetes con gran cohesión y modularidad y con un mínimo de acoplamiento entre paquetes.

Slide 59

Slide 59 text

Veamos un poco de código... Fernando Cejas https://github.com/android10/Android-CleanArchitecture

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Referencias Eduardo Medina https://github.com/emedinaa/android-clean-architecture Erik Jhordan http://erikcaffrey.github.io/2016/01/28/clean-architecture/ Fernando Cejas http://fernandocejas.com/2015/07/18/architecting-android-the-evolution/ Christian Panadero http://panavtec.me/my-way-to-clean-android

Slide 62

Slide 62 text

Otras fuentes importantes MVP http://antonioleiva.com/mvp-android/ https://www.linkedin.com/pulse/mvc-mvp-mvvm-architecture-patterns-shashank-gupta Dagger http://fernandocejas.com/2015/04/11/tasting-dagger-2-on-android/ https://realm.io/news/daniel-lew-dependency-injection-dagger/ Rx http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/ http://akarnokd.blogspot.pe/2016/04/google-agera-vs-reactivex.html Clean Architecture https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

Slide 63

Slide 63 text

Gracias!!! @pablojohnson88

Slide 64

Slide 64 text

No content