「ReactiveCocoa Tokyo #rac_tokyo」に参加してきました

@ninjinkunさんが発起人の一人で、Cocoa勉強会関西の特別編としてReactiveCocoaの勉強会を行ったところ、東京でもやろうということで開催されたとのことです。

はじめてのReactiveCocoa

ChatWorkの@tinpayさんによる発表。6月からReactiveCocoaで開発を行っているとのこと。

ReactiveCocoaって

• リアクティブプログラミングをサポートするライブラリ
• MVVMを実現するために利用する
• CocoaPodsでインストールできる

リアクティブプログラミング

• 命令型プログラミングは直ちに評価される処理を記述する
• 対して、リアクティブプログラミングは関係性は関係性を記述する

a = 1;
b = a + 2;
a = 3;
print(b);

• 命令型だと出力は3だが、リアクティブプログラミングだと5になる

MVVM

• Model: データ・ビジネスロジック
• View: 画面・UI
• ViewModel: Viewの値・動作を保持して、Modelとの情報伝達を行う
  • ModelとViewの間を取り持ち、バインディングを行う
• ReactiveCocoaを使ってバインディングすれば幸せ
  • ViewControllerのインスタンス生成時にViewとModelの関係性を書くだけで、値が変わったときにViewに反映させるための記述が必要がなくなる
• リアクティブプログラミングと命令型プログラミングを比較するためのサンプルソース

メリットとデメリット

メリット

• ViewControllerがスッキリした
  • 処理はViewModelに記述される
• テストが書きやすい
  • ビジネスロジックはModelに記述される
• 一時変数がなくなった
  • バグが減る

デメリット

• 難しい。。。。。。。
  • 1ヶ月くらいでは今までどおり書いたほうが何倍も早い
  • まずはViewModelへのデータバインディングのみ使うのがいいかも
• Signalを連鎖し過ぎると見にくい
  • 保守が大変な気がする
  • RACメソッドを上手く組み合わせる

まとめ

• 難しい
• 直感的に書けない
• もどかしい
• でもソースは綺麗になる
• 頑張りましょう＼(^o^)／

FrilでのReacitiveCocoa事例

株式会社Fablicの@ninjinkunさんによる発表。

• あなたが求めていたリアクティブプログラミング入門
  • リアクティブプログラミングは非同期データストリームを扱うプログラミングである

なぜ今ReactiveCocoaか

• アプリの複雑化
• Webサービス連携アプリの増加
• アプリが非常に多くの"状態"と"非同期処理"を持っている
  • 多数のAPIと非同期に通信し、状態を適切に更新し、ユーザに表示する
• Modelの更新、通知、Viewの更新
  • delegateメソッド or NSNotification

RPの特徴

• イベント駆動、拡張性、障害への耐性、応答性

RPの用途

• サーバーでもクライアントでも使える
  • Netflixではサーバとクライアントの中間レイヤーで使われている

ReactiveCocoaの段階的な採用

FrilのRAC利用ポリシー

• RACにロックインされるような実装は避ける
  • モジュール間のインターフェイスには使用しない

段階的な採用

• テキストのValidation
  • バリデーションしてボタンをenableにする
• delegateラッパー
  • delegateメソッドを使わずにその場でblockを渡せる
• KVOラッパー

MVVMへの緩やかな移行

なぜMVVMが必要か

• SNSアプリでは状態をViewController間で共有することが多い
• エントリの情報の追加、編集、削除
• ViewModelをbindすればViewは自動更新にしたい

ReactiveCocoa本のMVVM

• Functional Reactive Programming on iOS
• HTTPリクエストの開始までVMが持つ
• RACSignal依存の設計になるので今のところ不採用

僕の考えるゆるいMVVM

• とにかくMutableなものはVMに集める
• VMに対するユニットテストを書く
• RACはbindのみに使う

Frilの商品VM

• 複数のJSON由来NSObjectを持っている
• VMを中間レイヤーとして使う
• 商品ViewModelとAPIの構造は異なる

まとめ

• ReactiveCocoaの段階的な採用
  • Validationでの仕様、delegateラッパー
• MVVMへの緩やかな移行

freee社でのReactiveCocoa活用例

freeeの@yo_wakaさんによる発表

freee社でのReactiveCocoa活用例 from yo_waka

freeeのiOSアプリ

• 確定申告や小規模法人決算をカンタンに
• 既にWeb版がある
• エンジニア2人で1ヶ月で開発
• ReactiveCocoaを採用

ReactiveCocoa採用の背景

• アプリを出して終了ではない
• 会計サービスはUIが複雑
• スタートアップで後から設計変更してる余裕ない
• 変更に強い設計が必要
• Viewの状態管理が複雑
• 複数のモデルを管理しないといけない

MVCの問題点

• ViewとModelが1対1とは限らないのでビジネスロジックが散らばる
• APIどこのレイヤが叩くねん問題
• Web版が抱える問題を解決したかった

ReactiveCocoa

• VCの状態管理
• APIリクエストの発行
• Modelの操作
• ビジネスロジックがVMに集約
• モデルにメソッドがはえることがない

勉強し始めの頃

• GitHubのoctokit.objecがソースめっちゃ綺麗
• @ikehyoさんのQiita資料がまとまっている

Pros/Cons

• Pros
  • 1つsignal設計すると使い回しがしやすい
  • カテゴリ拡張がとにかく便利
  • RACObserverサイコー
• Cons
  • SubscriberやRACSignalのコードを理解するのが難しい
  • RACが死ぬと我々も死ぬ

var RAC3 = ReactiveCocoa + Swift

ReactiveCocoaのコミッターである@ikesyoさんの発表。

var RAC3 = ReactiveCocoa + Swift @ ReactiveCocoa Tokyo #rac_tokyo 10/18 from Syo Ikeda

• APIやクラス名など今後変更される可能性は大いにあります
• RAC3作ってたけどSwiftが出たため、RxSwiftが合流するかたちで開発を進めている

New Concepts

• Generics Support
• ColdSignal
• Subscriber
• HotSignal
• ObservableProperty
• Action

Swift版のReactiveCocoaを組み込む方法

• https://github.com/ikesyo/rac_tokyo_rac3_installation_sample

LT

CDEvents+ReactiveCocoa でファイル監視

@uasiさんによる発表。

ReactiveCocoa Pitfalls at freee

@yonekawaさんによる発表。

distinctUntilChangedの使いどころ

@at_akaさんによる発表。

distinctUntilChanged の使いどころ from 正之 安宅

Bolts-iOSを"ちょっと"駆使した非同期処理の例

@huinさんによる発表。

ReactiveCocoa Tokyo LT from Koichi Sakata