LiveDataとHandlerとLocalBroadcast

Question

私は、IntentService、 とこれらのサービスではなくから別々のプロセスで実行される2つの派生を含む古いAndroid/javaコードを持っています。

質問は、これらの結果を返す方法についてです。IntentServiceメインループ内のコードを実行するために、Handler + Runnableを用いて

つのサービスリターン結果：、

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

他方であるがActivityにメッセージを送信するLocalBroadcastManager.getInstance(this).sendBroadcast(in);を使用し、ActivityはonResumeにメッセージにBroadcastReceiver介して購読しますに退会してください。

私は正しいでしょうか、どちらの場合でも簡略化するためにLiveDataを使用することは可能ですか？

IntentServiceはLiveData、誰結果は新しいデータが到着したときobserveそれ、 とIntentServiceはpostValue、 を呼び出す必要があります必要がありますかここLiveDataの使用を防ぐために、いくつかのサンゴ礁があるかもしれ？したいを作成する必要がありますか

Answer 1

私はLiveDataがServiceから他のコンポーネントにデータを送信するのを手伝ってくれないと思います。

Serviceから他のコンポーネントへの通信での問題は、通常Serviceへの直接参照を取得しないため、通知に直接「購読する」ことはできません。

理論的には、Serviceが同じプロセスで実行されている場合は、バインドしてServiceオブジェクトへの参照を取得し、サブスクリプションを直接実行します。しかし、これはしばしば過度のものであり、このパターンが広く使われているとは思われません。あなたの例では

、二つの通信メカニズムがあります

1. サービスは、Applicationオブジェクトに静的に達し、いくつかのデータを設定します。これはグローバルな状態を通したコミュニケーションであり、一般に反パターンと見なされます。上記の二つのメカニズムから

LocalBroadcastManagerて

コミュニケーションは、私は＃2を使用し、すべてのコストで1位を避けるだろう。

LiveDataに戻る。

からLiveDataオブジェクトを取得できるようにするには、Serviceへの参照が必要です。 Serviceを同じプロセスでバインドしないか、グローバルな状態を含む醜いハックを使用しない限り、これは通常不可能です。

したがって、この文脈におけるLiveDataの有用性は非常に限られています。ところで

、LocalBroadcastManagerは大丈夫ですが、私はこの機構が複雑すぎると、規制を見つけます。したがって、同じプロセスでService実行される場合、私は、他の成分（又はその逆）へServiceから通信するためにEventBusを使用することを好みます。

あなたは、私は数日前に書いSQLite benchmarking applicationで見ることができるような通信の例。このアプリでは、TestServiceはスティッキーイベントとしてEventBusにステータス変更とテスト結果を投稿し、TestActivityはそれらのイベントをサブスクライブします。

Answer 2

両方のメソッドは、LiveDataを使用して動作します。これは、LiveDataの目的は、別のスレッドでそのメソッドを使用し、何かが変更されたときにユーザーに通知することだからです。 LocalBroadcastManager.getInstance(this).sendBroadcast(in);が確実に置き換えられ、IntentServiceがpostValueに置き換わるようです。あなたの活動や、変化を知る必要のあるものをオブザーバーにするだけです。