programar - para que sirve java en android

LiveData vs Handler y LocalBroadcast

Question

Tengo el código antiguo de Android / java, que contiene dos derivadas de IntentService , y estos servicios no se ejecutan en procesos separados.

La pregunta es sobre la forma de devolver el resultado de estos IntentService .

Un servicio devuelve el resultado utilizando Handler + Runnable , para ejecutar el código en el bucle principal:

new Handler(Looper.getMainLooper()).post(new Runnable() {
    @Override
    public void run() {
        MyApplication.get().setFoo(someThing);
    }
});

el otro es usa LocalBroadcastManager.getInstance(this).sendBroadcast(in); para enviar un mensaje a Activity , y Activity suscríbase a través de BroadcastReceiver en el mensaje en onResume , y cancele la suscripción en onPause .

¿Tengo razón, y en ambos casos es posible usar LiveData para simplificar las cosas?

IntentService debería crear LiveData y quien quiera ver el resultado debería observe , y cuando lleguen nuevos datos, ¿ IntentService debería llamar postValue o puede haber algunos arrecifes para evitar el uso de LiveData aquí?

Answer 1

Ambos métodos funcionan con el uso de LiveData, ya que el propósito de LiveData es tenerlo en otro hilo y aún notificar a los usuarios cuando algo ha cambiado. Parece que definitivamente reemplazaría a LocalBroadcastManager.getInstance(this).sendBroadcast(in); y tu IntentService postvalue. Solo haga que su actividad o cualquier cosa que necesite estar al tanto de los cambios se convierta en un observador.

Answer 2

Creo que LiveData no le ayudará a enviar datos desde el Service a otros componentes.

El problema con la comunicación de cualquier Service a otros componentes es que normalmente no obtiene una referencia directa al Service , por lo tanto, no puede "suscribirse" directamente a las notificaciones.

En teoría, si el Service ejecuta en el mismo proceso, puede vincularlo, obtener una referencia al objeto Service y luego realizar la suscripción directamente. Sin embargo, esto suele ser una exageración y no veo que este patrón se use ampliamente.

En sus ejemplos, hay dos mecanismos de comunicación:

1. El servicio llega estáticamente al objeto Aplicación y establece algunos datos. Esta es una comunicación a través del estado global, y generalmente se considera un anti-patrón.
2. Comunicación a través de LocalBroadcastManager

De los dos mecanismos anteriores, usaría solo el # 2 y evitaría el # 1 a toda costa.

Volver a LiveData .

Para poder obtener el objeto LiveData del Service , deberá tener una referencia a ese Service . Por lo general, esto es imposible a menos que vincules al Service en el mismo proceso, o uses algún truco feo que involucre un estado global.

Por lo tanto, la utilidad de LiveData en este contexto es muy limitada.

Por cierto, aunque LocalBroadcastManager está bien, encuentro este mecanismo demasiado complicado y restrictivo. Por lo tanto, si el Service ejecuta en el mismo proceso, prefiero usar EventBus para comunicarme desde el Service a otros componentes (o viceversa).

Un ejemplo de una comunicación de este tipo puede verse en la aplicación de evaluación comparativa SQLite que escribí hace varios días. En esta aplicación, TestService publica cambios de estado y resultados de pruebas a EventBus como eventos TestActivity , y TestActivity suscribe a esos eventos.