ReactiveCocoaフレームワークに興味をお持ちの場合、 リアクティブプログラミングとReactiveCocoaフレームワークのトピックについて、 Meet the ReactiveCocoaやThe Best World with ReactiveCocoaなど、少数の投稿があることに気づいたでしょう 。 今日まで、これらの投稿はすべてReactiveCocoa 2バージョンに関するもので、Objective-C向けに作成されました。 現在、Swift言語の人気が高まっており、ReactiveCocoaの開発者は、Swiftで記述され、この言語の基本的な機能を備えた新しいバージョンに熱心に取り組んでいます。
私のように、あなたの多くは必死にObjective-Cを離れ、Swiftに切り替えたと思います。 ReactiveCocoaを新しい言語で使用する場合は、ReactiveCocoaの新しいバージョンを使用することを強くお勧めします。 そして、私たちのコミュニティはあなたが行った貢献から大きな恩恵を受けると確信しています。 一方、特定の顧客向けに実稼働環境で大規模なビジネスアプリケーションを使用している場合は、そのことを伝えなければなりません。使用する前にこれを行ったり、慎重に考えたりしないでください。 ただし、これについては後で説明します。誰かが興味を持っている場合は、カットをお願いします。
これまでのReactiveCocoaのステータス
この記事の執筆時点では、ReactiveCocoa（今後RACと呼ばれる）は未定義の状態です。 Swiftの最初のバージョンが公開されたとき、開発者はRACの3番目のバージョンで作業を開始しました。 ただし、少し前まで、AppleはXcode 7.0をリリースしました。これには、Swiftバージョン2.0のサポートが含まれています。 これは、RAC3のいくつかの重大な変更が原因ですが、新しいAPIの大幅な簡素化もいくつかあります。 変更により、開発者はRAC4での作業を開始する必要がありました。
RAC4はまだ安定したアプリケーションを作成するためにそれを使用することはできませんが、多くはすでにこれを行っており、システムは頻繁に変更されるため注意が必要です。 変更プロトコルには次のように書かれています。「重大な変更は可能です。アプリケーションに統合する前に、これに備えてください。」
RACSignalに別れを告げる
RAC2では、すべての信号がRACSignalタイプを使用していました。 信号には、ホット（ホット）とコールド（コールド）の2種類があります。 ホットシグナルには、送信されたイベントを処理するサブスクライバが少なくとも1つあり、開始と終了のない閉回路を思い出させます。 コールドシグナルは、サブスクライバーを持たない可能性のあるシグナルの1つであるため、アクションや情報転送を提供しません。 ステージに分割できます。コールドシグナルは、誰かがサブスクライブするまで動作を開始しません。
RAC4は、信号の概念を2つの異なるタイプ、信号プロデューサーと信号に分割します。 信号手順はRACSignalと非常に似ています。 信号はトリガーされるまで非アクティブです。 開発者は、このオプションがこの信号状態をより正確に記述するため、開始にサブスクライブされた単語の用語を変更しました。 たとえば、SignalProducerには、イベントを受信するようにサブスクライブしている複数のサブスクライバーがいる場合がありますが、シグナルはアクティブにならず、サブスクライバーは何らかの理由でトリガーされるまでイベントを見ません。 シグナルは、start（）メソッドを呼び出すことでトリガーされます。
もう1つの新しいタイプはSignalです。 信号は消火ホースのようなものです。 それをソースに接続し、イベントがそれを通過します。 トリガーがない限り、それを使用してSignalProducerのように動作できます。 また、シグナルは履歴をサポートしていません。 サブスクライバーがシグナルからイベントにサブスクライブすると、将来のすべてのイベントを受信しますが、過去の単一のイベントは受信しません。 シグナルは、情報をリアルタイムで送信するのに非常に役立ちます。これは、ユーザーがアプリケーションを操作した結果として発生します。 たとえば、信号は、ユーザーがテキストフィールドに入力した数字と記号を送信できます。
延期方法が削除されました
また、RAC4には延期操作が含まれていないことにも気付くでしょう。 RAC2で関数を呼び出すのとは異なり、信号がホット状態になると、信号を返し、他の操作（デバッグテキストの登録など）を実行する関数を記述する必要がある場合、転送ブロックを使用することがよくあります。
RAC4の延期オプションはもう存在しません。 この例を実証するために、著者は、次のような開始済みを検討することを提案します。
Swift言語の場合：
func logIn(username: String, password: String) -> SignalProducer<String, NoError> { return accountManager.logIn(username, password: password) .on( started: { print("Logging in...") } }
Objective-Cとは異なり
- (RACSignal *)logInWithUsername:(NSString *)username andPassword:(NSString *)password { return [RACSignal defer:^{ NSLog("Logging in..."); return [accountManager logInUser:username withPassword:password]; }]; }
MutableProperties
RAC4で私が本当に気に入っている機能の1つは、MutablePropertyクラスです。 MutablePropertyは、実行時に変化するオブジェクトのコンテナです。 また、サブスクライバーに割り当てられた各値を自動的に送信するシグナルイニシエーターも含まれています。
強い型付け
RAC4に切り替える際の私にとって最も困難なことは、信号に関連する厳密なタイピングに慣れることでした。 RAC2では、信号にはオブジェクトまたはエラーに関する情報は含まれません。 制限は、送信されたすべてのオブジェクトがNSオブジェクト（プリミティブではない）から受信されることだけでした。 RAC4では、このタイプによって定義された値と発生する可能性のあるエラーに対して、シグナルがこのタイプによって定義されます。 例えば
var signalA = SignalProducer<String, ReallyBadError> ...
String型のオブジェクトにのみ送信できる信号を定義します。この場合、ReallyBadErrorのみが発生します。 タイプセーフティには、送信された情報がより明確になるという利点がありますが、同時に信号の組み合わせが複雑になります。
RAC2では、バナナが送信する信号を簡単に取得し、オレンジが送信する信号に接続し、その結果をパイナップルが送信する信号に関連付けることができます。 結果の信号は適切な形式ではありませんが、コードはコンパイルされます。
RAC4では、Peachsが送信する信号を返す可能性のある関数からApplesに送信する信号を返そうとすると、コンパイラはエラーを表示します。
信号の組み合わせ
シグナルの結合は、作成者がシグナル配列を使用してバインディング、マージなどを形成する優れた関数を削除したため、より複雑になります。たとえば、Objective-Cでは、2つのシグナルを結合する場合、 ：
-(RACSignal *) bakeCakeWith:(NSArray *)ingredients { RACSignal *preheatSignal = [self.oven preheat:@(350)]; RACSignal *bakeSignal = [self.baker combine:ingredients]; return [RACSignal concat:@[preheatSignal, bakeSignal]; }
RAC4では、次のことを行う必要があります。
func bakeCake(ingredients: Array) -> SignalProducer<RACUnit, NoError> { let (combinerSignal, combinerSink) = SignalProducer<RACUnit, NoError>.buffer(1) sendNext(combinerSink, self.oven.preheat(350)) sendNext(combinerSink, self.baker.combine(ingredients)) return combinerSignal.flatten(.Concat) }
ただし、Objective-Cと同じように簡単に実行できる独自の関数を作成できます。
私は間違いなくSwiftとRAC4言語に多少の不満を感じていましたが、それは本当に楽しい方法でした。 私は前進し続けることを計画しており、同じことを行うことをお勧めします。
以下に、RACについてさらに学ぶための優れた情報源を示します。
Stanfy MadCode Meetup＃11：なぜObj-CからSwiftに切り替える必要があるのか、またはReactiveCocoa v4について話しましょう
ReactiveCocoaの紹介
ReactiveCOCOA 3.0を使用したMVVM
Reactive Swift：ReactiveCocoa 3.0へのアップグレード