読者です 読者をやめる 読者になる 読者になる

毎日リアクティブ | try! Swift Tokyo 2017 #tryswiftconf Day1-6 聞き起こし

try! Swift Tokyo 2017

twitter.com

In this talk, we’ll walk through some practical uses of reactive programming in app development, using examples from my daily experiences. We’ll explore tips and tricks for determining when reactive programming can be a potent tool, as well as scenarios to avoid that might threaten code quality and performance. The talk will focus on concepts in reactive programming, the code will show off different Swift reactive implementations.

この講演では、私の日々の経験からの例を使って、アプリ開発におけるリアクションプログラミングの実践的な使い方を紹介します。リアクティブプログラミングがどんなときに強力なツールになりえるのかを判断するヒントとともにコードの品質とパフォーマンスを脅かす可能性があるために避けるべきシナリオも紹介します。 このトークでは、様々なSwiftのリアクティブな実装を例示しながらリアクティブプログラミングの概念に焦点を当てていきます。

speakerdeck.com

毎日リアクティブ

f:id:niwatako:20170302143059j:plain

UstreamiOSデベロッパーをしています

f:id:niwatako:20170302143133j:plain

安定した可読なコードを心がけリアクティブにしています、それ以外にも楽しいから。

しかし崇め奉っているわけではありません。

幾つかのパラダイムを意図してミックスし、さまざまなパターンを利用しています。

f:id:niwatako:20170302143228j:plain

これが非常にいいと思う。

データに反応しなければならないデータソースとコンポーネント間の関係を管理するのがリアクティブプログラミングである。

彼が書いている???も非常に良いのでみて下さい

(これのことかな?↓↓)

www.cocoawithlove.com

f:id:niwatako:20170302143312j:plain

リアクティブの何が良いか。ステートを減らすのが良い。ステートが多いとエラーがあり得るしテストが必要になる。変化に対する反応としてプログラミングをしていく。

特定の演算子によってパワフルになっている。

どのようにというHowではなくWhatにフォーカスできる。

どのようなテクノロジを使ってReactiveなコードを書けるか

f:id:niwatako:20170302143438j:plain

リアクティブフレームワーク

f:id:niwatako:20170302143453j:plain

非常に素晴らしいプロジェクトです。非常に多くのものに対してコミュニティが既にあります。

数年前からあるものも、昨日書かれたものも、様々でしょう。

違いは、デザインと、どれくらいのコントロールレベルかということが違います。

使い勝手が良いものなら、オブザーバブルがあってトランスフォーメーションの演算子が豊富。

それ以外にも大きなフレームワークもあって、あらゆるロジックや複雑なプログラムをリアクティブにするというパワフルなものもある。

違ったフレームワークから違ったコードを出しています。そうすると背後のコンセプトがわかると思います。

f:id:niwatako:20170302143632j:plain

どのような時に使うのか。

いろいろな議論をチームでしました。ある時点まではリアクティブにすると複雑になる。しかしある点を超えるとリアクティブにすると簡単になる。

f:id:niwatako:20170302143710j:plain

うまくいくのはReactiveなバインディングをViewとViewModelの間で行う、あるいは非同期通信、MVVMです

ステートアップデートが非同期処理に基づくと複雑になりますが、そうした複雑性をリアクティブプログラミングは簡単にします。

f:id:niwatako:20170302143813j:plain

データストリーム上でやり取りされている値をオブザーブするというパターンが使われる。

次の値、エラー、完了したイベント、このストリーム上で中断されたものをみていきます。

f:id:niwatako:20170302143902j:plain

f:id:niwatako:20170302143908j:plain

3つのフラグが、それぞれ8つの違う組み合わせがある。

しかしリアクティブにすると、右側になる。

可能性のあるステートは4つだけサポートするので既に削減できた。

f:id:niwatako:20170302143958j:plain

トランスフォームや組み合わせを行うことで出来る簡素化

f:id:niwatako:20170302144015j:plain

最も最新のあたいを両方からコンバインする。

これがストリームをコンバインする戦略です。その際に必要な戦略が有り、またそれは様々です。古い値のマージ、最新へのスイッチ…

f:id:niwatako:20170302144101j:plain

コンバインしてオペレーションをチェーン化することが出来る。特定のメソッドが必要ない。

コンビネーションハンドラをパスしていく、IBActionを定義する、などは必要ない

f:id:niwatako:20170302144156j:plain

ここではボタンクリックとレスポンスをコンバインしている。

f:id:niwatako:20170302144214j:plain

ちょっと問題になる部分

トレードオフの無いものは無い

f:id:niwatako:20170302144227j:plain

No.1の問題はデバッグ

コールスタックはもう友達ではない。何が起きたかを正確に伝えてくれない。

ではどう解決するか。

幾つかトリックが有ります。

一定のストリームに疑いがある時、コンソールログをイベントログにアタッチする

f:id:niwatako:20170302144313j:plain

大抵、(フレームワークには)ログイベントが有ります。

どこでどういうことが起きたかわかります。これはReactiveSwiftの例。

f:id:niwatako:20170302144346j:plain

リアクティブプログラミングを学習してここまでくると、オブザーブをどこでも使いたくなる。しかし、KVOを減らすためにはすべてのリアクティブフレームワークはオーバーヘッドが大きい。

f:id:niwatako:20170302144422j:plain

KVOを単に置き換えているが、リアクティブフレームワークを使っているならバインディングを使うことが出来る。

f:id:niwatako:20170302144458j:plain

ViewModelのタイトルをラベルにバインドしています。

リアクティブフローにこれをコンバインドしていく。

f:id:niwatako:20170302144518j:plain

f:id:niwatako:20170302144545j:plain

副作用が増えると測定が難しくなる。一つ何処かが変わると何が起きるかわからなくなる

しかし良いところもある。

f:id:niwatako:20170302144616j:plain

(よく聞き取れなかった:コールドの場合は毎回インジェクトするとシグナルに新しい / 皆さんが行う実装がどのようにこれを扱うか知らないと使いこなせない)

f:id:niwatako:20170302144652j:plain

Analyticsイベントを置くことになる。誰もアップデートに対してサブスクライブしていない。

(多分こういう話:副作用を注入する、例えばトラッキングなどを仕込むことで、サブスクライブすること無くトラッキングできてこのような場合には便利)

f:id:niwatako:20170302144747j:plain

ReactiveBehaviorを必要ないところに入れてしまうと時間がかかることになる。

いつも役に立つわけではない。問題が起きる例。

f:id:niwatako:20170302144814j:plain

非常に簡単にできるが、サブスクライビングをする時、イベントがどこから来るか分かっていない、コードの周辺からわからない。

このBehaviorによって予期せぬ事態が起きることがある。簡単に治すことも出来る。

Imutable、新しいセットを返すだけにするなど

そのほかに、非常に複雑なネットワークロジックがある

f:id:niwatako:20170302144923j:plain

このためになるべくシンプルにする、一つの変化だけで一人の人間がフォローできないだけ複雑になることもあるので注意する。

展望

f:id:niwatako:20170302144949j:plain

よりシンプルに出来るところで使っていく

f:id:niwatako:20170302145026j:plain

APIを自分で作った時にリアクティブを作っていくのは良いことだと思う。

でも他の人に押し付けてはいけない。

ライブラリをサポートすること、インターフェースのプロパティがオブザーバブルであることを確認する。

f:id:niwatako:20170302145056j:plain

f:id:niwatako:20170302145111j:plain

Q&A

新しいデベロッパーをオンボーディングする時、Reactiveなフレームワークを使うことは有りますか?それに関して問題があったことは有りますか?誰でも簡単にできますか?

これまでは大変なん時期もありました。Reactiveなコードを全くみたことがない方だと学ぶのも楽ではないです。ですがそういった人たちもキャッチアップすることは、毎日触れていれば可能です。新しいコードベースを知るというプロセスよりも遅いかもしれませんが可能です。

また、コミュニティの中でもトレンドが始まってきています。この一年で我々のチームの中での広報がインタビューで話そうとすると、Reactiveでやったことがあるという人が増えています。そういう人が増えればあまり大きな違いはないという状況だと思います。

すべてのライブラリをリストされていましたが、一番使っているのはどれですか?全部試しましたか?一番良いものを選んだなら理由を教えて下さい

ReactiveCocoa?、ReactiveCコードベースを試しました Ustreamでは我々自身の実装が有ります。

私が名前を上げたものはライトウェイトでシグナルがあってオペレーターがあって殆どのマイクロフレームワークと似ているものです、それでも十分役に立ちます。

みんなの反応

もっと反応を見る

togetter.com

気に入った記事は はてなブックマーク

はてなブックマークアプリiOS開発チームから来ました!はてなブックマークにはSwift特集があります!良い記事を見逃さないように、ご利用ください!

http://b.hatena.ne.jp/hotentry/it/Swift

そして良い記事があったらはてなブックマークでブックマークしましょう!

try! Swift の記事で盛り上がると嬉しいです!