Android Patrones arquitectónicos

Acabo de empezar con el desarrollo de Android y estoy tratando de desarrollar mi primera aplicación, que voy a publicar. Tengo un fondo de programación en Java y el conocimiento de algunos patrones sin embargo no tengo idea de qué patrones debo pegarse con el desarrollo de aplicaciones para Android. También dónde poner hilos. Estoy desarrollando una aplicación, que constantemente carga datos de una base de datos remota a través de scripts PHP y los muestra en la interfaz de usuario. He dividido una aplicación a varias capas: capa de presentación, capa de dominio / capa de servicio y capa de origen de datos. Entre ellos creo fachadas para acceder a los servicios de la capa abajo. Realmente no sé si debo seguir con esta estructura o reconstruir completamente esta aplicación de acuerdo con algunos otros patrones. Es mejor encontrarlo al principio del desarrollo que obligarse a reconstruir toda la aplicación más adelante. Así que si alguien me podría proporcionar algunos enlaces sobre los patrones arquitectónicos que puedo utilizar o escribir algo corto aquí, me gustaría realmente!

Es posible que desee poner la comunicación de red en un Servicio en lugar de AsyncTask o Thread. Su arquitectura suena como una forma de MVC que es bueno en mi opinión.

Creo que la actividad es un buen punto de partida para usted. Aprenda su ciclo de vida y cómo presentar sus datos al usuario. También puede leer más acerca de los subprocesos y la conectividad para ver por sí mismo cómo se hace en android.

En mi opinión, el principio de responsabilidad única y la separación de toda la aplicación en diferentes capas (como el patrón MVC, pero Android no es totalmente compatible con MVC formal) es una buena práctica en Android development.Now voy a hablar de las capas principales en lo siguiente:

Capa de representación:

Por ejemplo, el marco de Android ofrece una representación XML muy simple para la capa de presentación , en lo que respecta a esta representación XML, no debe crear las cosas de la interfaz de usuario en el código. En su lugar, debe hacerlo en XML.

Lógica de la aplicación capa:

Por ejemplo, hay un atributo android:onclick="function_name" en Android XML (para asignar un onClickListener a una vista) Pero como patrón MVC la vista / representación La capa DEBE estar completamente separada de la capa Controlador / lógica.

Capa de la fuente de datos:

Finalmente, puede tener una capa de origen de datos cuya responsabilidad es proporcionar datos, datos persistentes y todo lo relacionado con los datos. En Android usted pondría algunas cosas en esta capa como tratar con SQLite, ContentProviders, SharedPreferences etc

Resultado:

Creo que es mejor elegir un patrón de arquitectura principal y diseñar su aplicación en alto nivel de abstracción de acuerdo a su patrón elegido y, a continuación, implementa sus sub-capas. Mi enfoque favorito para el diseño arquitectónico y la implementación es algo que suena como el enfoque de arriba hacia abajo, en esta estrategia se diseñaría su aplicación de arriba a abajo de manera / más abstracto a menos abstracto / menos detalle a más detalle

He dividido una aplicación a varias capas: capa de presentación, capa de dominio / capa de servicio y capa de origen de datos.

Alternativamente, podría dividir la aplicación verticalmente por sus características. Así que obtienes un paquete para cada función o actividad, tal vez con subpaquetes. Una buena regla es: un paquete no debe contener más lógica, que usted (o alguien más) puede entender fácilmente. Esta técnica tiene algunas ventajas. En primer lugar, sus paquetes no se hacen más grandes y más grandes cuando se agrega más funciones a su aplicación. En segundo lugar, se hace más fácil mantener dependencias entre diferentes características. Tal vez su IDE puede generar una matriz de dependencia de sus paquetes.

También dónde poner hilos. Estoy desarrollando una aplicación, que constantemente carga datos de una base de datos remota a través de scripts PHP y los muestra en la interfaz de usuario.

Android tiene el concepto de cargadores y AsyncTasks . Ellos le ayudan a separar las tareas de largo funcionamiento de la interfaz de usuario. Hay un ejemplo utilizando el Loader-API en el sitio web de desarrolladores de Android.

  • ViewPager y fragmentos - ¿cuál es la forma correcta de almacenar el estado del fragmento?
  • ¿He usado Singleton con Realm Database correcto?
  • ¿Debería el renderingThread de un SurfaceView tener el mismo ciclo de vida que la vista o la actividad?
  • Patrones de diseño para Android
  • Menú del mapa de externalización
  • AsyncTask Android - Patrones de diseño y valores de retorno
  • Editar entrada de texto con patrón android
  • Comparación de MVC de Java con patrón de diseño Android
  • ¿Hay algún patrón en el método Random ()?
  • La mejor manera de administrar el ProgressDialog de AsyncTask
  • Android.util.Log al publicar - ¿qué puedo hacer / no hacer
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.