OttoからRxJavaへの移行ガイド - Qiita
Otto が突然メンテナンス終了したので言われたとおりRxJavaで置き換えてみた。お、いいね、でも移行するならEventBusでいいんじゃないかな、という話 経緯 ＿人人人人人人人人人＿ ＞ 突然のdeprecate ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y￣ https://github.com/square/otto/pull/181 RxJava流行っているしRxJavaで似たようなことできるからOttoのメンテナンスやめるね えー、EventBus とかOttoみたいなpub/subとRxは別物では… と思ったのだが、 gfxさんのつっこみとその後のやりとりを見て、言われたとおり参照されている記事を見てOttoを置き換えてみた Implementing an Event Bus With RxJava - RxBus 実装 OttoのかわりにRxBusというものをつくる。 RxBus
Android で EventBus を使うときのオレオレプラクティス - Qiita
"EventBus はどこでつかうべきか" の記事を参考に、 Android アプリ開発の際に EventBus を使っています。 EventBus は Acrivity や Fragment 、 Service 、 自分で定義したモデルのクラスなど、好きなところから自由にイベント通知を行える代物ですが、どこでも使える分、使いどころに困りました。自分なりの使い方をメモします。 Activity → モデル → 非同期処理 → モデル → Activity 自分が一番よく使うのはアクティビティからモデルオブジェクトに定義してあるロジックを呼び出して、モデルオブジェクト側では Web API と通信するなどの非同期処理を行い、その結果を Activity に通知するパターンです。 Web API との通信では Volley を使っていて、モデルオブジェクトのメソッドから通信を開始して、その結果
EventBus はどこでつかうべきか - Qiita
EventBus の使い方はこちらに任せるとして、この投稿では、EventBus の効果的な使い方について考察します。 どのレイヤの結合を分離するか 特に、View の仕組みがフレームワークとして作りこまれているものであれば、View のイベントはリスナーインタフェースを用いれば十分にイベントハンドリングが可能です。Android の場合、View のシステムは Activity のライフサイクルとよく連動して動作するため、ここに EventBus による中間層の挿入をする理由はあまりありません。 多くの場合、アプリ開発者が設計し実装する部分は Controller と Model の相互作用です。そして、Controller と Model の境界面で使われる設計パターンとして、コールバックインタフェースが用いられてきました。 コールバックインタフェースを用いることで、Model から
Android でイベントバスを使う - Qiita
Android では、非同期処理の返り値はコールバックインタフェースを介してやり取りされる。 これ以外にも、Observer パターンに基いて設計されているクラス（SharedPreferencesなど）や、Activity と Fragment とのやりとりなどでも、コールバックインタフェースを定義して、その実装とライフサイクル管理をする。 一方で、機能が増えるとその分コールバックインタフェースの定義も増え、Activity が幾つものインタフェースを実装することがある。コールバックインタフェースの定義が増えてくると、その分だけ依存関係が複雑になりやすくなったり、コールバックを受けて更に非同期処理を呼び出して…としていくと、どんどんネストが深くなったりしていく(コールバック地獄)。 そこで、コールバックメソッドを呼ぶタイミングでイベントを発火し、コールバックインタフェースの実装ではなく、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
