Arquitectura de la aplicación de Android – MVVM o MVC?

Tengo un proyecto android que estoy empezando a trabajar, y quiero que su estructura sea lo más robusta posible.

Vengo de un fondo de MVPV MVP y he estado leyendo un poco sobre la arquitectura de aplicaciones de Android, pero no pude encontrar una respuesta clara y clara sobre qué arquitectura debo usar.

¿Cómo implemento eficazmente el patrón de diseño de MVVM para mi aplicación de Android, que también facilitará la escritura de casos de prueba?
Qué debe hacerse en Activity / Fragment y ViewModel en MVVM
Xamarin Forms Navegación de página MasterDetail causando un accidente en android , Funciona en iOS y UWP
¿Cómo puedo utilizar sharedPreferences fuera de una actividad?
Android ViewModel no tiene constructor de argumento cero

Algunas personas sugirieron usar MVVM – http://vladnevzorov.com/2011/04/30/android-application-architecture-part-ii-architectural-styles-and-patterns/

Y otros sugirieron usar MVC, pero no especificaron exactamente cómo debería ser implementado.

Como he dicho que vengo de un fondo WPF-MVVM, y por lo tanto sé que depende en gran medida de enlaces que por lo que yo entiendo, no son compatibles por defecto en Android.

Parece que hay una solución de terceros – http://code.google.com/p/android-binding/ Pero no sé si me gustaría confiar en eso. ¿Qué pasa si su desarrollo se detendría y no será apoyado por futuras API y etc.

Básicamente lo que estoy buscando es un minucioso tutorial que me enseñará las mejores prácticas para la construcción de la estructura de la aplicación. Carpetas y estructura de clases y etc. Simplemente no pude encontrar ningún tutorial exhaustivo, y me esperaba que Google proporcionaría un tutorial para sus desarrolladores. Simplemente no creo que este tipo de documentación maneje el aspecto técnico lo suficientemente bueno – http://developer.android.com/guide/topics/fundamentals.html

Espero haber sido lo suficientemente claro y que no estoy pidiendo demasiado, sólo quiero estar seguro de la estructura de mi aplicación, antes de que mi código se convierta en un monstruo de espaguetis.

¡Gracias!

En primer lugar, Android no te obliga a utilizar cualquier arquitectura. No sólo eso, sino que también hace que sea algo difícil de tratar de seguir a cualquiera. Esto requiere que usted sea un desarrollador inteligente para evitar la creación de una base de código de espaguetis 🙂

Puede intentar adaptarse a cualquier patrón que conozca y que le guste. Me parece que el mejor enfoque de alguna manera entrar en sus tripas a medida que desarrollar más y más aplicaciones (lo siento por eso, pero como siempre, usted tendrá que cometer muchos errores hasta que empiece a hacerlo bien).

Acerca de los patrones que sabes, déjame hacer algo mal: Voy a mezclar tres patrones diferentes para que tengas la sensación de lo que hace lo que en Android. Creo que el Presentador / ModelView debe estar en algún lugar del Fragmento o Actividad. Los adaptadores a veces pueden hacer este trabajo ya que se encargan de las entradas en las listas. Probablemente las actividades deben funcionar como controladores también. Los modelos deben ser archivos java regulares, mientras que la vista debería estar en recursos de diseño y algunos componentes personalizados que podría tener que implementar.

Puedo darte algunos consejos. Esta es una respuesta wiki de la comunidad, así que espero que otras personas incluyan otras sugerencias.

Organización de archivos

Creo que hay principalmente dos posibilidades sensibles:

Organizar todo por tipo – crear una carpeta para todas las actividades, otra carpeta para todos los adaptadores, otra carpeta para todos los fragmentos, etc
Organizar todo por dominio (tal vez no la mejor palabra). Esto significaría que todo lo relacionado con "ViewPost" estaría dentro de la misma carpeta – la actividad, el fragmento, los adaptadores, etc. Todo lo relacionado con "ViewPost" estaría en otra carpeta. Lo mismo para "EditPost", etc Supongo que las actividades de mandato de las carpetas que crearía y luego habría algunos más genéricos para las clases base, por ejemplo.

Personalmente, sólo he estado involucrado en proyectos utilizando el primer enfoque, pero realmente me gustaría probar el más tarde, ya que creo que podría hacer las cosas más organizadas. No veo ninguna ventaja en tener una carpeta con 30 archivos no relacionados, pero eso es lo que obtengo con el primer enfoque.

Nombre

Al crear diseños y estilos, siempre nombre (o identificarlos) usando un prefijo para la actividad (/ fragmento) donde se utilizan.

Por lo tanto, todas las cadenas, estilos, ids utilizados en el contexto de "ViewPost" deben comenzar por ser "@ id / view_post_heading" (para una vista de texto por ejemplo), "@ style / view_post_heading_style", "@ string / view_post_greeting".

Esto optimizará el autocompletado, la organización, evitar la colisión del nombre, etc.

Clases base

Creo que querrás usar clases base para prácticamente todo lo que haces: Adaptadores, Actividades, Fragmentos, Servicios, etc. Estos pueden ser útiles al menos para fines de depuración para que sepas qué eventos están sucediendo en toda tu actividad.

General

Nunca utilizo clases anónimas – éstas son feas y desviarán tu atención cuando intentes leer el código
A veces prefiero usar clases internas (en comparación con crear una clase dedicada) – si una clase no va a ser utilizada en ningún otro lugar (y es pequeño) creo que esto es muy útil.
Piense en su sistema de registro desde el principio – puede utilizar el sistema de registro de Android, pero hacer un buen uso de ella!