Patrón MVC en Android

¿Es posible implementar el patrón model-view-controller en Java para Android?

¿O ya está implementado a través de Actividades? ¿O hay una mejor manera de implementar el patrón MVC para Android?

En Android no tienes MVC, pero tienes lo siguiente:

  • Usted define su interfaz de usuario en varios archivos XML por resolución, hardware, etc.
  • Define sus recursos en varios archivos XML por configuración regional, etc.
  • Extiende clases como ListActivity , TabActivity y hace uso del archivo XML por inflaters .
  • Puede crear tantas clases como desee para su lógica comercial.
  • Ya se han escrito muchos Utils para usted: DatabaseUtils, Html.

No hay un patrón MVC universalmente único. MVC es un concepto en lugar de un marco de progtwigción sólido. Puede implementar su propio MVC en cualquier plataforma. Siempre y cuando te apegues a la siguiente idea básica, estás implementando MVC:

  • Modelo: qué renderizar
  • Ver: Cómo renderizar
  • Controlador: eventos, entrada del usuario

También piénselo de esta manera: cuando programe su modelo, el modelo no debería tener que preocuparse por el procesamiento (o el 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 necesito que muestre. La vista solo manejaría el código de representación específico de la plataforma.

Esto es particularmente útil cuando usa 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) modelo-vista -controlador.

Según mi leal saber y entender, no hay forma de salir de este modelo. Probablemente se puede hacer, pero es probable que pierda todos los beneficios que tiene el modelo existente y tenga que volver a escribir su propia capa de interfaz de usuario para que funcione.

Después de buscar, la respuesta más razonable es la siguiente:

MVC ya está implementado en Android como:

  1. View = diseño, recursos y clases integradas como Button derivado de android.view.View .
  2. Controlador = Actividad
  3. Modelo = 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 desarrollador pequeño es seguir este patrón y no intentar hacer lo que Google decidió no hacer.

Nota: la actividad a veces se reinicia, por lo que no es un 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 su dispositivo).

EDITAR

Podemos estar hablando de MVC , pero será así para decir FMVC , Framework – Model – View – Controller . El Framework (el sistema operativo Android) impone su idea del ciclo de vida de los componentes y eventos relacionados, y en la práctica el Controlador ( Activity / Service / BroadcastReceiver ) es en primer lugar responsable de hacer frente a estos eventos propuestos por el Framework (como onCreate () ) . ¿La entrada del usuario debe procesarse por separado? Incluso si fuera necesario, no puede separarlo, los eventos de entrada del usuario también provienen de Android.

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

No hay un patrón MVC único al que puedas obedecer. MVC simplemente afirma más o menos que no debe mezclar datos y ver, por lo que, por ejemplo, las vistas son responsables de almacenar datos o las clases que están procesando datos están afectando directamente a la vista.

Pero, sin embargo, la forma en que Android maneja las clases y los recursos, a veces incluso te obligan a seguir el patrón de MVC. Más complicado en mi opinión son las actividades que a veces son responsables de la vista, pero que sin embargo actúan como un controlador al 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 seguirá de todos modos un patrón MVC.

El mejor recurso que encontré para implementar MVC en Android es esta publicación :

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

Hice una modificación: creé una instancia del modelo y del controlador para cada actividad en la clase de aplicación para que no se vuelvan a crear cuando cambie el modo paisaje-retrato.

Puede implementar MVC en Android, pero no es “compatible de forma nativa” y requiere un poco de esfuerzo.

Dicho esto, personalmente me inclino por MVP como un patrón arquitectónico mucho más limpio para el desarrollo de Android. Y al decir MVP me refiero a esto:

enter image description here

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

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

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

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

(Alternativamente puede usar el patrón singleton como lo sugiere la documentación de la aplicación)

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

espejo para el pdf

MVC- Architecture en Android Es mejor seguir cualquier MVP MVC en Android. Pero aún de acuerdo con la respuesta a la pregunta, esta puede ser la solución

Ingrese la descripción de la imagen aquí

Descripción y Pautas

  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:

Ahora 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, IEntity e IService. Declarar métodos comunes. Ahora crea la clase abstracta BaseService y declara tu propio conjunto de métodos y separa el código.

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

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

Aunque esta publicación parece ser antigua, me gustaría agregar las dos siguientes para informar sobre el desarrollo reciente en esta área para Android:

android-binding : proporciona un marco que permite enlazar los widgets de vista de Android con el modelo de datos. Ayuda a implementar patrones MVC o MVVM en aplicaciones de Android.

roboguice – RoboGuice elimina las conjeturas del desarrollo. Inyecte su vista, recurso, servicio del sistema o cualquier otro objeto, y deje que RoboGuice se encargue de los detalles.

El patrón MVC de Android se implementa con sus clases de Adaptador . Reemplazan un controlador con un “adaptador”. La descripción del adaptador dice:

Un objeto Adaptador actúa como un puente entre un AdapterView y los datos subyacentes para esa vista.

Solo estoy buscando una aplicación de Android que lea de una base de datos, así que no sé qué tan bien funciona todavía. Sin embargo, parece un poco como la architecture Model-View-Delegate de Qt, que afirman es un paso adelante de un patrón MVC tradicional. Al menos en la PC, el patrón de Qt funciona bastante bien.

Modelo View Controller (MVC)

enter image description here


Descripción:

  • Cuando tenemos que realizar grandes proyectos en el desarrollo de software, generalmente se usa MVC porque es una forma universal de organizar los proyectos.
  • 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 esto:

  • Modelo: Qué mostrar. Esta puede ser la fuente de datos (Ej: Servidor, datos brutos en la aplicación)
  • Ver: cómo se muestra. Este puede ser el xml. Por lo tanto, actúa como un filtro de presentación. Se adjunta una vista 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 el modelo o la vista o el controlador que todavía no afectan a los otros

  • Digamos que cambiamos el color en la vista, el tamaño de la vista o la posición de la vista. Al hacerlo, no afectará el modelo o el controlador
  • Digamos que cambiamos el modelo (en lugar de los datos obtenidos del servidor para obtener datos de los activos), pero no afectará la vista y el 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 inocua sería agregar el observador de Java como las diapositivas describir y agrupar el onClick y otros tipos de acciones en funciones que todavía están en la actividad.

La forma de Android es que la actividad hace ambas cosas. Luchar contra eso realmente no hace que ampliar o hacer futuras codificaciones sea más fácil.

Estoy de acuerdo con la segunda publicación . Ya está implementado, pero no de la manera en que las personas están acostumbradas. Ya sea que esté o no en el mismo archivo o no, ya hay separación. No es necesario crear una separación adicional para que se ajuste a otros lenguajes y sistemas operativos.

Estando cansado del desastre de MVx en Android, recientemente hice 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 (actividad, fragmento y grupo de visualización). En el interior, 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 vincular a los oyentes en el mismo lugar.

Luego, una vez que se modifiquen sus datos, se invocará el 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 adentro para la compacidad del 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 y el controlador separados, se vería así:

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

Aquí, en cada botón, haga clic en el número que se boostá, luego se llamará a “render ()” y se actualizará el texto del botón.

La syntax se vuelve más agradable si usa Kotlin: http://zserge.com/blog/anvil-kotlin.html . Además, hay una syntax alternativa para Java sin lambdas.

La biblioteca en sí es muy liviana, no tiene dependencias, no usa reflections, etc.

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

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

Por favor, revisa estos enlaces:

Google agregó un ejemplo de MVP de la architecture de Android:

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

Debido a que a Google no le gusta imponer por la fuerza las restricciones de una implementación de MVC como iPhone, han dejado que el usuario decida utilizar la técnica de MVC, ya que en aplicaciones pequeñas o simples no necesitamos usar MVC, sino la aplicación se vuelve complicada y tendrá que modificar su código una vez que se complete el desarrollo, luego viene la 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 explicó el equipo de Xamarin (en el MVC de iOS “Sé que parece extraño, pero espera un segundo”):

  • El modelo (lógica de datos o 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 plotble. La vista es el diseño XML, y el controlador es la (actividad + su fragmento).

* Esta es solo mi opinión, no de ningún recurso o libro.

Cuando aplicamos MVC, MVVM o Presentation Model a una aplicación de 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 marco de terceros, generalmente tiene muchos códigos (como addXXListener (), findViewById (), etc.), que no agrega ningún valor comercial.

Además, debe ejecutar pruebas de la unidad de Android en lugar de las pruebas JUnit normales, que tardan años en ejecutarse y hacen que las pruebas unitarias sean poco prácticas. Por estos motivos, hace algunos años comenzamos un proyecto de código abierto, RoboBinding : un marco de modelo de presentación vinculante para la plataforma Android.

RoboBinding te ayuda a escribir código de UI que es más fácil de leer, probar y mantener. RoboBinding elimina la necesidad de un código innecesario como addXXListener y cambia la lógica de UI a Presentation Model, que es un POJO y se puede probar a través de las pruebas JUnit normales . RoboBinding viene con más de 300 pruebas JUnit para garantizar su calidad.

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

En MVC, la capa de Vista solo sabe cómo mostrar la interfaz de usuario (UI). Si se necesitan datos para esto, lo obtiene de la capa Modelo . Pero la Vista NO le pide directamente al modelo que busque los datos, lo hace a través del Controlador . Entonces, el Controlador llama al Modelo para proporcionar los datos requeridos para la Vista . 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:

enter image description here

Vale la pena señalar que la Vista puede conocer la disponibilidad de los datos en el Modelo ya sea a través del Controlador (también conocido como MVC Pasivo ) o mediante la observación de los datos en el Modelo mediante el registro de elementos observables, que es el MVC Activo .

En la parte de implementación, una de las primeras cosas que se le viene a la mente es que ¿qué componente de Android debería usarse para la Vista ? Activity o Fragment ?

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

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

La aplicación de muestra completa se puede encontrar en la twig ‘mvc’ de mi repository de GitHub aquí .

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

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

Modelo MVC

Model-View-Controller en Android En 2011, cuando Android comenzó a ser cada vez más popular, las preguntas sobre architecture aparecían de forma natural. Como MVC era uno de los patrones de IU más populares en ese momento, los desarrolladores también intentaron aplicarlo a Android.

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

Ver 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 los comentarios de los usuarios a través de la Vista, luego procesa los datos del usuario con la ayuda de Modelo y pasa los resultados a la Vista. Por lo general, actúa como el coordinador entre la Vista y el Modelo.

en otras palabras

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

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

Controladores: servicios. Estos son componentes de fondo que se comportan como daemons de UNIX y servicios de Windows. Se ejecutan de forma invisible y realizan un procesamiento desatendido continuo.