Arquitectura de aplicaciones de Android: ¿cuál es el modelo sugerido?

Question

De la misma forma que una aplicación web o de escritorio podría tener tres o n niveles: interfaz de usuario, empresa, datos, por ejemplo, ¿cuál es la estructura sugerida para una aplicación de Android? ¿Cómo se agrupan las clases, qué capas tienes, etc.?

Acabo de iniciar Android dev (una aplicación basada en Internet que debe responder a las notificaciones entrantes) y no tengo una idea real de la estructura a la que me refiero. Sugerencias apreciadas.

Answer 1

Las acciones, vistas y actividades en Android están preparadas para trabajar con la interfaz de usuario de Android y son una implementación de un modelo de vista de modelo-modelo, que es estructuralmente similar (en la misma familia) controlador de vista modelo .

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 tiene que volver a escribir su propia capa de interfaz de usuario para que funcione.

puede encontrar MVC en lo siguiente:

• definiría su user interface en varios archivos XML mediante la resolución/hardware etc.
• definiría su resources en varios archivos XML de acuerdo al lugar
etc.
• Almacenar datos en SQLite o sus datos personalizados en/assets/folder, leer más sobre resources and assets
• Extiende clases como ListActivity, TabActivity y hacer uso del archivo XML por inflaters
• Puede crear tantas clases como desee para su modelo, y tienen sus propios paquetes, que actuará como una estructura
• Una gran cantidad de Utils han sido ya escrito para ti DatabaseUtils, Html,

No hay un patrón MVC único al que pueda obedecer. MVC simplemente afirma más o menos que no debe mezclar datos y ver, de modo que, p. las vistas son responsables de mantener los 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 se ve obligado a seguir el patrón 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 de la carpeta res, y si evita más o menos mezclar estas cosas en su código, entonces de todos modos siga un patrón MVC.

Answer 2

En mi humilde opinión, Android "quiere" seguir un patrón de MVC, pero el controlador de vista & generalmente está realmente acoplado en actividades.

Hace la prueba unitaria más difícil y es difícil obedecer al Single Responsibility Principle.

Encontré a really nice Android architecture presented here, podría haber una idea. Todo está vagamente acoplado, es mucho más fácil de probar y editar.

Obviamente, estoy seguro de que hay muchas otras posibilidades (como el patrón MVP (Model View Presenter) - y here are answers talking about MVP in Android), pero aún debe echarle un vistazo.

Answer 3

Me doy cuenta de que esta pregunta es muy antigua, pero creo que puede ser útil para otros, como yo, que nos topamos con una búsqueda.

He estado trabajando en Android durante 9 meses desde un fondo del lado del servidor donde las pruebas unitarias completas y las arquitecturas en capas son comunes y funcionan bien.

A través de un montón de intentos de prueba y error, yo sugeriría encarecidamente utilizar el patrón Model View Presenter, no el controlador de vista de modelo.

Un gran problema que he encontrado es que Activities/Fragments tienen un ciclo de vida que está fuera de su control y puede ocasionar problemas inesperados.

Por ejemplo, nuestra aplicación principal de Android desea ser utilizada en modo apaisado en tabletas. Hacemos esto en OnCreateView() o OnCreate().

En un Nexus 7, la vista por defecto es vertical, entonces lo que sucede es que inicia la actividad en modo vertical, nuestro código dice ir a horizontal y finalmente android crea la clase activity 3 veces.

Hemos conectado solicitudes de red al onCreate y terminan ocurriendo 3 veces en este caso.

Claro, podemos agregar lógica para buscar llamadas duplicadas, pero, en mi opinión, sería mejor, arquitectónicamente, tratar de dividir la interfaz de usuario de la lógica comercial.

Mi recomendación sería utilizar el patrón de fábrica para crear presentadores de la actividad, pero asegúrese de que la fábrica solo devuelva la misma instancia. El presentador puede entonces contener lógica para hacer solicitudes de red, buscar duplicados y devolver resultados en caché y lógica comercial general.

Cuando los resultados de las llamadas de red volver, ya sea posterior a un bus, como Otto cual la actividad (registrarse para el evento en onResume() y dar de baja durante onPause()) ha registrado, o hacer que la interfaz de devolución de llamada implementado por la actividad ha sido actualizado a la última actividad en el presentador.

De esta manera, el código en el presenter hacia abajo se puede probar por unidad y no depende de la prueba de la capa UI escamosa.

Answer 4

MVP es la última architecute la mayoría de la gente está siguiendo Here is the small documentation Como arquitectura limpia de tío Bob dice: “La arquitectura es acerca de la intención, no marcos”

Watch this video Es simplemente mindblowing buena.

Answer 5

Aquí hay un proyecto dedicado para Android Architecture blueprints con códigos fuente bien documentados. Todos ellos se basan en el patrón de MVP con varios giros. También consulte el comparison de las diversas soluciones basadas en líneas de código, capacidad de prueba, costo de aprendizaje, su compatibilidad para aumentar la complejidad de los datos. Depende de la aplicación especialmente desarrollada y del contexto (tiempo de comercialización, desarrolladores, planes futuros, etc.) que mejor se adapte a los planos.