web-dev-qa-db-ja.com

EventBusとコールバック、どちらをいつ使用するか？

バックグラウンドタスクを発生させるアクティビティがたくさんあります。バックグラウンドタスクがアクティビティでイベントを発生させることができるように、アクティビティはリスナーコールバックを実装したものとして自分自身を渡します。次に、アクティビティはUIに何かを表示して、バックグラウンドアクティビティが成功または失敗したことを示すことができます。

または、 EventBus を使用することもできます。ここで、アクティビティを取得して、リスナー/サブスクライバーとして登録します。バックグラウンドタスクでEventBusでイベントを発生させ、それをリッスンしているアクティビティで処理できます。

どちらが他方よりも優れている点は何ですか？いつ使用しますか？ （コードの清浄度？パフォーマンス？警告？）

フォローアップ-私はEventBusを使用することになりました。コードは間違いなく非常にクリーンであり、コールバックがどこにでもぶら下がっているわけではありません。 IDE（IntelliJ）はonEventメソッドが使用されていないと考えているので、アノテーションを作成しました

@Target({ElementType.METHOD})
public @interface EventBusHook {}

onEventメソッドの上に配置しました。次に、Alt +クリックして、IntelliJに未使用として扱わないように依頼しました。

@EventBusHook
public void onEvent(MyEventType myEventType){
androidcallbackevent-bus
23
Mendhak

EventBusを使用する利点：

  • あなたのコードははるかにきれいに見えます
  • コードはよりモジュール化され、コードのテストケースを簡単に作成できるようになります
  • オブジェクトをロックし、ガベージコレクターがオブジェクトをクリーンアップできないような不正なオブジェクト参照からのメモリリークを回避します
  • 一度に複数の受信機を持つことができ、それは放送のようです
  • 複数のインターフェイスを1つのEventBusに簡素化します
  • インターフェイスクラスでは、継承されるクラス内のすべてのメソッドをオーバーライドする必要があります。 EventBusを使用すると、本当に必要なイベントだけを聞くことができます

しかし、悪い部分は、IDEがオートコンプリートを支援できなかったため、関数宣言でもう少し頭痛がする可能性があることです。

私の提案は、カスタムリスナーを作成する必要がある場合は、EventBusを検討してください。すべてではないにしても、ほとんどの要件/ケースに適している可能性があります。

とにかく、結局のところそれはすべてあなたの選択です=）

25
nuuneoi

@nnuneoiの答えに同意しません。

イベントバスには、1つの利点があります。それは、互いの存在を「認識していない」コンポーネント間の通信を可能にすることです。

そして、いくつかの欠点があります。

  1. コンポーネントは、イベントバスと特定のイベントタイプの両方への依存によって疎結合になります
  2. 上記の＃1で説明した結合は強くありません
  3. 上記の＃1で説明した結合は明らかではありません
  4. イベントバスは、単純なコールバックよりもパフォーマンスのオーバーヘッドをもたらします
  5. イベントバスがサブスクライバーへの強い参照を保持している場合（たとえば GreenRobotのEventBus の場合のように）、未登録のサブスクライバーはメモリリークを引き起こします

これらすべての欠点を考えると、単純なコールバックをデフォルトの実装選択にする必要があります。

イベントバスは、直接結合が望ましくない場合、または実装が難しい場合にのみ使用してください。例えば：

  1. ServiceからActivityへのイベントの送信
  2. 独立したFragments間でイベントを交換する
  3. アプリケーション全体のイベント（ユーザーのログイン/ログアウトなど）

通信するコンポーネントがすでに互いの存在を「認識」している場合は、イベントバスを介して通信する必要はありません。

44
Vasiliy

イベントがセマンティックビューでグローバルに一意であるかどうかを確認する必要があります。加入者がイベントに興味があるかどうか。そうでなければ、彼は購読すべきではありません。

パブリッシャーとサブスクライバーの関係が本当にある場合は、イベントバスメカニズムが適切です。イベントは、受信者から完全に独立している必要があります。

したがって、何らかの理由でイベントを破棄するサブスクライバー（「登録されていてもイベントに責任を負わない」）は、Event-Busの使用が間違っていることを示す強力な指標です。次に、専用のリスナーの使用を検討する必要があります。

1
oopexpert

疎結合とよりクリーンなコードのために、 EventBus を使用します。また、GreenrobotなどのEventBusを使用すると、すべての定型文が自動的に実行され、アクティビティライフサイクルメソッド（onStartおよびonDestroy | onStop）からオブザーバーを登録および登録解除できるのは素晴らしいことです。コールバックを実装し、それらのコールバックのアクティビティライフサイクル管理を制御することは、不必要な頭痛の種であり、多くの不必要な定型文を伴います。

また、 明らかにすべてのガベージコレクターは弱い参照が素晴らしいと考えています -イベントバスはオブザーバーとコンポーネントにまさにそれを提供します。 オブザーバーパターン の基礎です。

0
samuel owino