ReactiveCocoaとの知り合い

正直なところ、ReactiveCocoaは流行しているため、ReactiveCocoaを使い始めました。 iOS開発者は常にこのフレームワークについて話していると聞きますが、ReactiveCocoaに言及せずにiOS Meetupをかろうじて思い出すことができます。









ReactiveCocoaの学習を始めたばかりのとき、それが何であるかわかりませんでした。 「リアクティブ」はとてもクールに聞こえ、「機能的」はスマートに聞こえます。 しかし、Reactive Cocoaを手に入れたいという誘惑に負けた後、それを使わずにコードを書くことはもはや想像できません。



ReactiveCocoaは、機能的リアクティブプログラミングの世界への窓を開くフレームワークです。 これにより、FRPの詳細な理論的知識を必要とせずに、このパラダイムの実用化から利益を得ることができます。



実際のプロジェクトでReactiveCocoaを習得し、いくつかの簡単なことを行いました。まず、この記事で説明する2つの問題を解決するためにそれを使用しました。 フレームワークの実用的な理解を得ることができるように、「方法」ではなく「何をすべきか」と言います。

1.コミュニケーション

ReactiveCocoaでの署名は通常、接続から始まります。 結局のところ、それらは初心者が理解できる最も簡単なものです。



関係だけでは、Objective-Cの既存のKVOメカニズムを補完するだけです。 ReactiveCocoaがKVOにもたらす新しい機能はありますか？ このより便利なインターフェイスは、モデルの状態とUIの状態を宣言スタイルでバインドするためのルールを記述する機能も追加します。



テーブルセルの例を使用して関係を見てみましょう。



通常、セルはモデルに接続され、その視覚的状態（またはMVVMアドヒアレントの場合はViewModel状態）を表示します。 ReactiveCocoaは多くの場合MVVMと同じコンテキストで表示されますが、その逆も同様です。 コミュニケーションはあなたの人生を楽にするための手段に過ぎません。

- (void)awakeFromNib { [super awakeFromNib]; RAC(self, titleLabel.text) = RACObserve(self, model.title); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは宣言的なスタイルです。 「ラベルのテキストを常にモデルのタイトル値に等しくしたい」 --awakeFromNibメソッド内。 タイトルやモデルがいつ変更されるかは問題ではありません。



これが内部的にどのように機能するかを見ると、 RACObserveはパス（この例では自己オブジェクトから " mode.title "）を取得し、それをRACSignalに変換するマクロであることがわかります。 RACSignalは、ReactiveCocoaフレームワークのオブジェクトであり、将来のデータを表し、提供します。 この例では、 タイトルまたはモデルが変更されるたびに、「 model.title 」からデータを配信します。



この段階では詳細に立ち入る必要がないため、信号については後で説明します。 現在、モデルの状態をインターフェイスに単に「リンク」して、結果を楽しむことができます。



多くの場合、モデルの状態を変換してUIに表示する必要があります。 この場合、 -map演算子を使用できます。

 RAC(self, titleLable.text) = [RACObserve(self, model.title) map:^id(NSString *text) { return [NSString stringWithFormat:@”title: %@”, text]; }]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UIを使用したすべての操作は、 メインスレッドで実行する必要があります 。 ただし、たとえば、 タイトルフィールドはバックグラウンドスレッドで変更できます（データを処理するときなど）。 新しいタイトルの値をメインストリームでサブスクライバーに配信するために追加する必要があるものは次のとおりです。

 RAC(self, titleLabel.text) = [RACObserve(self, model.title) deliverOnMainThread];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RACObserveは拡張マクロ-rac_valuesForKeyPath：オブザーバー：しかし、ここにトリックがあります-このマクロは常に自分をオブザーバーとしてキャプチャします。 ブロック内でRACObserveを使用する場合は、リンクサイクリングを作成せず、弱いリンクを使用するようにしてください。 ReactiveCocoaには、これらのニーズに対応する便利な@weakifyおよび@strongifyマクロがあります。



接続について注意する必要があるもう1つの詳細は、モデルの状態が、ユーザーインターフェースの重要な変更や、モデルの状態の頻繁な変更に関連付けられている場合です。 これは、アプリケーションのパフォーマンスに悪影響を与える可能性があります。これを回避するには、 -throttle演算子を使用できます。 - NSTimeIntervalを受け入れ、指定した時間間隔後にサブスクライバに「次の」コマンドを送信します。

2.コレクションの操作（フィルター、マップ、削減）

回収作業は、ReactiveCocoaで次に検討したものでした。 配列の操作には時間がかかりますよね？ アプリケーションの実行中に、ネットワークからデータ配列が届き、必要な形式でユーザーに表示できるように変更する必要があります。



ネットワークからの生データは、オブジェクトまたはビューモデルに変換され、ユーザーに表示される必要があります。



ReactiveCocoaでは、コレクションはRACSequenceクラスとして表されます。 CocoaコレクションをReactiveCocoaコレクションに変換するすべてのタイプのCocoaコレクションにはカテゴリがあります。 これらの変換後、 map、filter、reduceなどのいくつかの機能メソッドを取得します。



以下に小さな例を示します。

  RACSequence *sequence = [[[matchesViewModels rac_sequence] filter:^BOOL(MatchViewModel *match) { return [match hasMessages]; }] map:^id(MatchViewModel *match) { return match.chatViewModel; }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、ビューモデルをフィルター処理して、既にメッセージを持っているものを選択します（ -（BOOL）hasMessages ）。 その後、それらを他のビューモデルに変換する必要があります。



シーケンスが完了したら、NSArrayに変換し直すことができます。

 NSArray *chatsViewModels = [sequence array];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もう一度-map：演算子を使用していることに気づきましたか？ ただし、今回は、リンクの場合のように、 RACSignalではなくRACSequenceに適用されます。



RACアーキテクチャの素晴らしいところは、 RACSignalとRACSequenceの 2つの主要なクラスしかなく、親クラスが1つであるRACStreamであるということです 。 ストリーム全体と信号は、ストリームを動かしているプッシュです（新しい値はサブスクライバーにプッシュされて表示できません）。シーケンスは格納式ストリームドライブです（誰かが要求したときに値を提供します）。



注目に値するもう1つのことは、オペレーションをリンクする方法です。 これはRACの重要な概念であり、 RACSignalおよびRACSequenceでも使用されます。

3.ネットワーキング

フレームワークの機能を理解するための次のステップは、それを使用してネットワークで作業することです。 関係について話しているときに、Marcos RACObserveがRACSignalを作成することを言及しました。これは、将来配信されるデータを表します。 このオブジェクトは、ネットワーク要求を提示するのに理想的です。



シグナルは3種類のイベントを送信します。

• next-将来の価値/価値;
• エラー -NSError *値。信号を正常に完了できないことを意味します。
• completed-シグナルが正常に完了したことを意味します。

シグナルの耐用年数は、任意の数の次のイベントで構成され、1つのエラーまたは完了 （ただし、両方ではありません）。



これは、ブロックを使用してネットワーク要求を作成した方法と非常に似ています。 しかし、違いは何ですか？ 従来のブロックを信号で置き換える理由 いくつかの理由があります。



1）コールバックを取り除きます！



この悪夢のコードは、複数のサブクエリがあり、後続のサブクエリがそれぞれ前のサブクエリの結果を使用する場合に発生します。



2）エラーを1か所で処理します。



以下に小さな例を示します。



loginUserとfetchUserInfoの 2つのシグナルがあるとします。 ユーザーに「ログイン」してからデータを受信するシグナルを作成しましょう。

 RACSignal *signal = [[networkClient loginUser] flattenMap:^RACStream *(User *user) { return [networkClient fetchUserInfo:user]; }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

loginUser信号が次のイベントを送信すると、 flattenMapブロックが呼び出され、この値はユーザーパラメーターを介してブロックに渡されます。 flattenMapブロックでは、前の信号からこの値を取得し、結果として新しい信号を生成します。 それでは、このシグナルをサブスクライブしましょう。

 [signal subscribeError:^(NSError *error) { // error from one of the signals } completed:^{ // side effects goes here. block get called when both signals completed }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

少なくとも1つの信号が機能しない場合、 subscribeErrorブロックが発生することに注意してください。 最初のシグナルが失敗すると、2番目のシグナルは実行されません。



3）信号には、組み込みの廃棄（キャンセル）メカニズムがあります。



たとえば、ユーザーはロード中に画面を離れることがよくあります。 この場合、ダウンロード操作をキャンセルする必要があります。 このロジックを信号に直接実装でき、このロード操作へのリンクを保存することはできません。 たとえば、次のようにユーザーデータを読み込む信号を作成できます。

 [[RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) { __block NSURLSessionDataTask *task = [self GET:url parameters:parameters completion:^(id response, NSError *error) { if (!error) { [subscriber sendNext:response]; [subscriber sendCompleted]; } else { [subscriber sendError:error]; } }]; return [RACDisposable disposableWithBlock:^{ [task cancel]; }]; }]];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は意図的にこのコードを単純化してアイデアを示しましたが、実際には、ブロックで自己をキャプチャするべきではありません。



シグナルを参照することにより、いつキャンセルする必要があるかを判断できます。

 [[networkClient loadChats] takeUntil:self.rac_willDeallocSignal];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 [[networkClient loadChats] takeUntil:[self.cancelButton rac_signalForControlEvents:UIControlEventTouchUpInside]];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチの素晴らしい点は、操作を完了する必要がある場合にのみ使用する操作へのリンクを保存しないことです。 したがって、中間状態を維持する必要がないため、コードはより宣言的に見えます。



もちろん、シグナルを手動でキャンセルすることもできます-RACDisposableオブジェクト（ subsribeNext / Error / Completedメソッドから返される）への参照を保存し、必要なときに-disposeメソッドを直接呼び出します。



シグナルを使用してネットワーククライアントを実装することは、かなり広範な議論のトピックです。 OctoKit -Reactive Cocoaを使用してネットワークの問題を解決する方法の好例です。 Ash Furrowは、iOS向けのFunctional Reactive Programmingの本でもこのトピックを取り上げました。

4.動作中のシグナル

いくつかの問題を解決する際に、アプリケーションのさまざまな部分からのデータとイベントの部分を組み合わせました。 データが表示され、非同期に変更されます。 これらについて考える場合、これは必須です。コードに追加する接続と変数を予測し、さらに重要なこととして、これらすべてを時間内に同期する方法を予測しようとします。



おおよその一連のアクションを完成させると、コードの記述を開始し、クラスのさまざまな部分、またはいくつかのクラスでさえ、ジプシーキャラバンのようにプロジェクトを「さまよっている」無用な状態のコードの新しい行で汚染されます。



このようなコードを解析するのがどれほど難しいか知っています！ そして時々、何が起こっているかを知る唯一の方法は、それを段階的にデバッグすることです。



Reactive Cocoaを使用してしばらくしてから、上記のすべての問題（リンク、収集操作、ネットワークの操作）を解決するための基礎は、データストリーム（RACStream）としてのアプリケーションライフサイクルにあることを理解しました。 次に、ユーザーまたはネットワークからのデータを特定の方法で変換する必要があります。 タスクをはるかに簡単に解決できることがわかりました！



2つの例を見てみましょう。



タスク＃1

これは、最近完了した実際のプロジェクトの例です。



メッセージを交換する機会があり、タスクの1つは、アプリケーションアイコンに正しい数の未読メッセージを表示することでした。 通常のタスクではありませんか？



未読のブール値プロパティを格納するChatViewModelクラスがありました。

 @interface ChatViewModel : NSObject @property(nonatomic, readonly) BOOL unread // other public declarations @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、コードのどこかに、これらのビューモデルを含むdataSourcの配列がありました。



何をしたいですか？ 未読プロパティが変更されるたびに、未読メッセージの数を更新します。 要素の数は、すべてのモデルのYES値の数と等しくする必要があります。 信号を使用してこのパターンを実行してみましょう。

 RACSignal *unreadStatusChanged = [[RACObserve(self, dataSource) map:^id(NSArray *models) { RACSequence *sequence = [[models rac_sequence] map:^id(ChatViewModel *model) { return RACObserve(model, unread); }]; return [[RACSignal combineLatest:sequence] map:^id(RACTuple *unreadStatuses) { return [unreadStatuses.rac_sequence foldLeftWithStart:@0 reduce:^id(NSNumber *accumulator, NSNumber *unreadStatus) { return @(accumulator.integerValue + unreadStatus.integerValue); }]; }]; }] switchToLatest];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初心者には少し複雑に見えるかもしれませんが、理解するのはとても簡単です。



まず、配列の変化を観察します。

 RACObserve(self, dataSource)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいチャットを作成し、古いチャットを削除できると想定されているため、これは重要です。 RACには可変コレクション用のKVOがないため、DataSourceは、オブジェクトがdataSourceに追加/削除されるたびに不変の配列になります。 RACObservは、新しい値がdataSourceに追加されるたびに新しい配列を返すシグナルを返します。



さて、私たちは信号を得ました...しかし、これは私たちが望んでいた信号ではないので、それを変換する必要があります。 -map演算子は、このタスクに最適です。

 [RACObserve(self, dataSource) map:^id(NSArray *models) { }]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マップブロックには多くのモデルがあります。 すべてのモデルの未読プロパティの各変更について知りたいので、信号、または信号の配列さえ必要です-各モデルに1つの信号：

  RACSequence *sequence = [[models rac_sequence] map:^id(ChatViewModel *model) { return RACObserve(model, unread); }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここには新しいものは何もありません。 RACSequence、map、RACObserve 。



注： この場合、値のシーケンスを信号のシーケンスに変換します。



実際、それほど多くの信号は必要ありません。1つ必要ですが、重要なのは、絶えず変化するデータを一緒に処理する必要があるためです。 RACで信号を結合するにはいくつかの方法があり、ニーズに合った方法を選択できます。



+ mergeは 、シグナルから単一のストリームに値を転送します。 これはニーズを完全には満たしていません。次のブロックでは、最後の値（この場合はYESまたはNO ）のみが表示されます。



（合計を取得するために）すべての値を知りたいので、 + composeLatestを使用します。信号の変化を監視し、変化が発生したときにすべての信号の最後の値を送信します。 次のブロックでは、すべての未読値の「スナップショット」を見ることができます。

 [RACSignal combineLatest:sequence];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、単一の値が変更されるたびに最新の値の配列を取得できます。 ほぼ完了！ 残っている唯一のタスクは、この配列でYES値が検出される回数を計算することです。 簡単なループでこれを行うことができますが、最後まで機能し、reduceステートメントを使用しましょう。 reduceは、事前定義されたルールによってデータコレクションを単一の原子量に変換する関数型プログラミングの有名な関数です。 RACでは、この関数は-foldLeftWithStart：reduce：または-foldLeftWithStart：reduce：です。

 [unreadStatuses.rac_sequence foldLeftWithStart:@0 reduce:^id(NSNumber *accumulator, NSNumber *unreadStatus) { return @(accumulator.integerValue + unreadStatus.integerValue); }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に不明な点は、なぜswitchToLatestが必要なのかということです。



それなしでは、シグナルのシグナルを受け取ります（配列の値をシグナルに変換するため）。unreadStatusChangedにサブスクライブすると、値ではなく次のブロックでシグナルを受け取ります。 これを修正するには、 -flattenまたは-switchToLatest （ 平坦化されていますが、わずかに違いがあります）を使用できます。



flattenは、現在フラット化されているサブスクライバーが、変換から返される信号を使用して送信された値を受信することを意味します。 -flattenはシグナルからシグナルを受信し、それらに送信される次の値を結合しますが、 -switchToLatestは同じことを行いますが、値は最後のシグナルからのみリダイレクトします。



私たちの場合、 dataSourceの古いバージョンへの変更を受け取りたくないので、これはうまく機能します。 信号は準備ができており、使用できます。副作用を実行しましょう。

 RAC([UIApplication sharedApplication], applicationIconBadgeNumber) = unreadStatusChanged;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題のステートメントがどのようにコードに関連しているかに気づきましたか？ 1つの場所で宣言的に何をしたいのかを書きました。 中間状態を維持する必要はありません。



カスタム信号を作成するための適切な演算子を見つけるために、フレームワークのドキュメントを掘り下げる必要がある場合がありますが、それだけの価値はあります。



タスク＃2



フレームワークの機能を示す別のタスクを次に示します。 チャットリスト画面がありました。タスクは、チャットリスト画面を開いた状態で、最後のチャットメッセージを表示することでした。 生成された信号は次のようになります。

 RACSignal *chatReceivedFirstMessage = [[RACObserve(self, dataSource) map:^id(NSArray *chats) { RACSequence *sequence = [[[chats rac_sequence] filter:^BOOL(ChatViewModel *chat) { return ![chat hasMessages]; }] map:^id(ChatViewModel *chat) { return [[RACObserve(chat, lastMessage) ignore:nil] take:1]; }] ; return [RACSignal merge:sequence]; }] switchToLatest];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それが何で構成されるかを見てみましょう。



この例は、前の例と非常によく似ています。 配列を観察し、マップ演算子が値を信号に変換し、最新の信号のみを考慮します。



まず、メッセージのあるチャットには関心がないため、変換ブロックでdataSourceをフィルター処理します。



次に、再びRACObserveを使用して、値をシグナルに変換します。

 return [[RACObserve(chat, lastMessage) ignore:nil] take:1];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

RACObserveによって生成されたシグナルはプロパティの初期値（nil）で起動するため、 -ignore ：を無視する必要があります。 演算子が必要です。



タスクの2番目の部分は、最初の着信メッセージ-Take：のみを考慮することです。 それの世話をします。 シグナルは、最初の値を受信するとすぐに完了（および削除）されます。



明確にするためだけです。 このコードで作成した3つの新しい信号があります。 最初はRACObserveマクロによって作成され、2番目は最初に新しく作成されたシグナルのステートメントの-ignore：を呼び出して、3番目は-take：を呼び出して-ignoreによって作成されたシグナルによって：



前の例のように、生成された信号に基づいて1つの信号が必要です。 前の例のように値を気にしないため、 -merge：を使用して新しいマージされたストリームを作成します。



副作用時間！

 [chatReceivedFirstMessage subscribeNext:^(id x) { // switching to chat screen }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注： 信号に含まれる値は使用しません。 ただし、 xには受信したメッセージが含まれます。



それでは、Reactive Cocoaの印象について少し話しましょう。



Reactive Cocoaについて私が本当に好きなこと



1.プロジェクトでの使用は簡単です。 フレームワークは狂ったように文書化されています。 GitHubには多くの例があり、各クラスとメソッドの詳細な説明、多数の記事、ビデオ、プレゼンテーションがあります。



2.プログラミングスタイルを完全に変更する必要はありません。 まず、UIバインディング、ネットワークラッパー、GitHubを使用したその他のソリューションなど、問題に対する既存のソリューションを使用できます。 その後、段階的に、Reactive Cocoaのすべての機能を理解できます。



3.問題の解決方法が命令型から宣言型に変わります。 プログラミングの機能的なスタイルがiOSコミュニティでますます一般的になってきているため、多くの人が基本的に考え方を変えることは困難です。 Reactive Cocoaには、「 方法 」スタイルではなく「何をする」スタイルで通信するのに役立つ多くのツールがあるため、変更を加えるのに役立ちます。



Reactive Cocoaが気に入らない点



1. RAC（）またはRACObserve（）マクロの普及。



2. RACSignalsを使用すると深いスタックトレースが発生するため、コードのデバッグが困難な場合があります。



3. タイプセーフではありません（ subscribeNextブロックでどのタイプが期待されるかわかりません）。 この場合の最良の解決策は、例として、パブリックインターフェイスで信号を文書化することです。

 /** * Returns a signal which will send a User and complete or error. */ -(RACSignal *)loginUser;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私も助けることはできませんが、スウィフトに言及します



Reactive CocoaはObjective-Cで、特にObjective-C向けに作成されています。 しかし、もちろん、Swiftの人気が高まっている今、フレームワーク開発者は怠けているわけではありません。 彼らは、Reactive Cocoa（Great Swiftening close）で使用するために、実際にSwift APIを作成します。 控えめに言えば、ブラックジャックと売春婦、ジェネリック、およびオペレーターのオーバーロードを備えた新しいバージョン3.0があります。



この後、RACはさらに多くのファンを獲得すると確信しています。 まもなく、マクロと非型安全性を呪う完璧主義者は、Reactive Cocoaを使用せずに自分自身を保護するという議論を持ちません。

おわりに

機能的で応答性の高いアプローチにより、日常のタスクを簡素化できます。 おそらく、第一に、RACの概念は複雑すぎるように思われ、その決定は面倒で巨大であり、オペレーターの数はあなたを大きく混乱させます。 しかし、後で、これらすべてが単純なアイデアを持っていることが明らかになります。



データ（入力または出力）をストリームとして提示します。イベント（データ、エラー、完了）のパイプのようなストリーム。シグナルとシーケンスはストリームです。シグナルは制御されたストリームです。何かがあると、ユーザーに入力を与えたり、ディスクからの非同期ロードなどを行います。シーケンスは、格納式ドライブを備えたスレッドです。何かが必要な場合は、シーケンス（コレクションなど）から描画します。他のすべての変換演算子および結合演算子は、これらすべてを一緒に変換します（変換、フィルター、結合、switchToLatest、チョークなど）。



さらに、すべてのイベントは、作成されたストリーム内のサブスクライバーに配信されることを覚えておく必要があります。それを指定する必要がある場合は、-deliverOn演算子を使用してこのRACScheduler（GCDキューに似ていますが、キャンセルする機能を持つクラス）を適用します：



一般的なルールとして、あなたは明示的インターフェイスを更新するだけで、[RACScheduler mainThreadScheduler]を指定する必要がありますが、独自の実装を書くことができRACSceduler、のようなものを特定して、あなたしている取引、CoreDataを。