Rxを使えば非同期か同期かを意識しなくてよくなるというのはどういうことか - アナログ金木犀
AndroidエンジニアがRxを使うモチベーションって非同期処理に対するソリューションとしてが多いと思うんだけど、Futuer使ったりするのと比べて、使う側がそもそも非同期か同期かを知る必要がない点が優れていると思います— 有象無象 (@kgmyshin) 2017年9月28日 この件、多少説明した方がいいのではと思ったので記事にしました。 一応Androidの話です。題材はなんでもよかったんですがリポジトリパターンを題材としてみました。 あらかじめ言っておくと、コードの細かいツッコミは置いておいてもらえると。伝えたいのは 非同期か同期かを意識しなくていいとはどういうことか です。 Rxのなかった世界のころ 非同期がゆえに... こういうリポジトリのinterfaceを実装したいと考えます。 interface CourseRepository { fun resolveById(id:
Unit Testing RxJava Observables
The first step to rx-ify our architecture was to change the methods in the data layer so that they returned Observables. The next question was: how do we unit test this? The ugly wayThe first thing that came to our minds was to simply subscribe in the same way we would from outside the tests and then save the result in a global variable that can later on be asserted. For example, imagine we have a
RxJava的なものを最小限に実装してコンポーネントの関係を理解する - Qiita
社内のRxJava勉強会用の資料です。 軽く、ほんの軽くRxJavaのサブセットを20行ほどで実装してみました。 https://github.com/gfx/RxInTheBox 概要 RxJavaはPromise的なもので、連続した「イベントの発生 / 値の生成」を扱えるようにしたもの Observableは「イベントが発生するかもしれない状態 / 値の生成中」という状態を表すオブジェクト OnSubscribeはObservableの中身で、「イベントの発生 / 値の生成」をObservableに通知するためのオブジェクト SubscriberはObservableから「発生したイベント / 生成された値」を受け取るコールバック RxJavaの捉え方 まずRxJavaですが、いくつかの捉え方があります。 リスト処理の抽象化・ストリーム化 Optional的な何か Promise的な何
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
