Objective-Cのリアクティブプログラミング

時間の経過とともに、プログラミング言語は、新しい技術の出現、現代の要件、またはコードの記述スタイルを更新したいという単純な欲求のために、絶えず変化し開発しています。 リアクティブプログラミングは、Reactive Cocoaなどのさまざまなフレームワークを使用して実装できます。 これにより、Objective-C言語の命令型が変更され、このプログラミングアプローチには標準的なパラダイムを提供するものがあります。 もちろん、これはiOS開発者の注目を集めています。



ReactiveCocoaは、Objective-Cに宣言型のスタイルをもたらします。 それはどういう意味ですか？ C、C ++、Objective-C、Javaなどの言語で使用される従来の命令型スタイルは、次のように説明できます。特定の方法で実行する必要があるコンピュータープログラムのディレクティブを記述します。 言い換えれば、あなたは何かを「する方法」と言います。 宣言型プログラミングでは、「実行方法」を定義せずに、制御フローを一連のアクション、「実行すること」として記述することができます。

命令型プログラミングと関数型プログラミング

プログラミングへの必須のアプローチには、コンピューターがタスクを完了するために必要な各ステップの詳細な説明が含まれます。 実際、命令型スタイルはネイティブプログラミング言語で使用されます（またはマシンコードを記述するときに使用されます）。 ちなみに、これはほとんどのプログラミング言語の特徴的な機能です。



それどころか、機能的アプローチでは、実行する必要がある一連の機能を使用して問題を解決します。 各関数の入力パラメーターと、各関数が返すものを定義します。 これら2つのプログラミングアプローチは非常に異なります。



言語間の主な違いは次のとおりです。

1.状態の変更

純粋な関数型プログラミングの場合、副作用がないため、状態の変更は存在しません。 副作用には、何らかの外部操作による戻り値に加えて、状態の変化が含まれます。 部分式のSP（参照透過性）は、多くの場合「副作用なし」と定義され、主に純粋な関数を指します。 合弁会社は、各部分式が定義により関数呼び出しであるため、関数が関数の変数状態に外部アクセスすることを許可しません。



問題を明確にするために、純粋関数には次の属性があります。

• 唯一の注目すべき結論は戻り値です
• 入力パラメーターの唯一の依存関係は引数です
• 引数は、出力を生成する前に完全に定義されます

機能的なアプローチは副作用を最小限に抑えるという事実にもかかわらず、それらはあらゆる開発の内部的な部分であるため、完全に回避することはできません。



一方、命令型プログラミングの関数には参照の透明性がなく、これが宣言型アプローチと命令型アプローチの唯一の違いである可能性があります。 副作用は、状態とI / Oを実装するために広く使用されています。 ソース言語のコマンドは状態を変更できるため、同じ言語式に対して異なる値が得られます。



リアクティブココアはどうですか？ これはObjective-Cの機能フレームワークです。Objective-Cは概念的に命令型の言語であり、明示的に純粋な関数は含まれません。 状態の変化を回避しようとする場合、副作用は制限されません。

2.最初のクラスのオブジェクト

関数型プログラミングには、ファーストクラスのオブジェクトであるオブジェクトと関数があります。 これはどういう意味ですか？ これは、関数がパラメーターとして渡されるか、変数に割り当てられるか、関数から返されることを意味します。 なぜこれが便利なのですか？ これにより、実行ブロックを簡単に管理し、関数ポインター（char *（*（** foo [] [8]）（））[];-fun！）などのさまざまな方法で関数を作成および結合することができます。



命令型アプローチを使用する言語には、ファーストクラス式に関する独自の特性があります。 Objective-Cはどうですか？ クロージャー実装としてブロックがあります。 高次関数（FWP）は、ブロックをパラメーターとして受け入れることでモデル化できます。 この場合、ブロックはクロージャーであり、特定のブロックのセットから高次関数を作成できます。



ただし、関数型言語でFVPを操作するプロセスはより高速な方法であり、必要なコード行が少なくなります。

3.メインストリーム管理

命令型のループは、関数型プログラミングの再帰関数の呼び出しとして表されます。 関数型言語の反復は通常、再帰によって行われます。 なんで？ おそらく複雑さのために。 Objective-Cの開発者にとって、ループはプログラマにとって非常に役立ちそうです。 再帰は、RAMの過剰な消費などの問題を引き起こす可能性があります。



しかし！ ループや再帰を使わずに関数を書くことができます。 コレクションの各要素に適用できる無限に可能な特殊化されたアクションのそれぞれに対して、関数型プログラミングは「 map 」、「 fold 」、「 filter 」などの再利用可能な反復関数を使用します。 これらの機能は、ソースコードのリファクタリングに役立ちます。 重複を減らし、別の関数を書く必要がありません。 （続きを読んで、これについてもっと情報があります！）

4.実行の順序

宣言式は、subexpression関数への引数の論理関係と定数状態関係のみを示します。 そのため、副作用がない場合、各関数呼び出しの状態の遷移は他の関数呼び出しとは独立して発生します。



命令式の機能的な順序は、揮発性の状態に依存します。 したがって、実行順序は重要であり、ソースコードの構成によって暗黙的に決定されます。 この問題では、両方のアプローチの評価戦略の違いを指摘できます。



関数型プログラミング言語で必要なときに呼び出される遅延計算または計算は、戦略です。 この場合、式の評価はその値が必要になるまで延期されます。これにより、評価が繰り返されるのを防ぎます。 つまり、式は依存式を評価するときにのみ評価されます。 操作の順序が不明確になります。



それどころか、命令型言語での精力的な計算は、変数にバインドされるとすぐに式が評価されることを意味します。 このため、部分式には他の式の計算に影響する副作用があるため、部分式（関数を含む）がいつ計算されるかを判断するのは簡単です。

5.コードの量

これは重要です。機能的なアプローチでは、命令型よりも少ないコードを記述する必要があります。 これにより、クラッシュが少なくなり、テストするコードが少なくなり、開発サイクルがより生産的になります。 システムは常に進化し成長しているため、これは重要です。

ReactiveCocoaの主要コンポーネント

関数型プログラミングは、future（変数の読み取り専用表現）およびpromise（futureの読み取り専用表現）として知られる概念で機能します。 それらには何が良いのでしょうか？ 命令型プログラミングでは、既存の値を操作する必要があるため、非同期コードと他の問題を同期する必要が生じます。 ただし、futureおよびpromiseの概念を使用すると、まだ作成されていない値を操作できます（非同期コードは同期方式で記述されます）。

信号

未来と約束は、リアクティブプログラミングのシグナルとして提示されます。 RACSignalは、ReactiveCocoaの主要コンポーネントです。 これは、将来提示されるイベントのストリームを提示する機会を提供します。 シグナルをサブスクライブし、時間の経過とともに発生するイベントにアクセスします。 シグナルはプッシュドリブンストリームであり、ボタンを押す、非同期ネットワーク操作、タイマー、その他のUIイベント、または時間の経過とともに変化するあらゆるものを使用できます。 非同期操作の結果をバインドし、複数のイベントソースを効果的に結合できます。

シーケンス

別のタイプのストリームはシーケンスです。 信号とは異なり、シーケンスはプル駆動型のストリームです。 これは、NSArrayと同じ目的を持つ一種のコレクションです。 RACSequenceを使用すると、 NSArrayコレクションのように、特定の操作を連続的にではなく、必要に応じて実行できます。 シーケンス内の値は、デフォルトで指定されている場合にのみ評価されます。 シーケンスの一部のみを使用すると、パフォーマンスが向上する可能性があります。 RACSequenceを使用すると、Cocoaコレクションを普遍的で宣言的な方法で処理できます。 RACは、ほとんどのCocoaコレクションクラスに-rac_sequenceメソッドを追加して、RACSequencesとして使用できるようにします 。

チーム

特定のアクションに応じて、 RACCcommandが作成され、シグナルをサブスクライブします。 これは主にUIインタラクションに適用されます。 ReactiveCocoaが提供するほとんどのUIKitコントロールのUIKitカテゴリは、UIイベントを処理する正しい方法を提供します。 ボタンのクリックに応答してユーザーを登録する必要があると想像してみましょう。 この場合、コマンドはネットワーク要求を表す場合があります。 プロセスが開始されると、ボタンはその状態を「非アクティブ」に、またはその逆に変更します。 他に何？ チームでアクティブな信号を送信できます（到達可能性が良い例です）。 したがって、サーバーが使用できない場合（これが "オンシグナル"）、コマンドは使用できなくなり、関連するコントロールの各コマンドはこの状態を反映します。

基本操作の例

基本的なRACSignals操作がどのように機能するかを示す図を次に示します。

マージ

+ (RACSignal *)merge:(id<NSFastEnumeration>)signals;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果スレッドには、両方のイベントストリームがマージされています。 したがって、「+マージ」は、イベントの特定のソースを気にせず、1か所で処理したい場合に役立ちます。 この例では、stateLabel.textは実行、完了、エラーの3つの異なる信号を使用します。

 RACCommand *loginCommand = [[RACCommand alloc] initWithSignalBlock:^RACSignal *(id input) { // let's login! }]; RACSignal *executionSignal = [loginCommand.executionSignals map:^id(id value) { return @"Connecting.."; }]; RACSignal *completionSignal = [loginCommand.executionSignals flattenMap:^RACStream *(RACSignal *next) { return [[[next materialize] filter:^BOOL(RACEvent *event) { return event.eventType == RACEventTypeCompleted; }] map:^id(id value) { return @"Done"; }]; }]; RACSignal *errorSignal = [loginCommand.errors map:^id(id value) { return @"Sorry :("; }]; RAC(self.stateLabel, text) = [RACSignal merge:@[executionSignal, completionSignal, errorSignal]];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンビネラテスト

 + (RACSignal *)combineLatest:(id<NSFastEnumeration>)signals reduce:(id (^)())reduceBlock;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、ストリームには、送信されたストリームの最新の値が含まれます。 スレッドの1つが重要でない場合、結果は空になります。









いつ使用できますか？ 前の例を取り上げて、さらにロジックを追加しましょう。 ユーザーが正しい電子メールとパスワードを入力した場合にのみ、ログインボタンを有効にすると便利ですよね？ このルールは次のように宣言できます。

 ACSignal *enabledSignal = [RACSignal combineLatest:@[self.emailField.rac_textSignal, self.passwordField.rac_textSignal] reduce:^id (NSString *email, NSString *password) { return @([email isValidEmail] && password.length > 3); }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

*では、ログインコマンドを少し変更して、実際のloginButtonに接続しましょう。

 RACCommand *loginCommand = [[RACCommand alloc] initWithEnabled:enabledSignal signalBlock:^RACSignal *(id input) { // let's login! }]; [self.loginButton setRac_command:loginCommand];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

平坦化マップ

 - (RACSignal *)flattenMap:(RACStream * (^)(id value))block;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数を使用して、元のスレッドの値ごとに新しいスレッドを作成します（f）。 結果ストリームは、ソースストリームで生成された値に基づいて新しい信号を返します。 したがって、非同期にすることができます。









システムでの認証のリクエストは、Facebook（識別子など）からのデータの受信とバックエンドへの転送という2つの部分で構成されていると想像してみましょう。 要件の1つは、ログインをキャンセルできる必要があります。 したがって、クライアントコードは、キャンセルできるようにログインプロセスの状態を処理する必要があります。 これにより、特に複数の場所からログインできる場合、多くの定型コードが提供されます。



ReactiveCocoaはどのように役立ちますか？ これはログインの実装である可能性があります。

 - (RACSignal *)authorizeUsingFacebook { return [[[FBSession rac_openedSession] flattenMap:^RACStream *(FBSession *session) { return [session rac_fetchProfile]; }] flattenMap:^RACStream *(NSDictionary *profile) { return [self authorizeUsingFacebookProfile:profile]; }]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

凡例：

+ [FBSession rac_openedSession]-FBSessionの開始につながるシグナル。 必要に応じて、 Facebookのログインにつながる可能性があります 。



-[FBSession rac_fetchProfile]-selfとして送信されるセッションを通じてプロファイルデータを取得する信号。



このアプローチの利点は、ユーザーにとってストリーム全体がファジーであり、Facebookログインかバックエンドコールかに関係なく、「ステージ」でキャンセルできる単一の信号で表されることです。

フィルター

 - (RACSignal *)filter:(BOOL (^)(id value))block;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果として、ストリームには、指定された関数に従ってフィルタリングされたストリーム「a」の値が含まれます。

 RACSequence *sequence = @[@"Some", @"example", @"of", @"sequence"].rac_sequence; RACSequence *filteredSequence = [sequence filter:^BOOL(id value) { return [value hasPrefix:@"seq"]; }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

地図

 - (RACSignal *)map:(id (^)(id value))block;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FlattenMapとは異なり、Mapは同期的に実行されます。 プロパティ「a」の値は、指定された関数f（x + 1）を通過し、表示された初期値を返します。









画面にモデルタイトルを入力し、それにいくつかの属性を適用するとします。 「一部の属性の適用」が別の機能として説明されている場合、マップが機能します。

 RAC(self.titleLabel, text) = [RACObserve(model, title) map:^id(NSString *modelTitle) { NSDictionary *attributes = @{/*your custom font, paragraph style, etc*/}; return [[NSAttributedString alloc] initWithString:modelTitle attributes:attributes]; }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

仕組み： self.titleLabel.textを 、カスタム属性を適用してmodel.titleの変更と組み合わせます。

郵便番号

 + (RACSignal *)zip:(id<NSFastEnumeration>)streams reduce:(id (^)())reduceBlock;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果フローイベントは、各スレッドが同数のイベントを生成したときに作成されます。 これには、3つの結合されたスレッドのそれぞれからの値が含まれます。









いくつかの実用的な例では、zipはdispatch_group_notifyとして記述できますたとえば、3つの別々の信号があり、それらの応答を単一のポイントで結合する必要があります。

 NSArray *signals = @[retrieveFacebookContactsSignal, retrieveAddressBookContactsSignal]; return [RACSignal zip:signals reduce:^id (NSArray *facebookContacts, NSArray *addressBookContacts){ NSArray *mergedContacts = // let's merge them somehow ^_^ return mergedContacts; }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スロットル

 - (RACSignal *)throttle:(NSTimeInterval)interval;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特定の期間に設定されたタイマーを使用して、ストリーム「a」の最初の値はタイマーの最後でのみ結果ストリームに送信されます。 指定された時間間隔内に新しい値が生成されると、最初の値が保持され、結果ストリームに転送されなくなります。 代わりに、結果ストリームに2番目の値が表示されます。









驚くべきケース：ユーザーがsearchFieldを変更したときにオンデマンドで検索を行う必要があります。 標準的なタスクですか？ ただし、textFieldは1秒間に多くのそのようなイベントを生成する可能性があり、ネットワークを非効率的に使用するため、テキストが変更されるたびにネットワークリクエストを作成および送信するにはあまり効果的ではありません。

ここでの解決策は、遅延を追加してからネットワーク要求を実際に実行することです。 これは通常、NSTimerを追加することで実現されます。 ReactiveCocoaを使用すると、はるかに簡単になります！

 [[[seachField rac_textSignal] throttle:0.3] subscribeNext:^(NSString *text) { // perform network request }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

*ここで重要な点は、「最後の」テキストフィールドが削除される前に、すべての「前の」テキストフィールドが変更されることです。

遅延/遅延

 - (RACSignal *)delay:(NSTimeInterval)interval;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ストリーム「a」で受信された値は遅延され、一定の時間間隔後に結果ストリームに送信されます。











類似として-[RACSignalスロットル：]、遅延は「次の」および「完了した」イベントの送信のみを遅延させます。

 [[textField.rac_textSignal delay:0.3] subscribeNext:^(NSString *text) { }];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Reactive Cocoaの好きなところ

• iOSでCocoaバインディングを導入
• 将来のデータに対する操作を作成する機能。 Scalaの先物と約束についてのちょっとした理論があります。
• 非同期操作を同期方式で提示する機能。 リアクティブCocoaは、ネットワークコードなどの非同期ソフトウェアを簡素化します。
• 便利な分解。 ユーザーイベントとアプリケーションの状態の変更に関連付けられたコードは、非常に複雑でわかりにくくなる可能性があります。 Reactive Cocoaは、依存する操作モデルを特にシンプルにします。 結合されたフローの形式で操作を提示すると（たとえば、ネットワーク要求、ユーザーイベントなどの処理）、高度なモジュール性と自由な通信を実現でき、コードをより頻繁に繰り返し使用できます。
• プロパティ間の動作と関係は宣言型として定義されます。
• 同期の問題を解決します-複数のシグナルを組み合わせる場合、すべての結果を処理するための単一の場所があります（次の値、完了シグナル、エラーのいずれか）

RACフレームワークを使用すると、より優れた高レベルの方法で値のシーケンスを作成および変換できます。 RACを使用すると、ネットワークの応答、依存値の変更、その後の反応など、非同期操作の完了を期待するすべてを管理しやすくなります。 一見して対処するのは難しいですが、ReactiveCocoaは伝染性です！