#RxSwift_Sansan 今流行のRxをswiftで学ぶ! RxSwift勉強会 @ Sansanに行ってきたまとめ

rxswift_sansan

公開日: 

RxSwift勉強会 @ Sansanに参加してきたので、そのまとめ。

sponcer link

RxSwiftをプロダクトに導入してみた話

@kazu0620様

※遅刻してしまって発表をきけなかったので、資料を見たまとめを記載。

  • Rxを用いると、メンバ変数を所持したり、状態を保持などをせずに、計算方法などを定義できる
  • Rx自体は2009年から歴史があるので非常に枯れた技術である
  • RxSwift独自の拡張があるが、知見がないのでドキュメントやコメントをみて挙動を理解していったほうがはやい。

15minutes recipe of RxSwift

@gomi_ningen様

スライド

cf: テキストベース資料

  • 15分でRxSwiftを作る話

Observerパターンの復習

  • Aに変化が起きたらBに伝えたい
    • AはBの参照を保持してBに変更を伝える
    • しかし、異なるI/Fを持った通知先が増えると大変
  • pull型observerパターン
    • I/Fは単純だが、観測者がObservableに値を取りに行かなければならない
  • push型observerパターン
    • Observableが値ごとObserverに値を渡す

Observer, Observableの定義

  • push型observerパターンと同じ
  • 値の変化はnextで伝えて、エラーが発生したらErrorというEnumにいれると伝搬でき、状態遷移が終わったらCompleted
  • swiftはprotocolにgeneric parameterをもてない
    • swiftのクラス多重継承ができないので代わりにassosiated typeで対応している

BehaviorSubjectの実装

  • BehaviorSubjectはE型の値を状態として持つObservableなオブジェクトの一つ
  • 通知を解除できないとobserverパターンにならないので、return SubscribeDesposableすると解除できる
    • SubscriptionDisposableの実装は、発火するメソッドを実装すると成立する
  • unsafeAddressOf(AnyObject)
    • インスタンスにidを発行するが、その番地を取得できる

成果物の問題点

  • スレッドセーフではない→NSRecursiveLockを用いる
  • Error/Completedでイベントストリームが閉じない
  • SubscriptionDisposableがBehaviorSubjectに対してハードコードされている

まとめ

  • Observer, ObservableのI/Fはpush型Observerパターンから導ける
  • pushする値に意味付けをすることで機能性を向上させている
  • 購読解除の仕組みをDisposableに委譲している

Introduction to RxMarbleQuiz

@nakailand様

スライド

  • なぜRxSwiftを使う必要があるのか?
    • cross-platformでも似たような実装ができる
    • メンテが継続的
    • ドキュメントが豊富
  • RxMurbleについて語ります
  • Observableは流れる桃と思うといいらしい

オペレータの紹介

  • combineLatest
    • aとbがあって最新の値をとってくれるオペレーター
    • usernameとpasswordの入力ボックスがあって3文字以上入力されたらenterが押せるようにするなどといった時に使える
  • merge
    • 2つの処理を混ぜる
  • zip
    • 最新の2つがそろったら処理が終了するオペレーター
    • 2つのstreamの待ち合わせのイメージ
  • skip
    • 指定回数処理をスキップする

その他

Macアプリを作って覚えるRxSwift

@ymajio様

  • RxSwiftでツイッターのつぶやきを画面に流すMacアプリを作った話
  • rx_tapでもイベント処理はできるが、IBActionでいいときはIBActionのほうがよみやすいかも
  • 60秒ごとにannounceというstructを作り、TwitterのAPIで受信したコメントをmergeして画面に流す
  • メソッドを都度呼び出すとなるとメソッドを都度呼び出さないといけなくなるが、リアクティブだと、処理を合成して、一つのメソッドの呼び出しで終われる
  • Macアプリのソース
  • tweet表示は自分でviewを作って流している
  • レイヤード風アーキテクチャはmodelというのを使いたくないという思いから使った

RxSwiftのobserveOnとsubscribeOnを理解する

@ooba様

  • subscribeOnは人によって説明が違うので検証してみた
  • Observerとobservableの両方の当たらきをするオペレーター
  • オペレーターがやっていることは、下の処理からsubscribe()をしていき、上からobserveOn()していく
  • subscribeOnが効かないケース
    • NSURLSessionのrx_response
    • すでに実行スレッドが決まっているもの

Variableについて

@mo_to_44様

  • 勉強会してみたところ、RxSwiftをやる上では実践的なコードを書いて進めたほうがよさ気だった
  • variableの特徴
    • BehaviorSubjectをラップしたもの
    • valueに値を代入することでイベントが発火
    • 明示的にエラーや完了に出来ない
  • BehaviorSubjectはマーブルを見ると、直前の値を保持している事がわかる
  • Variableを使うとき
    • BehaviorSubectを使う場合
    • エラーが不要な場合

RxRests

@ishkawa様

  • Viewはデザインで変わりやすいが、ViewModelはviewでおこったことをmodelに伝えるだけなので壊れにくい
  • UITestをする上で、ViewModelならやりやすいかもしれない
  • ライヴコーディングでは、仮想時間が0のときにfalseが帰って来るかなど、実際にテストを記述していました

@mogmetの所感

RxSwiftを使えば様々な環境でも使えるし、かなり枯れた技術なので、とっつきにくい部分はあるかもしれませんが、一度勉強してみようかなと思いました。

ただ、実務で使うには学習コストが高いのでなかなか難しそうですね。

  • このエントリーをはてなブックマークに追加
  • Pocket
PAGE TOP ↑