loadermanager loadercallbacks getloadermanager example android android-service android-testing android-cursor android-cursorloader

android - loadercallbacks - ¿Por qué no debo usar un bus de mensajes en lugar de un cargador y servicios?



getloadermanager deprecated (3)

cualquier razón fundamental para NO tomar este enfoque basado en mensajes con aplicaciones de Android

No hay, supongo. En mi práctica trabajé con cosas ''stock'' como Loaders y AsyncTasks (no pondría Servicios en esta fila, porque su responsabilidad es mucho más amplia). Entonces se implementó la cosa del bus, ¿y adivina qué? La vida se hizo más fácil y más predecible, el desacoplamiento aumentó. Una vez que me mudé totalmente a Rx, el trabajo se hizo no solo más fácil, sino también más divertido. Sin embargo, nada te salvará de lidiar con los ciclos de vida.

Todo esto es solo detalles de la implementación, es más importante mantener las cosas globales claras. Cuando se habla de Arquitectura limpia, lo importante es ocultar de la capa de la interfaz de usuario (Actividades, Fragmentos, Vistas ...) cómo y dónde vienen los objetos. Una vez que encapsula este trabajo determinado en casos de uso, no es una gran tarea qué herramienta utilizar: cargadores, buses o Rx: su capa de UI solo debe atenerse a la interfaz proporcionada por usecase: devoluciones de llamada, eventos u observables.

Me gustaría señalar dos cosas:

  1. Cuanto menos sepa cualquier capa sobre la implementación de casos de uso, mejor.
  2. Si ha elegido una herramienta particular para la implementación, úsela en todas partes. No mezcle varias herramientas para el mismo trabajo.

En un proyecto típico de Android en el que necesitamos extraer datos de algún lugar (REST, SQL, caché, etc.) en la interfaz de usuario de una manera limpia, usualmente usamos un cargador, servicio o (posiblemente, yuk) una AsyncTask, pero encuentro todos estos enfoques. insatisfactorio por varias razones:

  • Son feos, especialmente los cargadores que tienen una estructura de API atroz.
  • Es demasiado fácil envolverse en hilos y pisar el hilo de la interfaz de usuario
  • Nuestro código de capa de presentación está siendo contaminado con el código de Android y el texto. A menudo pasamos objetos de Android (p. Ej., Cursores) a la capa UI, lo que hace que una arquitectura limpia sea casi imposible de lograr. Esto nos obliga a mezclar código específico de dominio empresarial (idealmente objetos Java simples) con código de plataforma Android, lo que no es excelente para la legibilidad, el mantenimiento, las pruebas o la flexibilidad para el desarrollo futuro. En la práctica, a menudo tenemos clases de Actividad / Fragmentos enormes y desordenadas.

Me atraen ideas como las que se describen en estos artículos: http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ http://antonioleiva.com/mvp-android/ http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

Habiendo comenzado a usar MVP para dividir las Actividades / Fragmentos / Vistas en partes más pequeñas / más limpias, ahora estoy pensando que una solución a los problemas anteriores podría ser confiar en un bus de mensajes (Otto, EventBus, etc.) en lugar de servicios o Cargadores o lo que sea para interactuar con los datos del dominio.

Entonces, en la práctica, eso significaría que en lugar de usar (por ejemplo) un CursorLoader para cargar un Cursor desde la base de datos, en cambio, usaría el bus de mensajes para enviar un mensaje para solicitar datos, los datos se cargan en un hilo de fondo en respuesta a ese mensaje, y luego manejar los datos de respuesta cuando llega a través de un mensaje en el hilo de la interfaz de usuario. Para mí, lo más importante es que prefiero que la estructura de datos se elimine del dominio de negocios, no del dominio de Android, por lo que prefiero una variedad de objetos de negocios, a un cursor.

En este aspecto de la ingeniería, siempre hay ventajas y desventajas, y aunque esto parece proporcionar una separación de preocupaciones mucho más clara, hay menos inconvenientes para el cargador / servicio, ¿cuáles son las desventajas?

  • Puede ser más difícil (especialmente para los nuevos desarrolladores) entender el código
  • Será necesario asegurarse de que los mensajes se envíen y se reciban en los hilos correctos (parece que Otto puede tener limitaciones aquí)
  • Será necesario evitar la tentación de implementar todo como un mensaje, que en última instancia sería contraproducente.
  • Pasar colecciones de objetos de negocio puede ser menos eficiente que usar objetos como los cursores. Aunque en muchos escenarios es un problema en la práctica?
  • No sé si Otto / EventBus está diseñado solo para pasar mensajes muy pequeños, o si es apropiado pasar objetos más grandes (por ejemplo, una matriz de objetos comerciales).

Mi pregunta es: ¿existen razones fundamentales para NO adoptar este enfoque basado en mensajes con las aplicaciones de Android?

Hace unos años no existían dispositivos Android fuertes que tuvieran 3 gb de ram o más. Cuando recibe una llamada de red de su aplicación y su aplicación se interrumpe, como cuando recibe una llamada telefónica y envía su aplicación a un segundo plano (si no usa un servicio), su aplicación se cancela y desperdicia su llamada de red. Si tienes un servicio en ejecución vinculado a tu aplicación, tu aplicación tendrá una prioridad baja para que el sistema operativo Android te mate.

También con los servicios puede hacer que sus trabajos que no son de ui o procesos de larga duración se separen de ui-thread. Es un buen enfoque para la aplicación ui sin bloqueo. También puedes manejar los cambios de orientación.

Hoy en día, como usted dice, hay otras opciones (bibliotecas, patrones, etc.) en Android Dev. mundo como MVP, MVC, MVVM, Retrofit, OttoBus ...

Creo que no hay una forma correcta para desarrollar su aplicación Android, como "tiene que usar MVP, Retrofit, servicios, cargadores, MVVM, enlace de datos, etc."

Pero mientras desarrolla una aplicación de Android, puede considerar estos principios y puede elegir su patrón y su biblioteca de acuerdo con estos principios. (El orden de los principios se puede cambiar de acuerdo con su proyecto, tiempo, recursos, etc.)

1- Clean code 2- Seperate layers 3- Non Blocking Ui 4- Don''t waste user''s resources. (Avoid unneccassry network calls, memory allocation etc.) 5- Support orientation change. 6- Testing 7- Clean Ui Design (Material Design)

Este es un video antiguo, pero todos los desarrolladores de Android deben verlo: https://www.youtube.com/watch?v=xHXn3Kg2IQE