Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Comparación de MVC de Java con patrón de diseño Android

Estoy haciendo una pequeña investigación sobre patrones de diseño en varias plataformas y tengo experiencia previa en la programación con Java.

Mientras leía estos mensajes: patrón MVC en Android y la arquitectura MVC en Android ,
Tenía una pregunta interesante en mente: ¿Por qué Java MVC swing no se puede comparar con el patrón de desarrollo de Android? O ¿Por qué no podemos decir que Android sigue MVC? (En el contexto de la "apariencia general").

En una respuesta, alguien aclaró MVC como:

  • Modelo: Qué hacer

  • Ver: Cómo procesar

  • Controlador: Eventos, entrada de usuario

DE ACUERDO. Bien, ahora lo que entiendo es:

Java Swing MVC:

  • En Java MVC, la clase de component es una clase abstracta para todos los atributos en el entorno visual. Hay una palabra clave distinta llamada controls se utiliza para algunos components como botones, listas, etc Por lo tanto, todos los controles y componentes son parte de Modelo en MVC.

  • Container hereda el component . Y hay varios LayoutManagers que definen los diseños y el lugar de los components en el container . También hay Listeners tienen que ser registrados con EventSources . Por lo tanto, todos ellos son la vista en MVC.

  • Clase que implementa Listener interface methods en los que ponemos nuestra lógica principal y hay algunas EventClasses para cada evento. Todos ellos forman parte de Controller en MVC.

Reuniendo todos estos ejemplos en una imagen; En MVC tenemos:

Swing mvc

Patrón de diseño de Android (visualización como MVC):

  • Creo que los widgets son iguales que los controls aquí. Además, hay algunos otros EventSources . Todos actúan como un modelo .

  • View paquete View tiene viewgroups (que también contienen varios tipos de layouts .) Y Listener interfaces . Todos ellos son parte de View en MVC.

  • Igual que MVC del oscilación, podemos decir Listener interface methods y las actividades de la Listener interface methods son la parte del regulador .

Poniendo todos juntos en una imagen; En Android tenemos:

Introduzca aquí la descripción de la imagen

Según la comparación anterior, considero las siguientes similitudes :

  • Container – igual que View

  • ViewGroup Layout managers : lo mismo que ViewGroup

  • Listeners – en general, tanto en la arquitectura

  • controls – en general igual que los widgets

  • Event delegation (registrando el listener apropiado con el origen del evento y luego implementando los métodos de Listener) – globalmente igual en ambas arquitectura

Entonces, ¿puede alguien explicar cuáles son las cosas que hace que el patrón de diseño de Android diferente de Java patrón MVC swing?
O Si usted cree que ambos son cosas diferentes (en el contexto de los patrones de diseño utilizados para el desarrollo), entonces explique por qué?

2 Solutions collect form web for “Comparación de MVC de Java con patrón de diseño Android”

Cada Swing JComponent tiene ComponentUI que es responsable de mostrar un componente. Mientras que JComponent tiene un método de pintura, sólo las clases derivadas por el usuario lo utilizan directamente – las implementaciones "estándar" muy a menudo sólo llaman al método paint de la interfaz de usuario adjunta. Esto permite conectar varias implementaciones de aspecto y sensación muy fácilmente – una apariencia diferente y solo proporciona diferentes ComponentUI. Muy claramente el componente es el "modelo" y la interfaz de usuario es la "vista". Y Android no hereda este desacoplamiento de manera muy obvia. Por ejemplo, su TextView parece sólo pintura dibujables cuando una JLabel similar tiene interfaz de usuario .

Sin embargo, este no es el único lugar donde se utiliza el enfoque MVC, y para algunos otros casos específicos Android y Swing MVC son muy similares. Por ejemplo, Android ListView tiene un modelo ( ListAdapter ) muy parecido a Swing JList tiene ListModel . En ambos casos, el modelo proporciona datos mientras que el propio componente ofrece posibilidades de visualización. La posible diferencia es que Swing tiene más componentes con tales datos desacoplados y presentación. JTable y JTree tienen modelos similares cuando Android no proporciona estos componentes fuera de la caja. No hay ningún árbol en absoluto, y TableLayout es un que se llama GridLayout en Swing, no es similar a JTable .

El enfoque general para invalidar y volver a pintar no es muy diferente y en ambos marcos sólo el hilo maestro dedicado puede tocar componentes. Además, los oyentes de eventos (probablemente otro grupo de "controladores") son muy similares en Java y Android, todas las diferencias entre ellos probablemente podrían ser llamadas "sutiles" solamente.

Los contenedores y las gestiones de diseño también son bastante similares entre Swing y Android, las principales diferencias son que Swing tiene implementaciones mucho más posibles de LayoutManager para elegir que Androids ViewGroup (clases como DatePicker , mientras que derivado de ViewGroup , no son administradores de diseño de propósito general) . Además, parte del diseño de Android está codificado en XML, mientras que Swing suele ser solo Java. Si los gestores de diseño también son una especie de "controladores" que responden a eventos como redimensionar o reorientar, esta parte se hace de manera muy similar. Sin embargo, no estoy seguro de si los gestores de diseño son realmente "controladores", ya que actualizar más la vista que el modelo.

En general, Swing parece más optimizado para la GUI grande y compleja que aparece en una pantalla grande cuando Android es más adecuado para pantallas pequeñas con sólo unos pocos componentes visibles, lo suficientemente grande como para ser operado con dedos sin lápiz óptico.

La característica clave de MVC es la separación de las preocupaciones entre los tres componentes:

  • El Modelo es responsable de mantener una representación interna de los datos.
  • La vista es responsable de mostrar esos datos al usuario y permitirles interactuar con él.
  • El Controlador es responsable de actualizar el Modelo en respuesta a las interacciones del usuario con la Vista y de asegurar que la Vista refleje el estado actual del Modelo.

Dependiendo de la estricta definición de MVC que esté aplicando, también podría especificar restricciones alrededor del desacoplamiento de los componentes; Por ejemplo, podría afirmar que el modelo no debe tener ningún conocimiento de la vista o el controlador. Sin embargo, en la mayoría de los casos probablemente se considerará suficiente para demostrar que los tres componentes se reflejan por separado en el software y se ajustan a las responsabilidades generales mencionadas anteriormente.

En términos de tus asignaciones de MVC a Swing y Android, creo que el principal problema con el que estás luchando es el de identificar el Modelo. El Modelo no tiene que ser un tipo distinto de componente en el marco de la interfaz de usuario, puede ser simplemente una clase simple o un conjunto de clases que encapsulan los datos en cuestión. Por lo tanto, donde tiene el modelo de mapeo de widgets y controles, yo diría que es incorrecto: el modelo es simplemente lo que los datos están siendo representados para el usuario. Por lo tanto, para Swing mapearía los componentes MVC de la siguiente manera:

  • Modelo: Cualquier clase de dominio que representa tus datos, por ejemplo com.example.Order .
  • Ver: Los controles, contenedores y gestores de diseño.
  • Controlador: las implementaciones de escuchas de eventos que manipulan el Modelo y actualizan la Vista.

Usted podría llegar a una aplicación MVC más estricta en Swing, pero lo anterior es probablemente una cartografía razonable.

El marco de la interfaz de usuario de Android es más restrictivo que el de Swing porque las aplicaciones en dispositivos móviles están más restringidas y Google prefiere que se comporten de una manera bastante consistente, de ahí la necesidad de clases como Activity para representar una cosa particular que el usuario necesita hacer y El acoplamiento relativamente apretado con una Activity y dado View / ViewGroup .

Aun así, podría asignar los componentes de Android de la siguiente manera:

  • Modelo: Cualquier clase de dominio que representa tus datos, por ejemplo com.example.Order .
  • Ver: Las Views y ViewGroups
  • Controlador: La Activity , suponiendo que el código de escucha de eventos para su View es parte de la Activity , que es a menudo el caso.

Ahora, también podría argumentar que lo anterior es en realidad más de un patrón Model-View-Presenter con la Activity jugando la parte del Presentador, pero dado que MVP puede ser pensado como una variedad más específica de MVC, que no Necesariamente invalidar el mapeo MVC.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.