LiveData与Handler和LocalBroadcast

Question

我有旧的Android/Java代码,它包含两个派生自IntentService,而这些服务不在单独的进程中运行.

问题是关于从这些结果返回结果的方法IntentService.

一个服务返回结果使用Handler+ Runnable,在主循环中运行代码:

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

另一个LocalBroadcastManager.getInstance(this).sendBroadcast(in);用于发送消息Activity,并Activity通过BroadcastReceiver消息onResume订阅,并取消订阅onPause.

我是对的,在这两种情况下都可以LiveData用来简化事情吗？

IntentService应该创建LiveData和谁想要结果observe,当新数据到达IntentService应该打电话postValue,或者可能有一些珊瑚礁,以防止在LiveData这里使用？

Answer 1

我认为这LiveData不会帮助您从Service其他组件发送任何数据。

从任何Service组件到其他组件的通信问题在于您通常不会获得对 的直接引用Service，因此您无法直接“订阅”通知。

理论上，如果Service运行在同一个进程中，可以绑定它，获取Service对象的引用，然后直接进行订阅。然而，这通常是一种矫枉过正，我认为这种模式并没有被广泛使用。

在您的示例中，有两种通信机制：

1. 服务静态地到达应用程序对象并设置一些数据。这是一种通过全局状态的通信，通常被认为是一种反模式。
2. 通过 LocalBroadcastManager 进行通信

根据上述两种机制，我将只使用 #2 并不惜一切代价避免 #1。

回到LiveData.

为了能够从 中获取LiveData对象，Service您需要有一个对该对象的引用Service。这通常是不可能的，除非你Service在同一个进程中绑定，或者使用一些涉及全局状态的丑陋的 hack。

因此，LiveData在这种情况下的用处非常有限。

顺便说一下，虽然 LocalBroadcastManager 没问题，但我觉得这个机制太复杂和限制了。因此，如果Service在同一进程中运行，我更喜欢使用EventBus以便Service与其他组件进行通信（反之亦然）。

您可以在我几天前编写的SQLite 基准测试应用程序中看到此类通信的示例。在此应用程序中，将TestService状态更改和测试结果EventBus作为粘性事件发布，并TestActivity订阅这些事件。