カテゴリー: programming

Cocoaにおける同期

ひとつのアプリケーションに複数のスレッドがあると、同じリソースに対する複数スレッドから変更が意図せず干渉する場合がある。基本的かつ有効な方針は、共有リソースを減らし、スレッド間のやり取りを最小化することだ。

不変オブジェクトはスレッドセーフであるので、スレッド間で安全に受け渡しすることができる。また、そもそもあるオブジェクトが単一のスレッドからしか利用されない場合は、当たり前ではあるがなにも問題はない。Foudationの基本的なクラスはだいたいスレッドセーフになっているが、そうでないものもあるので注意が必要。

同期ツール

しかし、完全に干渉のない設計が常にできるわけではないのでその場合には同期ツールを使う。同期ツールには以下のようなものがある。

  • アトミック操作: 単純なデータ型を操作するだけの同期、スレッドをブロックしない点が特徴
  • メモリバリア: 確実に正しい順序でメモリ操作を実行させる
  • ロック: クリティカルセクションの保護ができる
  • 条件変数: 特定の条件に該当する場合にスレッド同士シグナルを送り合う

パフォーマンス

  • mutex: 0.2 μsec
  • compare and swap: 0.05 μsec

デッドロックおよびライブロックへの配慮

単一のスレッドで複数のロックを同時に取得しようとする場合は、常にデッドロックが発生する可能性がある。できるだけそういう処理を避ける。

アトミック操作

ハードウェア命令とメモリバリアにより、特定の操作を必ず完了してから、その操作の影響を受けるメモリへのアクセスが再開されるような仕組みになっている。

対応している演算は以下のとおり

  • Add: 加算
  • Increment: +1
  • Decrement: -1
  • 論理OR: OR
  • 論理AND: AND
  • 論理XOR: XOR
  • compare and swap:
    • 古い値と変数を比較して等しい場合に、新しい値を代入する
    • 比較と代入をアトミックに行う
  • test and set:
    • 変数ないのビットをテストし、このビットを1にして、元のビットの値をブール値として返す
  • test and clear:
    • 指定された変数内のビットをテストし、このビットを0にして、元のビットの値をブール値として返す

ロック

いろいろなロック

  • ミューテックス: リソースを囲む保護バリアとして機能する相互排他的なロック。一度に1つのスレッドだけにアクセスを許可するセマフォの一種。
  • 再帰ロック: ミューテックスロックの亜種。ロックを取得した単一のスレッドで、そのロックを解放する前に複数回ロックを取得できる。同じ回数アンロックをかけるとロックを解除できる。
  • 読み取り/書き込みブロック: 共有排他ロックのこと。規模の大きな操作で利用することがおおい。データの読み取りを頻繁に行いながら、部分修正するような場合にパフォーマンスが良い。POSIXスレッドを用いる。
  • 分散ロック: プロセスレベルの相互に排他的なアクセスを実装できる
  • スピンロック: 条件が真になるまでロックの条件を繰り返しポーリングする。粗相されるロック待機時間が短いマルチプロセッサシステムで用いられる。カーネルプログラミングにより実装する。

POSIXミューテックスロック

どのアプリケーションからも利用できる。

NSLock

tryLock() -> Bool とか lockBeforeDate など便利なやつもいる。

NSRecrsiveLock

同一スレッドによる複数回ロック取得が可能なロック。ロック数をカウントしているので、対応するアンロックがすべて走ってようやくロックが解除される。使い方は NSLock と同じ。再帰呼び出しが発生する場合はこれを使うべし。ただ再帰呼び出しが発生しないように実装できるならばその限りでない。

NSConditionLock

NSConditionLock は特定の値を使用してロックおよびロック解除できるミューテックスロックを定義する。

条件変数の利用

条件変数は、必要な順序に合わせて操作を進めるために使用出来るロック。ある条件で待機しているスレッドはその条件のシグナルが別スレッドから明示的に送られるまでブロックされたままになる。

NSConditionの利用

Appendix

参考文献

Apple公式のこれとかこれとかこれを読んだ。

用語の定義

ドキュメントの中では用語の定義が以下のようになされている。

  • スレッド: コードを実行する、他とは切り離されたパスのこと
  • プロセス: 動作中の実行形式コードのことで、複数のスレッドから成ることもある
  • タスク: 実行するべき処理を表す、抽象的な概念

スレッドの代替テクノロジ

  • オペレーションオブジェクト: NSOperation のインスタンス, 通常は OperationQueue に突っ込んで使う
  • Grand Central Dispatch(GCD)
  • 他、アイドル時間通知, 非同期関数, タイマー, プロセス

Reactive Programming with Scala and Akka を読んでる #01

会社の近所でReactive Programming with Scala and Akka読書会なるものが開催されるようなので、参加することにした。とりあえず予習がてら初めの方をずらっとなめていってます。

1. Introducing Reactive Programming

最初に、リアクティブプログラミングが必要とされるまでの歴史なんかが書いてあった。ネットユーザー超増えてるので、データ転送量も指数関数的に増えてる。モバイルデバイスの利用も増えており、リアルタイムにデータを早く処理する必要も生じてきている云々。

Reactive とは

以下の4つの性質をもっているようなアプリケーション

  1. Responsive(高レスポンス)
  2. Resilient(耐障害性)
  3. Elastic(伸縮性)
  4. Message-driven(メッセージ工藤)

なるほどー。本読みながらまとめてくのめんどいな。気が向いたら更新します。

RxSwiftライブラリの作り方 〜Observer/Observable編〜

 RxSwiftライブラリの作り方をご紹介します。一つの記事ですべてを説明するのは非常に厳しいので、まず ObserverObservable といった基本的なコンポーネントとその周辺について、ひとつずつ作っていく流れで説明します。

注意事項

  • 以下の内容を理解しなくても RxSwift は十分使えるライブラリです
  • まだ Rx 系のライブラリを使ったことがない方は、まずライブラリを使ってみてください
    • Qiitaの記事を読むのもよいですが、公式のドキュメントExampleが充実しているのでそちらを読みながら、まずはコードを書いてみることを強くお勧めします。意外に簡単に使いどころが理解できるようになると思います。
  • 記事の内容的には Rx 系ライブラリの利用経験がなくても分かるように書いたつもりです
  • 以下の実装は RxSwift のものであり、他言語の Rx ライブラリとは実装が異なる場合があります

Observerパターンの復習

以下の問題について考えていきます

  • 【問題】 A が更新されたことを、B に通知したい
  • 【解決策】 A が B のインスタンスを保持し、B に 変更を伝える

解決策を単純に実装すると、次のような構造になると思います

 シンプルですが、問題をしっかりと解決できています。続いて「通知先が増えそうである」という条件が加わったを場合を考えてみましょう。このままでは、次のような問題が発生しそうです。

  • 通知先が増減するたびに A の内部を変更しなければならない
  • 通知先のI/Fの変更により A の内部を変更しなければならない

 この2点はともに、通知元が通知先のオブジェクトの詳細を知っていることによって生じている問題です。通知元はどうあがいても、通知先を保持しなければなりませんが、その詳細を知ったまま保持する必要はないはずです。

 したがって通知元は、必要のない情報をそぎ落とした状態で通知先のオブジェクトを保持すれば、問題が解決しそうです。つまり、通知先に共通のインターフェース(Swiftのプロトコル)を切ればよいということになります。

 また、通知元のオブジェクトの種類を増やしたいとすれば、こちらもインターフェースを切っておくと使いまわしが効いて便利です。ObserverObservable からの通知を受け取り始めるための attach というメソッドと、通知の受け取りを解除するための detach というメソッドがあれば十分でしょう。

 この形式を pull 型 Observer パターンと呼びます。Observer が通知を受けたあとに、Observable から値を引っ張ってこなければならないために pull という名前が付いています。以下のように Observable が更新時に Observer に対して値を投げるような実装も可能です。こちらは push 型とよばれています。

 この UML を Swift の実装へ単純に落とし込むことはできません。Swiftの protocol は、generic type parameter を持つことができないからです。代わりに関連型 (〜2.2: typealias, 2.3+: associatedtype) で表現する必要があります。

 ここまでくれば Observerパターンの基礎についてはなんとなく理解できるようになっているのではないかと思います。次節では RxSwift ではどのように push 型の Observer パターンに用いられる基本的なコンポーネントを構成しているかを見ていきます。

Observer, Observable を作る(Rxライブラリの下ごしらえ)

 ここからは実際に RxSwift でどのように Observer と Observable が定義されているかを見ていきましょう。基本的には push 型の Observer パターンをそのまま実装していけば良いだけです。ただしRxでは値を単純に通知するのではなく、成功(Next)、失敗(Error)、完了(Completed)という文脈をつけた イベント を通知します。また、ObserverObservable に登録した際に Disposable というI/Fを持ったオブジェクトを返し、そのオブジェクトに購読解除の機構を持たせている点も特徴的です。

したがって実現したい構造は下図のようなものになります。
 

ObserverType, ObservableType の実装

 前述したとおり、protocol には generic type parameter を用いることができないので、まず関連型を用いて ObserverTypeObservableType を以下のように定義します。

AnyObserver, Observable の実装

 さて、こうして定義した protocol を generic type parameter を用いたクラスに落とし込みます。Swiftの言語機能が不足しているので、ここは醜い表現になっていますが、 本来であればインスタンス化できないように abstract class にするような部分 だと思います。RxSwift 内では、苦し紛れですが @noreturn アノテーションを用いて抽象メソッドを表現しています。

 ここで登場するパターンは、なぜか皆さん大好きな type erasure ですが、これをやらなきゃいけないのは決して褒められたことではないと思います。個人的には普通にJavaより劣ってるでしょって感想です(←炎上しそう)。Swift の protocol が generic type parameter を持てない理由については、この記事によくまとまっているようですが、この点について自分は理解できてはいません。Swiftの言語仕様に阻まれ、随分遠回りにはなりましたが、無事 Observable<Element>Observer<Element> を定義することができました。

Observableの具象クラスを作ろう

Bag, SubscriptionDisposable の実装

 先ほど定義した Observable<Element> の実装クラスを作成してみましょう。実装が必要なメソッドは subscribe です。ここでは受け取った observer を保持する必要があります。
 
 observerO: ObserverType where O.E == E という制約のもと渡ってきますが、ObserverType のコレクションを作ることは残念ながらできません。なぜなら ObserverType は abstract type member を持っているからです。ここでは、型制約を利用して AnyObserver<E> のコレクションに突っ込んであげればよいでしょう。例が稚拙で申し訳ないのですが、Observable<String> であるような StringObservable を定義するとして、書き出しは以下のようになると思います(実際のライブラリにはこのようなクラスは存在しません)。

 subscribe に渡った observer は、observers に登録され、何かイベントがあったら通知されるようになりました。イベント購読の機能の実装はこれでとりあえずOKとしましょう(いろいろ細かい問題はありますがとりあえず置いておく)。
 
 続いてイベント購読解除の仕組みを作る必要があります。これは単に observers から購読を解除したい observer を削除してあげれば良いだけです。現状は配列に突っ込んでいますが、辞書的なものに突っ込んでキーを指定して削除できた方が、取り回しが良いでしょう。
 
 そこで、要素を追加すると同時に、 id を発行するコレクション Bag を作ります。差し当たっての問題は、どのように id を生成するのかということです。ここでは Swift の unsafeAddressOf メソッドが暗躍します。クラスのインスタンスはメモリを確保するため、インスタンスそのものがある種の id の役割を持っています。そして、メモリの番地を取得するのが unsafeAddressOf メソッドになります。

 こうしてコレクションのキーとなる BagKey の実装が終わりました。続いてコレクションの本体となる Bag について考えましょう。RxSwift の Bag の実装は要素数が少ないときに最適化されるような仕組みがのっていますが、本質だけ抜き出すとただの Key-Value store です。

 準備が整いました。もう一度やることを確認しておきましょう。Observable#subscribe では以下のことを行いたいのでした。

  1. 受け取った observerBag に突っ込む(通知先を保持する)
  2. 受け取った observerBag から一意探せるようなキーと、Observable 自身の弱参照を持ち、dispose で購読解除ができるような Disposable オブジェクトを返す

 2. のようなことができる Disposable の具象クラスとして SubscriptionDisposable というものを実装していきましょう。構造はとても単純で、以下のようなものになります。

 observer を所有している owner にキーを指定して購読解除ができなければならないので、 owner 自身は SynchronizedUnsubscribeType プロトコルに適合している必要があります。そういった部分も含めて StringObservable の実装を修正すると以下のようになります。

 これがマルチスレッド下で正しく動くかというと、またそれは別の話なのですが、とりあえず、シングルスレッド下で Observer パターンを実現させるための Rx の基本的なコンポーネントは出揃いました。利用側のコードを以下に示します。

 ここまできたらもう BehavoirSubjectVariable の実装を読むことができるようになっていると思います。マルチスレッド対応のためのロック処理なども完結にまとまっているので勉強になるコードです。次節ではその実装をみていきます。

BehaviorSubject, Variable の実装

BehaviorSubject

 前節では、String値を状態として持つ Observable の具象クラスを実装しましたが、これを一般化して任意の型の値を状態として持つような Observable があれば便利そうです。また、こうしたオブジェクトは通知元になりうると同時に、通知先になることもできそうです。この性質を SubjectType プロトコルにまとめます。普段は通知元として振る舞いますが、必要な時に通知先のインターフェースへの変換メソッドを呼び出せれば十分なので以下のように asObserver() を持っていれば大丈夫そうです。

 また、BehavoirSubject をスレッドセーフに実装するために NSRecursiveLock が使われています。これは lock している場合に同一スレッド以外からのアクセスを、unlock されるまで待たせることができるものです。使い方は、以下のように直感的なものです。

 スコープから抜けるときに必ず unlock が実行されるという点を強調するためなのか、RxSwift では defer を使った次のような書き方がちらほら見受けられます(とはいえ統一されているわけではない)。

 これらを踏まえた上で BehaviorSubject の実装をしていきましょう。基本的には前節で実装した StringObservable に対して、SubjectType, Disposable の実装と排他制御を追加しただけの構造になっています。

 クライアント側のコードは前節とほぼ同じ形となります。

Variable

 BehavoirSubjecton.Error.Completed を渡すことにより閉じることができてしまいますが、ただの値を Observable にしたいだけならそんな機能は要らないはずです。そこで、そういったインターフェースを隠蔽し、もっと変数ライクに扱えるようにしたのが Variable です。基本的に実装は、ただの変数ラッパー + asObservable のために保持しているBehavoirSubject ですが、不要なAPIの隠蔽と、変数として扱うのに便利な computed property を生やす役割を担っていると言ってよいと思います。

 こうして取り回しのきく Variable を作ることができました。RxSwift には他に PublishSubjectReplaySubject というような Subject (通知元にも通知先にもなりうるオブジェクト)が存在しますので、また機会があれば別の記事でご紹介したいと思います。また、ここまで記事の内容を理解しながら読み進めている方であれば、ソースコードを読みさえすれば何をしているか大体わかるのではないでしょうか。

まとめ

 歴史的経緯はともあれ、Rx の基本的なインターフェースである Observable, Observer については以下のように説明できると思います(自分は歴史的経緯は知らないので実際の流れは違うかもしれません)

  • push 型 Observer パターンが基本的な出発点
  • 値に next, error, completed という文脈をつけたものが push の対象物になっているのが特徴的
  • 購読解除の仕組みを Disposable に分離しているのが特徴的
  • 以上を踏まえると Observable, Observer といったインターフェースを自然に導き出すことができる

 また、Observable の実装クラスのうちのひとつである BehaviorSubjectVariable などについては次のようなことが言えます。

  • ある型のインスタンスを観測可能な状態(Observable)に簡単にリフトアップさせることのできる役割を持つ
  • 同時に、観測者側(Observer)にも変換できる状態にする役割を持つ
  • 中身は、単純に push 型 Observer パターンの Observable がやらなければならないことをスレッドセーフに実装しているだけ

 最後にもう一度書いておきますが、この記事の内容がわからなくても、RxSwift は使えますので、利用を迷っている方は、巷に飛び交う記事に惑わされず、是非公式の Example や Playground を真似して使ってみてください。

Appendix

ライセンス表記

RxSwiftはMITライセンスで公開されています。記事内のコードはライセンスに基づき、そのまま掲載している箇所や改変して掲載している箇所があります。

The MIT License Copyright © 2015 Krunoslav Zaher All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

class縛り

という感じで class で縛れる。structでは縛れない。

タグ付けできない休日

これを Swift で書こうとして無理だと悟って休日が終わりました。はぁ…。
はやく protocol 宣言に型変数をかけるようになってほしい。

Self = A を表現する言語機能が Swift には足りていないのが原因かなと思います。その部分を妥協するとしたら普通に Phantom Type 的な解決法として以下のような具合になるのかなぁと思います。

もちろん hogeId + 456 なんてものはできないですね…。残念。
しかも以下のようなことはできない。

ため息しかでない。

Java8 + AWS Lambda + API Gateway で遊ぶ

 この記事では Java8 で書いたメソッドを AWS Lambda に実行させ、その実行結果を API Gateway を用いて外から取得できるような簡単なアプリケーションを作成していきます。

 めっちゃ雑にいうと、Java で String を返すメソッドを書いて、その文字列を返すAPIを作るというようなことをやります。

 この際、String を返す Java のコードを実行するのが、AWS Lambda の役割で、その実行結果を取得できるエンドポイントを提供するのが API Gateway の役割になります。

 また、ちょっと手を加えるだけで簡単に JSON を返す API を作ることもできるので、使い方次第では遊べるツールになるのではないでしょうか?

固定した文字列を返すAPIを作成する

 まず、あるエンドポイントを叩くと、ただ文字列が帰ってくるだけのAPIを作成しながら、AWS LambdaAPI Gateway の使い方を確認していきます。

Gradleプロジェクト作成〜実行対象のメソッド作成

 gradleで適当にプロジェクトを作成してください。手元で実際に使った build.gradle ファイルは以下のような具合です。

 続いて、AWS Lambda で実行する対象のメソッドを作成します。めっちゃ簡単なので「馬鹿にしてんのか!」って思うかもしれませんが、まあチュートリアルですので…。

あとはプロジェクトルートから ./gradlew builde を叩いて build/libs 以下にできた jarAWS Lambda にアップロードするだけ!めっちゃ簡単じゃないですか?

AWS Lambda への jar のアップロードと実行

以下のように進めてください

1. AWSのマネジメントコンソールから Lambda を探してクリックします
2. create a lambda function ボタンをクリック
3. 適当なテンプレート一覧が出てくるが、スルーして右下の skip をクリック
4. Name を適当に埋め、Runtimejava8 を選択
5. zip をアップロードできるようになるので、さっき作った jar を選択する
6. Handlerのところにはさっき作ったメソッドを指定。上の例だと com.github.gochiusa.lambda.routes.api.v1.text.Words::get という感じで {package}.{class}::{method} という感じでしていすれば良い。残りの項目も適当に埋める。

適当にすすめると、左上に test というボタンが出てくるので押せば、晴れて AWS Lambda上 で、自分が書いた Java8 コードが実行されてくれる。だいぶ説明を端折っているので詳しくは AWS のドキュメントを見ればいいと思います。

API Gateway でエンドポイントを作る

マネジメントコンソールから API Gateway へ行き、create API をクリック

スクリーンショット 2016-02-28 0.40.49

API の名前を適当につけ先に進む

スクリーンショット 2016-02-28 0.40.57

create Method をクリックする

スクリーンショット 2016-02-28 0.44.14

以下のような感じで適当に各フィールドを埋める。ここで指定する lamda resion はさっき作った lamda function が置いてあるリージョンを指定。lambda function は作ったやつの名前を入れる。

スクリーンショット 2016-02-28 0.41.53 1

以上がおわったら Save を押して、Deploy API のほうに進めば、"ご注文はうさぎですか?" とだけ返してくれる最高なAPIが出来上がる。

JSON を返す API を作る

 JSON を返す lambda function も簡単につくれます。AWS Lambda は、POJO を返す Lamda function を実行すると JSON のレスポンスに変換してくれるみたいでめっちゃ楽しそうです。具体的にはこんなAPIがつくれます。

まずは、上記の感じ構造を持った POJO を定義しましょう。

んであとは、関数の戻り型、戻り値をこいつにしてやればOKです。

ソースコードはここにまとめて置いてあるのでまあ適当に見ていただければ…。

おわりに

 AWS Lambda で Java のコード動かしている記事があんまりなかったので書いたが、だいぶ雑なので迷ったらドキュメントか、他の優しい人が書いた記事を読むと良いと思います。AWS Lambda と API Gateway、どちらも素晴らしいサービスですね。どんどん活用していきたい…。

謝辞など…

 実はWantedly さんでやっていた Serverless Framework の勉強会に参加させていただき、この周辺のものに触れることができました。Wantedlyさん、ありがとうございます…。この記事の内容に近いもののハンズオンでしたので、AWS LambdaやAPI Gatewayに初めて触る方は、まずそちらを試して見ると良いと思います。

Swift2で静的なDIを実現する謎のソースコード

とりあえず書いたら動いたけど、なんだかよくわかっていないのでコードだけ貼っておきます。元ネタはここ。元ネタではAppContextで頑張って配線しているけど、めんどうくさいのでどうにかならんのか、と思っていろいろいじってたらこうなった。

いろいろ分かったらまとめて記事を書きます。XcodeのPlaygroundで動いたので、貼っていじってみるとよいのではないですかね。

プルリクエストを便利に取得できるアレ

ReSwiftのサンプルコードの仕組みをRxSwiftで実現する

 ReSwiftのサンプルコード程度であれば、RxSwiftの機能を使って自前で実装ができてしまうのでは、と考えたので実際にやってみました。不必要に依存ライブラリを増やしたくないという気持ちがモチベーションとなっています。まずはReSwiftのサンプルコード的なものを確認するところから始めます。

 ちなみにこの記事は ReSwift を使い始めて数時間の人間が書いているので、間違っている可能性が大いにあります。嘘を嘘と見抜きながら読んでいただけると幸いです(そして、コメント欄で刺してください)。

ReSwiftとは?

 ReduxのSwift実装らしいです。そもそもReduxがよくわからないのですが、そんなものわかってなくても動くコードはかけそうでした。ということで、とりあえずコードを書いて読んでから、小難しい記事を読んで理解してく方針にして、Redux および ReSwift の解説は他の記事に譲ります。

簡単な数字のカウントアップ・アプリケーション

 まずはReSwiftを用いてどのようにアプリケーションを構成していくか、ごくごく簡単な数字のカウントアップ・アプリケーションの例を用いてみていきましょう(ただし実際にはこんな単純すぎるアプリケーションに小難しいアーキテクチャを採用するメリットはないと思っています、あくまで例示としてのお話です)。まず CocoaPods でも Carthage でもなんでもいいので適当に ReSwift を導入してください。

 ReSwiftではアプリケーションの持つ状態をStateTypeプロトコルを持つ構造体 or クラスにまとめるようです。

 つづいて Action の宣言です。今回のアプリケーションに発生しうるアクションとして数字をカウントアップするアクションとカウントダウンするアクションを宣言してみます。

 簡単ですね?さて続いては、アクションを解釈して、新しい状態を発行する役割を持つ Reducer を実装してみましょう。状態を変化させるのではなく 新しい状態を発行する という点に注意しながらコードをみてみると良いと思います。

 そんなに難しいものではなく、action がもし、CountActionIncrese 型だったら、現在の状態のcounterをカウントアップしたものを生成して返すというだけです。Decrease も同様に考えれば同じようなものですね。

 最後に皆さんおなじみの ViewController を実装してみましょう。まずは、ストーリーボードに適当にラベルとボタンを配置してください。

スクリーンショット 2016-02-12 7.12.03

 つづいて、ViewController に label と ボタンのアクションを紐づけて、以下のようなコードを記述します。

 各アクションで文字通り Action を発行しているだけで、ラベルのテキストを書き換えたりカウンターの状態(数字)を書き換えたりしていない点が非常に重要なポイントです。アプリケーションの状態の書き換えは、Reducerで行います。そして、ビューの書き換えは newState で行います。こうすることにより、状態遷移(実際には新しいステートの発行)の記述と、ビューへの反映を分離しています。

 以上のような簡単なアプリケーションだとしても、多分コードみただけじゃ、感覚はつかめないのではないでしょうか?簡単なのでXcode起動して、ちゃちゃっと実験してみてください。5分で終わるので絶対自分の手でコードを書いてみてください。

RxSwiftを使って、上述の形式のコードを実現する

 細かいことは抜きにして、RxSwiftを使って同じ動きをエミュレートしてみましょう。まずは state, action, reducer の定義から。

 ほとんど変化はないですね?次に ViewController は次のような感じ。ちょっと記述は長くなりましたが、だいたい読み替えは可能なのではないでしょうか?

 もちろん、厳密なお話をするとおなじものにはなっていないのですが、ちゃんとプロトコルと基底となるコードをちょっと書いてあげれば、たちまち同じようなものになるのではないでしょうか?(自分の理解が間違っていたらご指摘をお願いします:ReSwiftを触ってまだ1日目です)

おわりに

 楽なので、よくやってしまいがちなのは、ViewControllerに var で状態を宣言して、イベント処理時に変化させていくという感じの実装ではないでしょうか?このサンプルレベルの簡単なアプリケーションであれば、その実装は正しいと思います。シンプルでわかりやすいので、別にそれで全然かまわないと思います。

 しかし状態の数が増えると、結果としてアプリケーションの取りうる状態の数は、各プロパティの取りうる状態の組み合わせ(高校で習った数学的なお話)になります。状態が10個程度を超えてくると、もうアプリケーションコードを読むのが辛くなってきたり、一つの変更が別の箇所に影響してしまい、意図しない動作を引き起こしてしまうなどということがあるのではないでしょうか。

 自分もまだ ReSwiftRedux がどういうものがわかっていませんが、状態の遷移とビューへの反映の混在を分離するところから、まずはじめてみようと思っています。

Swiftで同期HTTP通信を走らせる

 NSURLSession を使って通信を走らせる場合、コールバックやデリゲートなどで後処理を指定する非同期通信となります。基本的に通信処理を非同期で扱うのは正しいと思います。しかし、コールバックやデリゲート、FutureObservable などに縛られず処理を書きたいとなると、同期通信でないと困ります。

 そこで強制的に同期通信にしてしまうコードを書いてみました。これで晴れてコールバックを渡す必要も無く、デリゲートを指定する必要もない。そして FutureObservable に包む必要のない状態になりました。

 実際にUI層から呼び出す前に、適当なタイミングで Future なり Observable なりに lift すればよいので、同期である方が柔軟な設計が可能になるのではないかなと思います。execute の戻り型が、 Either<NSError, HttpResponse> とかになっているとさらに良さそうですね。

 純粋な HttpClientFutureObservable に依存する必然性がないので、このコードが安定したものであれば、使っていきたいと考えています。iOS開発に詳しい方、このコード実際どうなんですかね?(丸投げ)