vista tutorial mvc modelo español ejemplo diagrama controlador java android design-patterns model-view-controller

java - tutorial - mvc android ejemplo



Patrón MVC en Android (21)

¿Es posible implementar el patrón modelo-vista-controlador 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?

Controlador de vista de modelo (MVC)

Descripción:

  • Cuando tenemos que dirigir grandes proyectos en el desarrollo de software, MVC generalmente se usa 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 este:

  • Modelo: Qué mostrar. Esta puede ser la fuente de datos (Ej: Servidor, Datos sin procesar en la aplicación)
  • Ver: 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 entrada de usuario. Esta sea la actividad

Característica importante de MVC: podemos modificar el Modelo o la Vista o el Controlador sin afectar 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á al modelo ni al controlador.
  • Digamos que cambiamos el modelo (en lugar de los datos extraídos del servidor para obtener los datos de los activos) todavía no afectará la vista y el controlador
  • Digamos que cambiamos el controlador (lógica en la actividad) no afectará el modelo y la vista

Al estar cansado del desastre de MVx en Android, recientemente he creado una pequeña biblioteca que proporciona 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 vista). En el interior se define la estructura y el estilo de la capa de vista. También se define cómo se deben vincular los datos a las vistas. Finalmente, puedes unir a los oyentes en el mismo lugar.

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

Este es un ejemplo del componente que tiene todo dentro 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 como:

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

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

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

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

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

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 vincular los widgets de vista de Android al 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 de sistema o cualquier otro objeto, y deje que RoboGuice se encargue de los detalles.

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

Por todo lo demás que he visto y leído aquí, implementar todas estas cosas hace que sea más difícil y que no se ajuste bien con otras partes de Android.

Tener una actividad para implementar otros oyentes ya es la forma estándar de Android. La forma más inofensiva sería agregar el Java Observer como las diapositivas describen y agrupan 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 eso realmente no hace que extender o hacer la codificación futura sea más fácil.

Estoy de acuerdo con la 2ª publicación . Ya está implementado, pero no de la forma 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 idiomas y sistemas operativos.

Cuando aplicamos MVC, MVVM o modelo de presentación 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 sencillo para las pruebas unitarias.

En este momento, sin un marco de terceros, por lo general tiene mucho código (como addXXListener (), findViewById (), etc.), que no agrega ningún valor comercial.

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

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

De acuerdo con la explicación que explicó el equipo de Xamarin (en el MVC de iOS "Sé que parece extraño, pero espere 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 la (actividad + su fragmento).

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

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 incorporadas 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, no implica ninguna lógica de dominio de aplicación en la actividad).

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

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

EDITAR

Podemos estar hablando de MVC , pero por así decirlo, FMVC , Framework - Model - View - Controller . El Marco (el sistema operativo Android) impone su idea del ciclo de vida de los componentes y los eventos relacionados, y en la práctica, el Controlador ( Activity / Service / BroadcastReceiver ) es el primero responsable de afrontar estos eventos previstos en el Marco (como onCreate () ) . ¿Se debe procesar la entrada del usuario por separado? Incluso si fuera necesario, no puede separarlo, los eventos de entrada del usuario también vienen de Android.

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

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 sea la mejor solución.

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

El patrón MVC de Android se implementa (tipo de) con sus clases de Adapter . Reemplazan un controlador con un "adaptador". La descripción de los estados del adaptador:

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

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

En Android no tienes MVC, pero tienes lo siguiente:

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

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

Sin embargo, si considera la Actividad como parte de la vista, la implementación de MVC es bastante sencilla. Puede anular la Application (según lo devuelto por getApplication () en la actividad) y es aquí donde puede crear un controlador que sobrevive durante toda la vida de su aplicación.

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

Fue sorprendente ver que ninguno de los mensajes aquí respondieron 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 (IU). Si se necesita algún dato para esto, lo obtiene de la capa Modelo . Pero la Vista NO le pide directamente al modelo que encuentre 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 a continuación:

Vale la pena señalar que la Vista puede conocer la disponibilidad de los datos en el Modelo 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 observables en él, que es el MVC activo .

En la parte de la implementación, una de las primeras cosas que me 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 pueden ser utilizados. La vista debe poder presentar la interfaz de usuario (IU) en el dispositivo y responder a la interacción del usuario con la IU. Tanto la Activity como el Fragment proporcionan los métodos requeridos para esto.

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

La aplicación de muestra completa se puede encontrar en la rama ''mvc'' de mi repositorio de GitHub here .

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

Para aquellos interesados, comencé una serie de artículos sobre arquitectura de aplicaciones de Android en los que comparo las diferentes arquitecturas, es decir, MVC, MVP, MVVM, para el desarrollo de aplicaciones de Android a través de una aplicación que funciona completamente.

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

Debido a que 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 de usar la técnica de 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 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 simples patrones de diseño de Android. 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/

Las acciones, las vistas y las actividades en Android son la forma horneada de trabajar con la interfaz de usuario de Android y son una implementación del patrón modelo-vista-modelo de vista (MVVM) , que es estructuralmente similar (en la misma familia que el modelo-vista) -controlador.

Que yo sepa, 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 que tenga que volver a escribir su propia capa de UI para que funcione.

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

Pero, sin embargo, como Android trata con las clases y los recursos, a veces incluso se ve obligado a seguir el patrón MVC. En mi opinión, más complicadas 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 de 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.

No hay un patrón MVC universalmente único. MVC es un concepto más que un marco de programación sólido. Puedes implementar tu propio MVC en cualquier plataforma. Mientras se apegue a la siguiente idea básica, está implementando MVC:

  • Modelo: Qué renderizar
  • Ver: Cómo renderizar
  • Controlador: Eventos, entrada de usuario

También piénselo de esta manera: cuando programa su modelo, el modelo no debería tener que preocuparse por el renderizado (o el código específico de la plataforma). El modelo le 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 renderice. 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 para desarrollar aplicaciones multiplataforma.

Puede implementar MVC en Android, pero no está "soportado 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:

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

Después de jugar con los diversos enfoques para 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 .

Model-View-Controller en Android Alrededor de 2011, cuando Android comenzó a ser cada vez más popular, las preguntas de arquitectura aparecieron naturalmente. Dado que MVC era uno de los patrones de UI 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 de negocios, es decir, el modelo de negocios, así como las operaciones de acceso a datos, es decir, el modelo de datos. También define las reglas de negocios para los datos significa cómo se pueden cambiar y manipular los datos.

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 IU.

Controlador El controlador es responsable de procesar las solicitudes entrantes. Recibe información de los usuarios a través de la Vista y 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 Vista y el Modelo.

en otras palabras

Modelos: Proveedores de contenido. Los 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 de Android se deriva de la clase Activity Java (android.app.Activity). Son contenedores para vistas (android.view.View).

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

MVC: la arquitectura en Android es mejor seguir a cualquier MVP que MVC en Android. Pero aún 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:

Ahora aquí está la pieza de magia que puedes hacer. Una vez que haya clasificado el fragmento de código, escriba una clase de interfaz base como, IEntity e IService. Declarar métodos comunes. Ahora cree la clase abstracta BaseService y declare su propio conjunto de métodos y tenga separación de 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 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. Todos los componentes de la arquitectura deben ser independientes sin tener lógica dependiente. Si es por casualidad si tiene algo de lógica dependiente, escriba una clase de lógica de mapeo en medio. Esto te ayudará en el futuro.