Android Architecture Design - ¿Cómo hacerlo bien?

Question

¿cómo se ve una buena arquitectura para una aplicación de Android? ¿Debería haberse hecho toda la "lógica de trabajo/negocio" en un servicio en segundo plano y la Actividad se comunica solo con el servicio para consultar/recuperar datos de algún lugar (local/distante)?

¿Implementarías el "servicio" que la actividad llama como un servicio real de Android? O un POJO-Singleton que hace el trabajo (tal vez usando hilos de fondo). O crea instancias de hilos de fondo en tu actividad para acciones que requieren mucho tiempo (consulta un servicio web).

¿Cómo abstractas el acceso a tus datos de la manera correcta? ¿Usarías un ContentProvider para acceder/abstraer tus datos? ¿Cómo/de dónde debería ser consultado? ¿Actividad? ¿Servicio? ..?

He intentado buscar un buen diseño de arquitectura de aplicaciones, pero solo encontré la apariencia de la arquitectura de Android, no cómo debería ser una aplicación de Android.

¿Cuál es su opinión al respecto? ¿Qué componentes de una aplicación de Android deberían comunicarse entre sí para garantizar la mejor extensibilidad/encapsulación, ...?

Answer 1

No hay una respuesta a esta pregunta. El buen diseño de OO no es específico de Android. Yo diría que la regla es: si el marco te da un objeto de alto nivel (como el Servicio en el caso de Android) que se ajuste a tu caso de uso, úsalo. Si te encuentras haciendo implementaciones POJO de las mismas cosas que obtienes de forma gratuita con el marco, ve con el marco.

En cuanto a la separación de preocupaciones, esto es algo estándar de OO. No coloque nada en sus clases de Actividad que no sea el trabajo de la Actividad. El sobrealimentar la Actividad con métodos y propiedades que la Actividad necesita pero que realmente no es el trabajo de la Actividad es malo, hace que la intención de su Actividad sea difícil de entender.

Normalmente separe cosas en subpaquetes en mis aplicaciones.

• com.myname.myproject.app - clases base, funcionalidad aplicación global
• com.myname.myproject.net - cosas de la red, utilidades relacionadas con la red
• com.myname.myproject.data - ayudantes db , proveedores, etc
• com.myname.myproject.model - modelo de objetos

etc.

En lo que a la comunicación w dentro de su aplicación ...

Siempre tengo una clase de aplicación personalizada que registro en el manifiesto. De esta manera, cuando tengo controladores y ayudantes que necesitan ser una "única instancia", no tengo que hacer todo ese hilo loco de cosas seguras de singleton ... Solo conservo una copia global de.

RoboGuice es un marco de inyección de dependencia que hace esto aún más fácil de lograr ... definitivamente vale la pena investigar. Si esto te interesa, el Grupo de Google para RoboGuice es excelente y está constantemente lleno de creadores del marco que básicamente pueden responder cualquier cosa que necesites.

Por lo que dentro de la aplicación de comunicación, uso mis clases Controlador instancia y estatales individuales para mantener el estado y realizar tareas comunes, y por lo general utilizo BroadcastIntents para comunicarse de nuevo a Actividades de Servicios