Patrón MVC en Android

No existe un patrón MVC universalmente único. MVC es un concepto más que un marco de programación sólido. Puede implementar su propio MVC en cualquier plataforma. Siempre y cuando se adhiera a la siguiente idea básica, está implementando MVC:

• Modelo: Qué renderizar
• Vista: {[5] } Cómo renderizar
• Controlador: Eventos, entrada del usuario

También piénsalo de esta manera: Cuando programes tu modelo, el modelo no debería tener que preocuparse por renderizado (o código específico de la plataforma). El modelo diría a la vista, no me importa si su representación es Android o iOS o Windows Phone, esto es lo que deben representar. La vista solo manejaría el código de renderizado específico de la plataforma.

Esto es particularmente útil cuando se utiliza Mono para compartir el modelo con el fin de desarrollar aplicaciones multiplataforma.

Las acciones, vistas y actividades en Android son la forma de trabajar con la interfaz de usuario de Android y son una implementación del patrón model-view–viewmodel (MVVM) , que es estructuralmente similar (en la misma familia que) model–view–controller.

Hasta donde yo sé, no hay manera de salir de este modelo. Probablemente se puede hacer, pero es probable que pierda todo el beneficio que tiene el modelo existente y tenga que reescribir su propia capa de interfaz de usuario para hacerlo trabajo.

Después de algunas búsquedas, la respuesta más razonable es la siguiente:

MVC ya está implementado en Android como:

1. View = layout, recursos y clases integradas como Button derivadas de android.view.View.
2. Controlador = Actividad
3. Model = las clases que implementan la lógica de la aplicación

(Esto por cierto implica que no hay lógica de dominio de aplicación en la actividad.)

Lo más razonable para un pequeño desarrollador es seguir esto patrón y no tratar de hacer lo que Google decidió no hacer.

PS Tenga en cuenta que la actividad a veces se reinicia, por lo que no es lugar para los datos del modelo (la forma más fácil de provocar un reinicio es omitir android:configChanges="keyboardHidden|orientation" del XML y activar el dispositivo).

EDITAR

Podemos estar hablando de MVC, pero será por así decirlo FMVC, Marco--Modelo--Ver--Controller. El Framework (el sistema operativo Android) impone su idea del ciclo de vida de los componentes y eventos, y en la práctica el Controlador (Activity/Service/BroadcastReceiver) en primer lugar, es responsable de hacer frente a estos eventos impuestos por el Marco (como onCreate()). ¿Debe procesarse la entrada del usuario por separado? Incluso si debería, no puede separarlo, los eventos de entrada de usuario también provienen de Android.

De todos modos, menos código que no es específico de Android que poner en su Activity/Service/BroadcastReceiver, mejor.

No hay un solo patrón MVC al que puedas obedecer. MVC solo indica más o menos que no debe mezclar datos y vista, de modo que, por ejemplo, las vistas son responsables de mantener los datos o las clases que procesan datos afectan directamente a la vista.

Sin embargo, la forma en que Android trata con clases y recursos, a veces incluso se ve obligado a seguir el patrón MVC. Más complicado en mi opinión son las actividades que son responsables a veces de la vista, pero sin embargo actuar como un controlador en el mismo tiempo.

Si define sus vistas y diseños en los archivos XML, cargue sus recursos desde la carpeta res, y si evita más o menos mezclar estas cosas en su código, entonces de todos modos está siguiendo un patrón MVC.

El mejor recurso que encontré para implementar MVC en Android es este post :

Seguí el mismo diseño para uno de mis proyectos, y funcionó muy bien. Soy un principiante en Android, por lo que no puedo decir que esta sea la mejor solución.

Hice una modificación: instancié el modelo y el controlador para cada actividad en la clase application para que no se recreen cuando cambie el modo horizontal-vertical.

Puede implementar MVC en Android, pero no es "compatible de forma nativa" y requiere un cierto esfuerzo.

Dicho esto, yo personalmente tiendo hacia MVP como un patrón arquitectónico mucho más limpio para el desarrollo de Android. Y al decir MVP quiero decir esto:

También he publicado una respuesta más detallada aquí.

Después de jugar con los diversos enfoques para la implementación MVC/MVP en Android, se me ocurrió un patrón arquitectónico razonable, que descrito en este post: MVP y MVC Patrones arquitectónicos en Android.

Estoy de acuerdo con JDPeckham, y creo que XML por sí solo no es suficiente para implementar la parte UI de una aplicación.

Sin embargo, si considera la actividad como parte de la vista, implementar MVC es bastante sencillo. Puede anular Application (como devuelve getApplication() en Activity) y es aquí donde puede crear un controlador que sobreviva durante la vida útil de su aplicación.

(Alternativamente, puede usar el patrón singleton como sugiere la documentación de la solicitud)

La creación de la interfaz de usuario de Android mediante diseños, recursos, actividades e intentos es una implementación del patrón MVC. Por favor, consulte el siguiente enlace para obtener más información sobre esto - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

Espejo para el pdf

MVC-Arquitectura en Android Es Mejor Seguir Cualquier MVP lugar MVC en Android. Pero aún así, de acuerdo con la respuesta a la pregunta, esta puede ser la solución

Descripción y directrices

     Controller -
        Activity can play the role.
        Use an application class to write the
        global methods and define, and avoid
        static variables in the controller label
    Model -
        Entity like - user, Product, and Customer class.
    View -
        XML layout files.
    ViewModel -
        Class with like CartItem and owner
        models with multiple class properties
    Service -
        DataService- All the tables which have logic
        to get the data to bind the models - UserTable,
        CustomerTable
        NetworkService - Service logic binds the
        logic with network call - Login Service
Helpers -
        StringHelper, ValidationHelper static
        methods for helping format and validation code.
SharedView - fragmets or shared views from the code
        can be separated here

AppConstant -
        Use the Values folder XML files
        for constant app level

NOTA 1:

Aquí está la pieza de magia que puedes hacer. Una vez que haya clasificado la pieza de código, escriba una clase de interfaz base como, ITality e IService. Declarar métodos comunes. Ahora crear la clase abstracta BaseService y declare su propio conjunto de métodos y tenga separación de código.

NOTA 2: Si su actividad está presentando varios modelos, en lugar de escribir el código/lógica en la actividad, es mejor dividir las vistas en fragmentos. Entonces es mejor. Así que en el futuro, si se necesita más modelo para aparecer en la vista, agregue un fragmento más.

NOTA 3: La separación de código es muy importante. Cada componente en la arquitectura debe ser independiente no tener lógica dependiente. Si por casualidad tiene una lógica dependiente, entonces escriba una clase de lógica de asignación en el medio. Esto te ayudará en el futuro.

Aunque este post parece antiguo, me gustaría añadir los dos siguientes para informar sobre el desarrollo reciente en esta área para Android:

Android-binding - Proporcionar un marco que enabes el enlace de widgets de vista de Android al modelo de datos. Ayuda a implementar patrones MVC o MVVM en aplicaciones Android.

Roboguice - RoboGuice elimina las conjeturas del desarrollo. Inyecte su Vista, Recurso, Servicio del Sistema o cualquier otro objeto, y deja que RoboGuice se encargue de los detalles.

El patrón MVC de Android se implementa con sus clases Adapter. Reemplazan un controlador con un "adaptador"."La descripción del adaptador indica:

Un objeto Adapter actúa como un puente entre un AdapterView y datos subyacentes para esa opinión.

Solo estoy buscando en esto para una aplicación de Android que lee de una base de datos, así que no se lo bien que funciona todavía. Sin embargo, parece un poco como el Modelo-Vista-Delegado de Qt arquitectura, que afirman que es un paso adelante de un patrón MVC tradicional. Al menos en el PC, el patrón de Qt funciona bastante bien.

Controlador de vista de modelo (MVC)

Descripción:

• Cuando tenemos que principales grandes proyectos en el desarrollo de software, MVC se utiliza generalmente porque es una forma universal de organizar el proyecto.
• Los nuevos desarrolladores pueden adaptarse rápidamente al proyecto
• Ayuda en el desarrollo de grandes proyectos y multiplataforma también.

El patrón MVC es esencialmente este:

• Modelo: Qué mostrar. Esta puede ser la fuente de datos (por ejemplo: Servidor, Raw datos en la aplicación)
• Vista: Cómo se muestra. Este puede ser el xml. Por lo tanto, está actuando como un filtro de presentación. Una vista se adjunta a su modelo (o parte del modelo) y obtiene los datos necesarios para la presentación.
• Controlador: Manejo de eventos como la entrada del usuario. Esta es la actividad

Característica importante de MVC: Podemos modificar ya sea el Modelo o la Vista o el Controlador que aún no afecta los otros

• Digamos que cambiamos el color de la vista, el tamaño de la vista o la posición de la vista. Al hacerlo, no afectará al modelo o al controlador
• Digamos que cambiamos el modelo (en lugar de los datos obtenidos del servidor obtener datos de los activos) todavía no afectará a la vista y controlador
• Digamos que cambiamos el Controlador (Lógica en la actividad) no afectará el modelo y la vista

Creo que la explicación simplificada más útil está aquí: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf

De todo lo demás que he visto y leído aquí, la implementación de todas estas cosas hace que sea más difícil y no encaja bien con otras partes de Android.

Tener una actividad implementar otros oyentes ya es la forma estándar de Android. La forma más inofensiva sería agregar el Observador de Java como las diapositivas describen y agrupan el onClick y otros tipos de acciones en funciones que aún están en la Actividad.

La forma de Android es que la Actividad hace ambas cosas. Luchar contra él realmente no hace que extender o hacer codificación futura sea más fácil.

Estoy de acuerdo con el 2do post. Ya está implementado, pero no de la forma en que la gente está acostumbrada. Esté o no en el mismo archivo o no, ya hay separación. No hay necesidad de crear una separación adicional para que se ajuste a otros idiomas y sistemas operativos.

Cansado del desastre MVx en Android, recientemente he creado una pequeña biblioteca que proporciona un flujo de datos unidireccional y es similar al concepto de MVC: https://github.com/zserge/anvil

Básicamente, tienes un componente (activity, fragment y viewgroup). En el interior se define la estructura y el estilo de la capa de vista. También define cómo deben vincularse los datos a las vistas. Finalmente, puede enlazar oyentes en el mismo lugar.

Entonces, una vez que se cambian sus datos-el se llamará al método global "render ()" y sus vistas se actualizarán inteligentemente con los datos más recientes.

Aquí hay un ejemplo del componente que tiene todo dentro para compactar el código (por supuesto, el Modelo y el Controlador se pueden separar fácilmente). Aquí " count "es un modelo, el método view() es una vista, y" v -> count++ " es un controlador que escucha los clics del botón y actualiza el modelo.

public MyView extends RenderableView {
  public MyView(Context c) {
      super(c);
  }

  private int count = 0;

  public void view() {
    frameLayout(() -> {              // Define your view hierarchy
      size(FILL, WRAP);
      button(() -> {
          textColor(Color.RED);      // Define view style
          text("Clicked " + count);  // Bind data
          onClick(v -> count++);     // Bind listeners
      });
    });
  }

Con el modelo separado y el controlador se vería como:

button(() -> {
   textColor(Color.RED);
   text("Clicked " + mModel.getClickCount());
   onClick(mController::onButtonClicked);
});

Aquí, en cada clic de botón, el número se incrementará, luego se llamará a "render()" y el texto del botón se actualizará.

La sintaxis se vuelve más agradable si usas Kotlin: http://zserge.com/blog/anvil-kotlin.html. También, hay sintaxis alternativa para Java sin lambdas.

La biblioteca en sí es muy ligera, no tiene dependencias, no utiliza reflexión, etc.

(Descargo de responsabilidad: Soy el autor de esta biblioteca)

No hay una arquitectura MVC implementada, pero existe un conjunto de bibliotecas / ejemplos para implementar una arquitectura MVP (model–view–presenter).

Por favor, compruebe estos enlaces:

• Https://github.com/sockeqwe/mosby

• Https://github.com/android10/Android-CleanArchitecture

• Https://github.com/antoniolg/androidmvp

Google agregó un ejemplo de una arquitectura de Android MVP:

• https://github.com/googlesamples/android-architecture

He visto que muchas personas están diciendo MVC ya está implementado en Android, pero no es cierto. Android no sigue ningún MVC por defecto.

Porque a Google no le gusta imponer a la fuerza las restricciones de una implementación de MVC como iPhone, pero han dejado esta decisión en el usuario para usar la técnica MVC, porque en aplicaciones pequeñas o simples no tenemos necesidad de usar MVC, pero como la aplicación se complica y tendrá que modificar su código después del desarrollo completa, entonces viene una necesidad del patrón MVC en Android.

Proporciona una manera fácil de modificar el código y también ayuda en problemas no deseados. Esos vienen en patrones de diseño de Android simples. Si desea implementar MVC en Android, siga este enlace a continuación y disfrute de las técnicas de implementación de MVC en su proyecto.

Http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro /

De acuerdo con la explicación que el equipo de Xamarin explicó (en el MVC de iOS "Sé que parece raro, pero espera un segundo"):

• El modelo (datos o lógica de aplicación),
• La vista (interfaz de usuario), y
• El controlador (código detrás).

Puedo decir esto:

El modelo en Android es simplemente el objeto parcelable. La vista es el diseño XML, y el controlador es el (actividad + su fragmento).

*Esta es solo mi opinión, no de cualquier recurso o de un libro.

Cuando aplicamos MVC, MVVM, o Modelo de presentación a una aplicación Android, lo que realmente queremos es tener un proyecto estructurado claro y, lo que es más importante, más fácil para las pruebas unitarias.

Por el momento, sin un framework de terceros, normalmente tienes mucho código (como addXXListener(), findViewById(), etc.), que no añade ningún valor comercial.

Además, tienes que ejecutar pruebas unitarias de Android en lugar de las pruebas JUnit normales, que tardan años en ejecutarse y hacer la unidad pruebas poco prácticas. Por estas razones, hace algunos años iniciamos un proyecto de código abierto, RoboBinding - Un marco de trabajo de Presentación de enlace de datos para la plataforma Android.

RoboBinding le ayuda a escribir código de interfaz de usuario que es más fácil de leer, probar y mantener. RoboBinding elimina la necesidad de código innecesario como addXXListener o así, y cambia la lógica de la interfaz de usuario al Modelo de presentación, que es un POJO y puede ser probado a través de pruebas normales de JUnit. RoboBinding viene con más de 300 pruebas JUnit para garantizar su calidad.

Fue sorprendente ver que ninguno de los posts aquí respondió a la pregunta. Son demasiado generales, vagos, incorrectos o no abordan la implementación en Android.

En MVC, la capa View solo sabe cómo mostrar la interfaz de usuario (UI). Si se necesitan datos para esto, los obtiene de la capa Model. Pero la Vista NO pide directamente al modelo que encuentre los datos, lo hace a través del Controlador . Así que el Controlador llama al Model to provide the required data for the View . Una vez que los datos están listos, el Controlador informa a la Vista que los datos están listos para ser adquiridos del Modelo . Ahora la Vista puede obtener los datos del Modelo .

Este flujo se puede resumir de la siguiente manera:

Vale la pena señalar que la Vista puede conocer la disponibilidad de los datos en el Modelo ya sea a través de Controlador also también conocido como MVC pasivo or o observando los datos en el Modelo registrando observables en él, que es MVC activo .

En la parte de implementación, una de las primeras cosas que viene a la mente es que ¿qué componente de Android se debe usar para la vista ? Activity o Fragment ?

La respuesta es que no importa y ambos se pueden usar. La vista debería poder presentar la interfaz de usuario (UI) en el dispositivo y responder a la interacción del usuario con la interfaz de usuario. Tanto Activity como Fragment proporcionan los métodos requeridos para esto.

En la aplicación de ejemplo utilizada en este artículo He utilizado Activity para la capa View, pero Fragment también se puede usar.

La aplicación de ejemplo completa se puede encontrar en la rama 'mvc' de mi repositorio de GitHub aquí.

También he tratado con los pros y los contras de la arquitectura MVC en Android a través de un ejemplo aquí.

Para los interesados, he comenzado una serie de artículos sobre android app architecture aquí en los que comparo las diferentes arquitecturas, es decir, MVC, MVP, MVVM, para el desarrollo de aplicaciones Android a través de una aplicación de trabajo completa.

Modelo-Vista-Controlador en Android Alrededor de 2011, cuando Android comenzó a ser cada vez más popular, las preguntas de arquitectura aparecieron naturalmente. Desde MVC fue uno de los patrones de interfaz de usuario más populares en ese momento, los desarrolladores trataron de aplicarlo a Android también.

Modelo El Modelo representa un conjunto de clases que describen la lógica de negocio, es decir, el modelo de negocio, así como las operaciones de acceso a datos, es decir, el modelo de datos. También define reglas de negocio para los datos significa cómo se pueden cambiar y manipular los datos.

Vista La vista representa los componentes de la interfaz de usuario. Solo es responsable de mostrar los datos que se reciben del controlador como resultado. Esto también transforma los modelos en UI.

Controlador El Controlador es responsable de procesar las solicitudes entrantes. Recibe la entrada de los usuarios a través de la vista, luego procesa los datos del usuario con la ayuda del Modelo y pasa los resultados a la vista. Normalmente, actúa como coordinador entre la Visión y el Modelo.

En otra palabra

Modelos: Proveedores de contenido. Administradores de datos que son la forma recomendada de intercambio de datos entre aplicaciones.

Vistas: Actividades. Este es el componente principal de la interfaz de usuario de la aplicación. Cada pantalla individual de una aplicación Android se deriva de la clase Activity Java (android.app.Actividad). Son contenedores para Vistas (android.vista.Vista).

Controladores: Servicios. Estos son componentes en segundo plano que se comportan como demonios UNIX y servicios Windows. Se ejecutan de forma invisible y realizan un procesamiento desatendido continuo.