Este artículo describe la teoría detrás del modelo de diseño Modelo – Vista –Modelo (MVVM) y sus componentes. Si quieres experimentar con ella de forma práctica, abre un proyecto antiguo con código de espagueti. Si no tiene uno, puede obtener uno de GitHub. Luego, intente usar los componentes MVVM introducidos en este artículo.

De alguna manera, el desarrollo de software no ha cambiado mucho en la última década. Los desafíos básicos siguen siendo los mismos:

  • Escribir código limpio.
  • Tener una arquitectura flexible.
  • Probar el código.
  • Crear una excelente experiencia de usuario.
  • Desarrollar características más rápido de lo que la administración de productos puede imaginar. ellos. :]

Todos estos problemas tenían una solución para cuando Android entró en el mercado. Los desarrolladores de aplicaciones web y de escritorio ya tenían una base de conocimientos para escribir interfaces de usuario. Esas soluciones también funcionaron para Android, pero estaban lejos de ser ideales.

Android se basó inicialmente en Java y las aplicaciones se implementaron normalmente utilizando MVC (Controlador de vista modelo). Diez años después, está Kotlin … y MVVM. Fue un largo viaje durante esos diez años, ¡así que vamos a ponernos al día!

Comenzando

Entendiendo los patrones de diseño

Los patrones de diseño representan bloques arquitectónicos reutilizables dentro de un programa. Los buenos bloques de construcción en su código:

  • Dirigirán a código limpio.
  • Resolverán problemas comunes usando paradigmas comunes, facilitando que varios desarrolladores trabajen en el mismo proyecto.
  • Serán robustos y bien probados. [19659004] Ser más fácil de entender que el código de forma libre.

Imagínate entrar a un baño. De un vistazo, puede identificar un inodoro. Sabes lo que hace y cómo usarlo. Entonces reconoces el fregadero. Con suerte, no es necesario que lo pinches y pruebes lo que hace. El patrón de una bañera también es algo que ya sabe.

No todos los lavamanos son iguales. Por ejemplo, en el Reino Unido, es posible que encuentre un fregadero con tuberías separadas para agua fría y caliente. Si bien es inusual para el resto del mundo, aún sabría cómo usar el fregadero.

 Paradigmas de diseño: Reino Unido se hunde contra el mundo

Con los patrones de diseño, los desarrolladores pueden aplicar soluciones conocidas a problemas existentes.

Uso de patrones de diseño arquitectónico

El concepto de patrones de diseño apareció en un libro famoso con el mismo nombre, que describía tres categorías para estos patrones: [19659003] Creational

  • Structural
  • Behavioral
  • Una cuarta categoría, los patrones de diseño arquitectónico, ayuda a los desarrolladores a seguir un estilo arquitectónico. Le ayudan a separar diferentes componentes dentro de un proyecto.

    En el mundo de la empresa, uno de los patrones de diseño más populares es el patrón de "tres niveles" o "tres capas". Otro útil es el modelo “cliente-servidor”. Las aplicaciones móviles también se benefician de muchos de estos patrones, pero algunos funcionan mejor que otros.

    MVVM es un patrón de diseño arquitectónico que funciona bien para aplicaciones móviles.

    Patrones comunes de diseño arquitectónico en Android [19659011] MVC y MVP

    Model-View-Controller (MVC) y Model-View-Presenter (MVP) son dos patrones de diseño que son muy similares y tienen mucho en común con MVVM. Google no presionó para un solo patrón de diseño para Android al principio. Sin embargo, la documentación utiliza MVC más a menudo que no. Este patrón tiene tres componentes: Modelo, Vista y Controlador.

    En MVC, la comunicación entre los componentes parece un triángulo:

    • La vista muestra el estado del modelo,
    • El controlador maneja la entrada de la vista.
    • El modelo almacena el resultado que sale del controlador .

     Diagrama de flujo de MVC

    El MVC puede ser difícil de probar debido a este modelo de comunicación. Navegar por el código también puede ser tedioso. La lógica de negocios debe dividirse entre el Controlador y el Modelo, pero a veces la lógica se filtra en la Vista.

    Esto crea un tipo de acoplamiento que tiene un efecto espiral. Al final, alienta a los desarrolladores de Android a colocar la mayor parte del código en una clase de Actividad o Fragmento. El problema tiene un apodo: "controlador de vista masiva" . Irónicamente, este problema tiene las mismas iniciales que MVC. Pero hace que la aplicación sea difícil de mantener y casi imposible de probar.

    A pesar de esto, el patrón sigue siendo lo suficientemente bueno para proyectos pequeños. Pero hay mejores patrones disponibles.

    Nota : ¿Alguna vez has visto una actividad o un fragmento que supera las 1000 líneas de código? Eso es un controlador de vista masiva! Es ese archivo que siempre genera conflictos de fusión. Tiene un 0% de cobertura de prueba, y todos evitan cambiarlo.

    Por ejemplo, MVP cambia el "controlador" en MVC entre el modelo y la vista, y lo denomina presentador. Esto ayuda a concentrar la lógica de negocios en el presentador. Por otro lado, el Presentador también es responsable de adaptar los datos en el modelo para mostrarlos en la Vista. Por esta razón, el Presentador a veces se denomina "controlador supervisor" .

    La diferencia entre MVC y MVP no es enorme, pero el desacoplamiento del modelo de la vista tiene ventajas. Permite una mayor flexibilidad y ofrece una interfaz de usuario más sencilla y pruebas de unidad.

     Diagrama de flujo de MVP

    El problema es que el presentador aún está acoplado tanto con el modelo como con la vista. ¡Es hora de dar un paso más por el camino de desacoplamiento!

    Tomando el siguiente paso: MVVM

    En comparación con MVP, MVVM desacopla la vista del ViewModel usando algo llamado Binder . ViewModel no sabe acerca de la vista o las vistas suscritas para los cambios. The Binder entrega los cambios de ViewModel a View. Esto permite desarrollar y probar la Vista de forma aislada sin romper el ViewModel.

    Piénsalo: ¿debería tu UI influir en la lógica de negocios? Tienes razón, ¡no debería!

    Este patrón tampoco es perfecto, pero es muy bueno. Por lo tanto, vamos a profundizar en él.

    Descripción de los componentes de MVVM

    MVVM es ahora uno de los patrones más populares, ya que ha tenido mucho tiempo para madurar. La comunidad web adoptó el patrón después de que el equipo de Microsoft lo formalizara en 2005. Finalmente se abrió camino en cada marco basado en UI.

    Una de las principales ventajas de MVVM es que ofrece la cantidad correcta de desacoplamiento. Otra cosa buena es que la curva de aprendizaje es similar a los otros patrones.

    MVVM tiene tres componentes principales: Modelo, Vista y Modelo de Vista.

     Diagrama de flujo de MVVM

    A diferencia de MVP y MVC , hay un cuarto componente: la carpeta. Este es el mecanismo que vincula las Vistas a los ViewModels.

    El archivador generalmente es manejado por la plataforma o una biblioteca de terceros, por lo que el desarrollador no tiene que escribirlo. Para Android, tiene la biblioteca DataBinding a su disposición.

    Definición del rol de la vista

    En MVVM, la vista es muy liviana porque casi no tiene lógica. La vista es todo lo relacionado con la interfaz de usuario. En Android, esto suele ser una actividad o un fragmento. Su función es mostrar todo lo que recibe de ViewModel y reenviarle la entrada. ¡Es tan simple como eso!

    Aquí hay una vista de ejemplo en una clase de Android llamada MainFragment :

     class MainFragment: Fragment () {
    
      objeto compañero {
        fun newInstance () = MainFragment ()
      }
    
      private var selectedUser: User? = nulo
      privado lateinit var viewModelBasic: BasicMainViewModel
    
      anular la diversión enCreateView (
        inflater: LayoutInflater, contenedor: ViewGroup?
        savedInstanceState: Bundle?
      ): Ver {
        devolver inflater.inflate (R.layout.main_fragment, container, false)
      }
    
      anular la diversión onActivityCreated (savedInstanceState: Bundle?) {
        super.onActivityCreated (savedInstanceState)
        viewModelBasic = BasicMainViewModel ()
        viewModelBasic.uiModel.observe (this, Observer  {uiModel ->
          // actualizar la interfaz de usuario
        })
      }
    
      diversión onDeleteButtonClicked (v: View) {
        viewModelBasic.deleteUser (selectedUser)
      }
    }
    

    En onActivityCreated () se crea una instancia del objeto ViewModel desde la clase BasicMainViewModel . En el controlador onDeleteButtonClicked () se ve una interacción típica entre View y ViewModel: el fragmento pasa un evento de IU, el usuario hace clic en el botón de eliminación, para ver ViewModel.

    Definición del modelo [19659012] El modelo es un componente liviano que no conoce ningún otro componente. Su función es almacenar el estado del sistema y dejar que el ViewModel lo consulte.

    El modelo se crea a menudo utilizando un patrón Repository . Los Objetos de acceso a datos (DAO) que proporcionan operaciones Crear-Leer-Actualizar-Eliminar (CRUD) pueden ayudar al repositorio a completar las solicitudes. Para Android, el equipo de Google lanzó la biblioteca Room Persistence dentro de Jetpack para este propósito.

    Una interfaz de modelo simple podría tener este aspecto:

     repositorio de interfaz {
    
      inserción divertida (usuario: usuario)
    
      fun getAll (): LiveData <List >
    
      divertido borrar (usuario: usuario)
    
      actualización divertida (usuario: usuario)
    }
    

    La interfaz proporciona Create ( insert () ), Read ( getAll () ), Update ( update () ) y Delete () y Delete () eliminar () ) operaciones en el modelo.

    Verás una implementación de ejemplo con Room más adelante en el artículo.

    Encontrar el lugar de ViewModel's en MVVM

    El ViewModel es la pieza central de MVVM. Tiene toda la lógica de negocios y parte de la lógica de visualización en ella.

    El ViewModel necesita adaptar la información en el Modelo para que se muestren las Vistas. El ViewModel también transforma los eventos de entrada en datos para que el Modelo los almacene. Si algo sale mal, ¡mire primero en ViewModel!

    Esto es lo que BasicMainViewModel puede parecer:

     clase BasicMainViewModel (depósito de valores privados: Repositorio): ViewModel () {
      val uiModel: MutableLiveData  por perezoso {
        MutableLiveData  ()
      }
    
      fun generaReport () {
        // TODO Añadir cómputo de informe complicado
      }
    
      divertido deleteUser (usuario: usuario?) {
        deleteUserFromRepository (usuario)
        uiModel.value? .userList? .remove (usuario)
      }
    
      fun deleteUserFromRepository (user: User?) {
        if (usuario! = nulo) {repository.delete (usuario)}
      }
    }
    

    El ViewModel aquí toma un Repositorio en su constructor para que pueda comunicarse con el Modelo. Y proporciona funciones que calculan datos para su visualización ( generateReport () ) y permiten la eliminación de datos del modelo.

    Mejora de la capacidad de prueba

    La escritura de código verificable es una característica de un buen desarrollador. Después de leer este artículo, serás tú. :]

    Cómo ocultar las interfaces y la inyección de dependencias

    Lo más fácil que puede hacer con su código para mejorar la capacidad de prueba es ocultarlo detrás de una interfaz. Esto significa que su clase implementará una interfaz que expone solo los métodos públicos. Los métodos públicos forman un tipo de Interfaz de programación de aplicaciones (API).

    Deberá pensar dos veces en lo que expone para su API. Una vez que algo está en la API, otras partes del código lo usarán. La API es como un contrato que los métodos no pueden cambiar. La ventaja es que puede cambiar la implementación sin romper nada.

    Por ejemplo, la clase BasicMainViewModel debe esconderse detrás de una interfaz como esta:

     interfaz MainViewModel {
      diversión genera Informe ()
      divertido deleteUser (usuario: usuario?)
      divertido deleteUserFromRepository (usuario: ¿Usuario?)
    }
    

    Nota : ¿Ha notado el repositorio en el constructor ? Esa es una interfaz también. Este es un ejemplo de "inyección de dependencia": permitir que otros objetos "inyecten" un Repositorio en el ViewModel.

    Deberá crear interfaces para todos los componentes de MVVM, no solo para ViewModel.

    ¿Pero cómo puede evitar que los usuarios de su código utilicen la implementación? Hay un par de formas para crear esta restricción.

    Un método es hacer que la clase de implementación sea interna . Luego, proporcione una Fábrica pública que siempre devuelva una referencia al tipo de Interfaz. De esta manera, la implementación nunca abandona el módulo.

    Considere este BasicLocationProvider que podría usarse dentro de un ViewModel:

     clase BasicLocationProvider: LocationProvider {
      Ubicación de val: Ubicación? = nulo
    
      diversión refreshLocation () {
        // TODO activar una actualización de ubicación en Android
      }
    }
    

    Este código almacena y expone una ubicación e incluye un método para actualizar esa ubicación. Debe protegerlo de los desarrolladores molestos que usarán la implementación en todo el código. Primero, declare la interfaz:

     interfaz LocationProvider {
      diversión refreshLocation ()
      Ubicación de val: Ubicación?
    }
    

    Luego, asegúrese de que la clase implemente la interfaz y declare interna :

     clase interna BasicLocationProvider: LocationProvider {
      anular ubicación val: ubicación?
        get () = nulo
    
      anular la diversión refreshLocation () {
        // TODO activar una actualización de ubicación en Android
      }
    }
    

    Por último, cree un objeto Factory que ofrezca un LocationProvider a cualquier persona interesada:

     objeto LocationProviderFactory {
      val locationProvider: LocationProvider =
        BasicLocationProvider ()
    }
    

    Con estas modificaciones, la implementación de BasicLocationProvider está bien protegida de los usuarios de la clase.

    La mayoría de los marcos de Inyección de Dependencia tienen una forma más fácil de hacer esto. Por ejemplo, en Dagger, puede exponer @Module pero mantener las clases de implementación internas.

    Cuando se trata de pruebas, los constructores recibirán objetos simulados que implementan las interfaces. Esto hace que la prueba del código sea más fácil. Los marcos de prueba y las bibliotecas le permiten crear fácilmente objetos simulados para controlar la entrada.

    Prueba de cada componente

    Ahora tome un momento para revisar cómo prueba cada uno de los componentes cubiertos hasta ahora.

    • Vista : Este es el componente más simple en MVVM. No conoce ningún otro componente y no controla nada. Probar la vista también es simple. Primero, proporcione algunos datos controlados como lo haría un ViewModel. Luego, verifica los resultados visuales. ¡Voilà!
    • Modelo : Esto también suele ser fácil de probar. El modelo no tiene conocimiento sobre el mundo externo, por lo que tiene un control completo sobre él. Todo lo que tiene que hacer es llamar a los métodos de "ejecución" en un objeto Modelo y luego verificar los resultados con las llamadas al método de consulta.
    • ViewModel : Probar este componente es un poco complicado. Tienes que burlarte del modelo y los métodos de llamada en el ViewModel. Después de eso, verifique que los datos disponibles para la Vista sean correctos. También puede verificar que los métodos llamados en el modelo simulado son correctos. Si el ViewModel depende de otros componentes, también debe burlarse de ellos. Sin embargo, probar el ViewModel es más fácil que probar los componentes de cualquiera de los patrones de diseño mencionados anteriormente.

    Prácticas recomendadas en Pruebas MVVM

    La prueba es sencilla cuando se aplica un buen patrón. Hay algunos secretos para probar MVVM, pero aquí está el mejor enfoque:

    • Comience a probar el modelo de vista . Prueba cada uno de los métodos públicos, pasando por tantos casos como puedas. No solo los caminos obvios, sino también los casos reales de borde que está seguro de que nunca sucederán. Confía en mí: los usuarios y los futuros desarrolladores alcanzarán esos casos de vanguardia. :]
    • Si algo no se puede probar, envuélvalo. Cree una interfaz que contenga todos los métodos que necesita de la clase no comprobable. Cree una clase que implemente esa interfaz y cree una instancia de la clase no comprobable que quería usar dentro de ella. Luego, dentro de tu clase, llama a los métodos de la clase no comprobable. Esto se denomina Patrón de diseño de proxy .

    Ahora tiene una interfaz que puede usar en su aplicación que es fácilmente reemplazable con un objeto simulado. De esta manera, puede "lanzar" dependencias no verificables fuera de su clase.

    Debes mantener los componentes del marco del SDK de Android y las bibliotecas externas a la distancia de los brazos. Al envolverlos de esta manera, se asegura de no distribuir las dependencias en todo el código. Utiliza la interfaz que has creado y mantienes los marcos y las bibliotecas en un solo lugar.

    Mantén tus pruebas cortas y asegúrate de que sean repetibles.

    No es tu responsabilidad probar el marco. No puedes controlar el marco, por lo que no tiene sentido probarlo. Si su modelo solo reenvía métodos a otra biblioteca como Room, no hay mucho que hacer en términos de prueba. Puede agregar pruebas una vez que su Modelo necesite hacer otra cosa, como filtrar o computar.

    Pruebe su Vista con diferentes configuraciones de dispositivos. Simula el ViewModel para generar todos los estados que una Vista podría recibir.

    Agregando los Componentes de Arquitectura de Android

    Hasta ahora, has visto los componentes principales de MVVM y has discutido cómo probarlos. Pero ¿qué pasa con la capa Binder? El SDK de Android proporciona Enlace de datos para implementar un cuaderno.

    Uso de Enlace de datos

    El enlace de datos es una técnica que conecta las fuentes de datos con los consumidores y las mantiene sincronizadas. La biblioteca de enlaces de datos de Android permite al desarrollador mantener la interfaz de usuario en los archivos XML de diseño y generar código a partir de ellos. La biblioteca también hace el trabajo pesado de sincronizar la Vista con los datos que vienen de ViewModel.

    Para agregar enlace de datos a su proyecto, debe agregar lo siguiente al archivo build.gradle de su aplicación:

     android {
      ...
      el enlace de datos {
        enabled = true
      }
    }
    

    Ahora, sus XML de diseño deberán tener la siguiente estructura:

    
        
            
        
         
    
    

    Para transformar XML de la estructura predeterminada a uno de enlace de datos, debe ajustar el diseño raíz, en este caso un ConstraintLayout dentro de una etiqueta layout . Luego, en la parte superior del diseño, justo dentro de la etiqueta layout deberá agregar una etiqueta data que contiene los objetos que se utilizan para el enlace.

    Nota : una vez que haya habilitado el enlace de datos y sincronice su proyecto, Android Studio ofrece un acceso directo para transformar cualquier diseño en uno de enlace de datos. Seleccione el elemento raíz de su diseño y presione opción + retorno . Aparece una ventana emergente con la opción "Convertir a diseño de enlace de datos". Seleccione eso y el diseño agregará las etiquetas datos y automáticamente.

    La interfaz de usuario reflejará cada cambio en el ViewModel a través de las variables dentro de los datos etiqueta. En el ejemplo, hay una variable llamada usuario .

    Debe indicar a los elementos de la interfaz de usuario qué propiedades necesitan. Por ejemplo:

    
       
           
       
       
           
           
       
    
    
    

    Aquí hay dos vistas de texto que están vinculadas a los valores user.firstName y user.lastName .

    Aún deberá agregar diferentes oyentes a su interfaz de usuario y reenviar esos eventos al ViewModel. Por suerte para usted, la biblioteca de DataBinding también puede ayudar con eso. La biblioteca genera un objeto de enlace para acceder a los elementos de la interfaz de usuario:

     anula fun onCreate (savedInstanceState: Bundle?) {
      super.onCreate (savedInstanceState)
      enlace val: MyLayoutBinding = MyLayoutBinding.inflate (layoutInflater)
    }
    

    En lo anterior, crea un valor de binding utilizando el objeto de enlace generado.

    Agregar el propio ViewModel de Android

    Crear tu propia clase de ViewModel es genial, pero Android Jetpack ofrece más. El ViewModel de Jetpack tiene su propio ciclo de vida, administrado por la biblioteca. Esto significa que la biblioteca conservará ViewModel cuando el sistema operativo vuelva a crear la Actividad. Tampoco necesita sincronizar el estado de la interfaz de usuario.

    Para comenzar, cree una clase que herede de Viewpackel de Jetpack:

     clase ProfileViewModel: ViewModel () {
      val uiModel: MutableLiveData  por perezoso {
        MutableLiveData  ()
      }
    }
    

    Luego, en su Actividad o Fragmento, agregue esto:

     val model = ViewModelProviders.of (this) .get (ProfileViewModel :: class.java)
    

    Si la actividad se recrea, recibe la misma instancia ProfileViewModel que antes. Cuando la actividad del propietario finaliza, el marco llama al método onCleared () del objeto ViewModel. Ahí es cuando realmente se destruye el ViewModel.

    Acoplamiento suelto con LiveData

    Jetpack también proporciona la clase LiveData . LiveData es solo el patrón Observer mejorado con la conciencia del ciclo de vida. La mayoría de los problemas en el desarrollo de Android provienen del manejo del ciclo de vida. Los desarrolladores que usan LiveData tienen menos probabilidades de tener:

    • Fugas de memoria
    • Se bloquea
    • Interfaz de usuario obsoleta
    • Para usar LiveData, primero cree su objeto LiveData en su ViewModel:

     clase ProfileViewModel: ViewModel ()
      val uiModel: MutableLiveData  por perezoso {
        MutableLiveData  ()
      }
    }
    

    Después de eso, conecta tu Vista a este LiveData. En su Actividad o Fragmento, después de haber creado el ViewModel, agregue esto:

     viewModel.uiModel.observe (this, Observer  {uiModel ->
      // actualizar la interfaz de usuario
    })
    

    La base de datos en la sala

    La base de datos que analizamos anteriormente llamada Sala también es un componente Jetpack. Usar Room en tu aplicación de Android es sencillo. Hay tres tipos de clases que necesita escribir:

    • Entidades
    • Objetos de acceso a datos
    • Bases de datos

    Entidades

    Las entidades son POJOs (Plain-Old-Java-Objects) ) con anotaciones para los nombres de columna y una clave principal:

     @Entity
    clase de datos Usuario (
      @PrimaryKey var uid: Int,
      @ColumnInfo (name = "first_name") var firstName: String?
      @ColumnInfo (name = "last_name") var lastName: String?
    )
    

    Objetos de acceso a datos

    Por lo general, cada entidad tiene su propio objeto de acceso a datos (DAO). El DAO implementa las operaciones CRUD, así como otros métodos útiles.

     @Dao
    interfaz UserDao {
      // Crear
      @Insertar
      inserción divertida (usuario: usuario)
    
      // leer
      @Query ("SELECT * FROM usuario")
      fun getAll (): List 
    
      // Actualizar
      @Actualizar
      actualización divertida (usuario: usuario)
    
      // Borrar
      @Borrar
      divertido borrar (usuario: usuario)
    }
    

    Aquí, UserDao ha recibido cada una de las operaciones CRUD etiquetadas con la anotación correspondiente.

    Lo mejor de los componentes de Jetpack es que funcionan bien juntos. Por ejemplo, Room también puede devolver LiveData objetos.

     // Leer
    @Query ("SELECT * FROM usuario")
    fun getAll (): LiveData <List >
    

    Genial, ¿eh? Este método es consciente del ciclo de vida y propagará los cambios de manera reactiva.

    Luego, para usar Room, debe crear la base de datos.

    Base de datos

    La interfaz de la base de datos necesita saber qué entidades que tendrá. Esto le permite a Room generar las clases y métodos apropiados.

     @Database (entidades = arrayOf (Usuario :: clase), versión = 1)
    clase abstracta MvvmDatabase: RoomDatabase () {
      abstracto divertido userDao (): UserDao
    }
    

    Room también maneja el control de versiones de su base de datos. Para eso es el segundo parámetro versión . Le ayudará a ejecutar migraciones cuando actualice la base de datos.

    Por último, debe inicializar la base de datos cuando se inicie la aplicación:

     val db = Room.databaseBuilder (
      aplicaciónContexto,
      MvvmDatabase :: class.java, "mvvm-article"
    ).construir()
    

    Le proporciona al constructor un contexto, la clase de base de datos y un nombre para el archivo de la base de datos, por ejemplo. "Mvvm-article".

    Buscando más

    MVVM no es el final de la historia para los patrones de diseño arquitectónico. Hay muchos otros patrones que son útiles en Android, especialmente a medida que crece el tamaño de su aplicación.

    Arquitectura limpia

    En 2012, se desarrolló el concepto de Arquitectura limpia . Desde entonces, cada comunidad marco ha tratado de incluir una variación de la misma.

    Este concepto tiene cuatro capas:

    • Entidades
    • Casos de uso
    • Adaptadores de interfaz
    • Marcos y controladores
      • Arquitectura limpia separa el código incluso mejor que MVVM. Eso no significa que MVVM no sea bueno, pero no es necesariamente tan "limpio" como podría ser. Por ejemplo, el modelo en MVVM a veces puede contener adaptadores y marcos. Pero en Arquitectura limpia, estos están separados.

         arquitectura limpia por el diagrama del tío Bob

        Lo más importante que se debe recordar en la arquitectura limpia es La Regla de dependencia . Esta regla dice que las dependencias del código fuente solo pueden apuntar hacia adentro en el diagrama de arriba, hacia el centro. Nada en un círculo interno puede saber nada sobre algo en un círculo exterior.

        VIPER

        VIPER es un patrón de diseño que la comunidad iOS desarrolló para sus proyectos. Es su forma de implementar Arquitectura Limpia en iOS.

        VIPER significa: Vista, Interactor, Presentador, Entidad, Enrutador.

        Como puede ver, hay algunos componentes nuevos que aparecen en este acrónimo. También sugiere que VIPER es un descendiente de MVP, no de MVVM.

        De hecho, puedes pensar en VIPER como MVP con un Interactor y un Router.

        El Interactor maneja parte de las responsabilidades del Presentador en MVP. La lógica de negocios se mueve al Interactor, dejando los eventos de la IU y la pantalla al Presentador.

        Sin embargo, esto deja un problema con la Vista. La Vista aún maneja todo el enrutamiento entre los módulos. Ahí es donde entra el Router.

         Diagrama de flujo de patrón de diseño de VIPER

        En Android, tener un Router para manejar la navegación fue complicado. El desarrollador no puede crear instancias de actividad, porque el marco lo hace. Existen soluciones alternativas para que también se pueda crear un enrutador con instancias de actividad. Pero Google recientemente anunció mejoras en Fragmentos en la Biblioteca de Soporte y recomienda su uso, y Fragmentos pueden ser instanciados por el desarrollador.

        Combinado con una estructura de la aplicación Actividad única el Router puede ocupar el lugar que le corresponde en el patrón de diseño VIPER para Android. Con Fragmentos, los enrutadores pueden tener total poder sobre la navegación a través de módulos.

        ¿A dónde ir desde aquí?

        ¡Esa es una gran cantidad de información que ha cubierto en este artículo!

        Ahora tiene una buena comprensión de qué son los patrones de diseño en el desarrollo de software, con un enfoque en los patrones de diseño arquitectónico.

        Conoces los patrones más importantes que existen y las debilidades de cada uno. Y lo más importante de todo: ahora sabe cómo implementar MVVM, cómo probarlo y cómo utilizar los Componentes de Arquitectura de Android de Android Jetpack para aprovechar al máximo MVVM.

        Buen trabajo para mantenerse al día con todos estos patrones y componentes!

        Para profundizar más en MVVM, puedes ver el curso de video MVVM en Android . Aprenderá más sobre cada uno de los componentes de MVVM y podrá practicar el patrón de diseño en pequeños desafíos.

        Si desea saber más acerca de los componentes de Google que pueden ayudarlo a aprovechar al máximo MVVM, lea el Componente de la arquitectura de Android: tutorial de iniciación y todos los screencasts relacionados con ellos.

        Para obtener más información sobre la inyección de dependencia, puede ver el Dependency Injection with Koin screencast. Si prefiere Dagger2, puede leer Inyección de dependencia en Android con Dagger2 y Kotlin . O vea los screencasts Comenzando con Dagger y Dagger Network Injection .

        A pesar de que está basado en iOS, el libro Design Patterns by Tutorials abarca muchos de los Patrones mencionados en este artículo.

        Finalmente, los patrones de diseño realmente no cambian mucho de una plataforma a otra; solo los ejemplos de código específicos y la implementación pueden variar. Asegúrese de consultar el próximo libro Advanced App Architecture para Android para obtener más detalles sobre MVP, MVVM y otros patrones arquitectónicos en Android.

        Si tienes alguna pregunta o comentario, únete a la discusión del foro a continuación.


    READ MORE - CLICK HERE

    www.Down.co.ve


    from Down.co.ve http://bit.ly/2G8UQOy
    via www.Down.co.ve