ReSwift とは

ReSwift とは、iOS アプリを Redux のように作れるようにしてくれるライブラリです。

スマホアプリを作っていると

• アプリの状態管理を一元管理したい
• アプリの状態が変わったら、UI を最新に更新したい

という要求が出てくると思います。そんなときに、ReSwift でステートを一元管理し、UI の更新を RxSwift の I/F に合わせて使えると結構便利です。

ソースコード

ということで、メモ書きなので、さっとソースを貼り付けておきます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

/// アプリの `Store` クラス
/// Rx 拡張を行うために独自クラスを作成する
class AppStore : Store<AppState> {

    required convenience init(reducer: @escaping (Action, AppState?) -> AppState, state: State?) {
        self.init(reducer: reducer, state: state, middleware: [])
    }

}

/// AppStore を Rx 化するためのプロキシ
class AppStoreProxy<SelectedState> : StoreSubscriber {

    typealias StoreSubscriberStateType = SelectedState

    private weak var source: AppStore?
    private(set) var subject = PublishSubject<StoreSubscriberStateType>()

    fileprivate init(source: AppStore) {
        self.source = source
    }

    func newState(state: StoreSubscriberStateType) {
        subject.on(.next(state))
    }

    deinit {
        subject.on(.completed)
    }
}


extension AppStore : ReactiveCompatible {
}


extension Reactive where Base: AppStore {

    func state() -> Observable<AppStore.State> {
        return state { $0 }
    }

    func state<SelectedState: StateType>(selector: @escaping ((AppStore.State) -> SelectedState)) -> Observable<SelectedState> {
        return Observable.create { observer in
            let proxy = AppStoreProxy<SelectedState>(source: self.base)
            _ = proxy.subject.bind(to: observer)

            self.base.subscribe(proxy, transform: { (subscriber: Subscription<AppState>) -> Subscription<SelectedState> in
                subscriber.select(selector)
            })

            return Disposables.create {
                self.base.unsubscribe(proxy)
            }
        }
    }

    func state<SelectedState: StateType & Identifiable>(selector: @escaping ((AppStore.State) -> SelectedState)) -> Observable<SelectedState> {
        return Observable.create { observer in
            let proxy = AppStoreProxy<SelectedState>(source: self.base)
            _ = proxy.subject.bind(to: observer)

            self.base.subscribe(proxy, transform: { (subscriber: Subscription<AppState>) -> Subscription<SelectedState> in
                subscriber.select(selector)
            })

            return Disposables.create {
                self.base.unsubscribe(proxy)
            }
        }
    }
}

これで、ReSwift の State を次のように書くことができます。

1
2
3
4

store.rx.state { $0.userState }
  .map { $0.name }
  .bind(to: nameLabel.rx.text)
  .disposed(by: disposeBag)

オブザーブしているステートが更新されたときのみ通知して欲しい時

ReSwift を RxSwift のように使うだけであれば、上の拡張でいいのですが、たくさんステートが出来てくると、 関係ないステートが更新されたときにも変更が通知されてしまって、パフォーマンスを気にすることが出てくるかもしれません。

そんなときは、distinctUntilChanged を使って、監視しているステートが更新されたかどうかを確認するようにするといいと思います。

State 自体を == で比較できるように、State に Identifier を導入して、更新されたかどうかをチェック出来るようにしてみます。 (というのも、State は構造体(struct) で作ることになると思うので、同一のステートかどうかの一致が大変なのです。)

State に一意性を持たせる

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

/// 識別子コンポーネント
struct IdentifiableComponent : Hashable {

    typealias Identifier = UInt64

    /// インスタンス生成毎に一意になる値を生成するクラス
    private struct Counter {
        static let lock = DispatchSemaphore(value: 1)
        static var count: Identifier = 0
        static func getAndIncrement() -> Identifier {
            lock.wait()
            defer { lock.signal() }
            count += 1
            return count
        }
    }

    /// インスタンスの識別子
    private(set) var identifier: Identifier = Counter.getAndIncrement()

    var hashValue: Int { return identifier.hashValue }

    mutating func update() {
        identifier = Counter.getAndIncrement()
    }

    static func ==(lhs: IdentifiableComponent, rhs: IdentifiableComponent) -> Bool {
        return lhs.identifier == rhs.identifier
    }
}

protocol HasIdentifiableComponent : Equatable {
    var identifiableComponent: IdentifiableComponent { get }
}

/// 識別子を持つタイプ
protocol Identifiable : HasIdentifiableComponent {
}

extension Identifiable {

    var identifier: IdentifiableComponent.Identifier {
        return identifiableComponent.identifier
    }

    static func ==(lhs: Self, rhs: Self) -> Bool {
        return lhs.identifiableComponent == rhs.identifiableComponent
    }
}

複雑そうなことをやっていますが、要はインスタンスを生成するたびに一意の数値を割り当てて、 状態が更新されたらその値をインクリメントするという方法で、数値比較だけで状態が変わったかを判断できるようにしています。

この識別子コンポーネントを State に持たせるようにして

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

struct UserState : StateType, Identifiable {

  fileprivate(set) var identifiableComponent = IdentifiableComponent()

  var name: String?
}

// MARK: - Reducer
extension UserState {
    static func reducer(state: UserState?, action: Action) -> UserState {
        var state = state ?? UserState()

        switch action {
        case let action as UserActions.SetName:
            state.name = action.name
            state.identifiableComponent.update()

        default:
            break
        }

        return state
    }

こんな感じで、ステートが更新したときに、identifiableComponent.update() を呼び出すと状態が更新されたことをマークします。 これで、ステートが更新されたときだけ UI を更新するようなコードを次のように書けるようになります。

1
2
3
4
5

store.rx.state { $0.userState }
  .distinctUntilChanged()
  .map { $0.name }
  .bind(to: nameLabel.rx.text)
  .disposed(by: disposeBag)

パフォーマンスも気にせず使えるようになりました。

既存のプロジェクトからの抜粋なので、一部省略している箇所があります。

目次

• Part I　イントロダクション
  • 第1章　アーキテクチャ、実行速度、ゲーム
• Part Ⅱ　デザインパターン再訪
  • 第2章　コマンド
  • 第3章　フライウェイト
  • 第4章　オブザーバ
  • 第5章　プロトタイプ
  • 第6章　シングルトン
  • 第7章　ステート
• Part Ⅲ　シーケンスのパターン
  • 第8章　ダブルバッファ
  • 第9章　ゲームループ
  • 第10章　更新メソッド
• Part IV　ビヘイビアのパターン
  • 第11章　バイトコード
  • 第12章　サブクラスサンドボックス
  • 第13章　型オブジェクト
• Part V　分離のパターン
  • 第14章　コンポーネント
  • 第15章　イベントキュー
  • 第16章　サービスロケータ
• Part VI　最適化のパターン
  • 第17章　データ局所化
  • 第18章　ダーティフラグ
  • 第19章　オブジェクトプール
  • 第20章　空間分割

目次

• 第1部 基盤
  • 第1章 イントロダクション
  • 第2章 仕事用ツール
  • 第3章 ゲームのためのソフトウェアエンジニアリングの基本
  • 第4章 ゲームのための3D計算
• 第2部 低レベルエンジンシステム
  • 第5章 エンジンサポートシステム
  • 第6章 リソースとファイルシステム
  • 第7章 ゲームループとリアルタイムシミュレーション
  • 第8章 ヒューマンインターフェイスデバイス（HID）
  • 第9章 デバッグおよび開発のツール
• 第3部 グラフィックス、モーション、サウンド
  • 第10章 レンダリングエンジン
  • 第11章 アニメーションシステム
  • 第12章 コリジョンと剛体力学
  • 第13章 オーディオ
• 第4部 ゲームプレイ
  • 第14章 ゲームプレイシステムの概要
  • 第15章 ランタイムのゲームプレイ基本システム
• 第5部 まとめ
  • 第16章 まだやることがあるってこと？

目次

• Chapter1 建造物からレベルデザインを学ぶ準備
  • これから見ていく準備段階として、建築史の概要を学びます。
• Chapter2 レベルデザインのツールとテクニック
  • 空間の設計に便利な意匠図や視覚化の方法を説明します。
• Chapter3 基本的な空間配置とゲーム空間の種類
  • ゲーム空間を分析して、設計に使用できるタイプを特定します。
• Chapter4 ビジュアル要素によるチュートリアル
  • プレイヤーにゲームのメカニクスを教える方法を紹介します。
• Chapter5 生存本能を利用したレベルデザイン
  • 感情を動かし、プレイヤーを促すテクニックを取り上げます。
• Chapter6 報酬の空間でプレイヤーを誘い込む
  • 心理学を利用し、プレイヤーに報酬を与える方法を説明します。
• Chapter7 ゲーム空間におけるストーリーテリング
  • ストーリーを語り、円滑に進める空間構築の方法を探求します。
• Chapter8 インタラクティブ空間とワールドデザイン
  • 空間を概観し、庭園デザインの手法を活かす方法を紹介します。
• Chapter9 プレイヤーの交流を生み出すレベルデザイン
  • プレイヤーの交流を促す方法を、都市デザインに学びます。
• Chapter10 サウンドによるレベルデザインの強化
  • リズムの効果を知り、空間効果を増幅させる方法を見ていきます。
• Chapter11 現実世界を舞台にしたレベルデザイン
  • 都市や屋外空間でプレイするゲームに、空間原理を応用します。

目次

• 第1章 ゲーム開発者に欠かせないUI/UXの基礎知識
  • 「ユーザー体験の創造」と「ナビゲーションの最適化」
  • 各デバイス/プラットフォームの特性を押さえる
  • スマートデバイスゲームにおけるUI/UX設計のヒントを探る
  • コンソールゲームにおけるUI/UX設計のヒントを探る
  • アーケードゲームにおけるUI/UX設計のヒントを探る
• 第2章 スマートデバイスゲームのUI/UX
  • 白猫プロジェクト(コロプラ)
  • にゃんこ大戦争(PONOS)
  • ぼくらの甲子園! ポケット(面白法人カヤック)
  • モンスターストライク(ミクシィ)
• 第3章 コンソールゲームのUI/UX
  • ファイナルファンタジーXIV: 新生エオルゼア(スクウェア・エニックス)
  • D4: Dark Dreams Don’t Die(アクセスゲームズ)
  • フェアルーン(フライハイワークス/スキップモア)
• 第4章 アーケードゲームのUI/UX
  • 戦国大戦(セガ・インタラクティブ)
  • ガンスリンガー ストラトス2(スクウェア・エニックス/バイキング)
• 第5章 UI/UXの歴史を紐解き、これからの技術動向を考える
  • ゲームUI/UXのこれまでとAIが拓く未来
  • ゲームの世界に欠かせない3D立体視の基礎
  • VRが生み出す新しいゲームUI/UXの世界

目次

• まえがき
• はじめに
• 本書について
• I部　SPAの紹介
• 1章　最初のシングルページアプリケーション
  • 1.1　定義、簡単な歴史、重点事項
  • 1.2　最初の SPAを構築する
  • 1.3　適切に記述されたSPAのユーザメリット
  • 1.4　まとめ
• 2章　JavaScriptのおさらい
  • 2.1　変数スコープ
  • 2.2　変数の巻き上げ
  • 2.3　高度な変数の巻き上げと実行コンテキストオブジェクト
  • 2.4　スコープチェーン
  • 2.5　JavaScriptオブジェクトとプロトタイプチェーン
  • 2.6　関数 .詳しく調べる
  • 2.7　まとめ
• II部　SPAクライアント
• 3章　シェルの開発
  • 3.1　シェルを完全に把握する
  • 3.2　ファイルと名前空間を用意する
  • 3.3　機能コンテナを作成する
  • 3.4　機能コンテナをレンダリングする
  • 3.5　機能コンテナを管理する
  • 3.6　アプリケーション状態を管理する
  • 3.7　まとめ
• 4章　機能モジュールの追加
  • 4.1　機能モジュール方式
  • 4.2　機能モジュールファイルを用意する
  • 4.3　メソッド APIを設計する
  • 4.4　機能 APIを実装する
  • 4.5　頻繁に必要となるメソッドを追加する
  • 4.6　まとめ
• 5章　モデルの構築
  • 5.1　モデルを理解する
  • 5.2　モデルとその他のファイルを用意する
  • 5.3　peopleオブジェクトを設計する
  • 5.4　peopleオブジェクトを構築する
  • 5.5　シェルでサインインとサインアウトを可能にする
  • 5.6　まとめ
• 6章　モデルとデータモジュールの完成
  • 6.1　chatオブジェクトを設計する
  • 6.2　chatオブジェクトを構築する
  • 6.3　モデルにアバターサポートを追加する
  • 6.4　チャット機能モジュールを完成させる
  • 6.5　アバター機能モジュールを作成する
  • 6.6　データバインディングと jQuery
  • 6.7　データモジュールを作成する
  • 6.8　まとめ
• III部　SPAサーバ
• 7章　 Webサーバ
  • 7.1　サーバの役割
  • 7.2　Node.js
  • 7.3　高度なルーティング
  • 7.4　認証と認可を追加する
  • 7.5　WebSocketとSocket.IO
  • 7.6　まとめ
• 8章　サーバデータベース
  • 8.1　データベースの役割
  • 8.2　MongoDBとは
  • 8.3　MongoDBドライバを使う
  • 8.4　クライアントデータを検証する
  • 8.5　個別の CRUDモジュールを作成する
  • 8.6　チャットモジュールを構築する
  • 8.7　まとめ
• 9章　 SPAを本番環境に備える
  • 9.1　SPAを検索エンジンに対して最適化する
  • 9.2　クラウドサービスとサードパーティサービス
  • 9.3　キャッシングとキャッシュバスティング
  • 9.4　まとめ
• 付録A　JavaScriptコーディング標準
  • A.1　なぜコーディング標準が必要なのか
  • A.2　コードレイアウトとコメント
  • A.3　変数名
  • A.4　変数の宣言と割り当て
  • A.5　関数
  • A.6　名前空間
  • A.7　ファイル名とレイアウト
  • A.8　構文
  • A.9　コードを検証する
  • A.10　モジュール用のテンプレート
  • A.11　まとめ
• 付録B　SPAのテスト
  • B.1　テストモードを準備する
  • B.2　テストフレームワークを選ぶ
  • B.3　nodeunitを準備する
  • B.4　テストスイートを作成する
  • B.5　テストに合わせて SPAモジュールを調整する
  • B.6　まとめ
• 索引

細かいニュアンスは間違っているかも。。

基本用語の整理です。

Reactive Extensions

大雑把に言うと、Observer Pattern (オブザーバパターン) と Stream/Sequence Programming を合わせたものが Reactive Extensions です。

Observable

オブザーバパターンにおいて、観測される対象を Subject と呼びますが、Rx では観測される対象のことを Observable と呼びます。観測する側は Observer (オブザーバ） なので、観測される側は Observable なわけです。

Rx では、Observable なものを subscribe (購読) することで、Observable から送られてくるデータを受け取ります。この、Observable からデータが流れてくることを Stream (ストリーム) と呼びます。流れてくるデータは Element と呼ばれます。

1
2
3
4
5
6
7
8

someObservable
    .subscribe { (e: Event<Element>) in
        switch e {
        case .Next(let val):
        case .Error(let error):
        case .Completed:
        }
    .scopedDispose()

ストリームには状態が3種類あり、それぞれ Next、Error、Completed になります。

Next

ストリームから次のデータが流れてきたことを表します。正常処理と考えて構いません。

Error

Observable な対象が何かしらエラーを起こし、観測したかったデータが流れてこなかったことを表します。Rx では、Error を起こしたストリームは閉じられます。つまり、次のデータが流れてこないことを表します。

Completed

Observable な対象のストリームが閉じられ、この Observable な対象からは今後データが流れてこないことを表します。

dispose

観測を取りやめたい時には、dispose を呼び出します。いつ dispose するかを使い分けられるように、Dispose の実装がいろいろあります。

Subject

Observable は観測対象のことでしたが、Rx においては観測可能な事柄のことを Subject (事象) と呼ぶほうが一般的だったりします。Subject を観測するわけですが、観測するデータのことは Behavior (振る舞い) と呼ばれます。Subject / Behavior は Reactive Extensions における一般的な説明となりますが、こと Rx Programming においては、Observable と Subject、Element と Behavior は似て非なるものとして扱われています。

Hot and Cold Observables

Observable な対象は、2つの種類にわけられます。Hot と Cold です。

Hot Observable

Hot な Observable とは、観測対象である Observable が作られたときから、任意のタイミングでデータを送信することができるものになります。

実はこの Hot Observable のことを、Rx Programming では Subject と呼ばれています。Subject は任意のタイミングでデータをストリームに流すことができ、同時に Observable なわけです。

Subject は任意のタイミングで Behavior (振る舞い) を決められることから、Subject / Behavior はセットで使われる言葉になります。

1
2
3
4
5
6

let msg = PublishSubject<String>()

msg.subscribeNext { print($0) }

msg.onNext("Hello World")
msg.onCompleted()

Cold Observable

Cold な Obserable は、任意のタイミングでデータを流すことができません。いつデータが流れてくるのかわかりませんし、観測対象がいなければ、そもそも振る舞いが起きることもありません。

よく、API 通信を Observable にしますが、subscribe (観測) を忘れると、API 呼び出しがされないことになりますので注意が必要です。

1
2
3
4

API.call()
    .subscribeNext {
        // When to occur?
    }

Rx でプログラミングすると何が嬉しいか

テスタビリティが向上

Rx は UI プログラミングで語られることが多いと思いますが、プログラムのあらゆる境界を Observable でつなぐことで、テスタビリティが向上します。

Observable でつなぐことにより、直接のデータの生成元に依存せずにプログラムを記述することができるようになるので、テスト時だけデータ生成部分をいじることで、例えば API 通信結果を画面に表示するようなプログラムでも、API 通信を行うことなくデータを生成し、Stream に流すことで色々な依存関係を排除することが出来るのです。

1
2
3
4
5
6
7
8
9
10
11

func something(dataSource: Observable<DataSource>) {
    dataSource.
        subscribeNext {
            // do something
        }
}

// development
something(API.call())
// test
something(just(DummyDataSource()))

非同期処理

また、Rx には Stream の観測を任意のスレッドで行うスケジューリングの機能が備わっているものがほとんどですので、時間の掛かるデータ生成処理はバックグラウンドで行い、UI の表示処理のところだけメインスレッドで行うといったことを容易に行なえます。

1
2
3
4
5
6
7
8

API.call()
    .map { $0.toViewModel() }
    .subscribeOn(BackgroundScheduler.sharedInstance)
    .observeOn(MainScheduler.sharedInstance)
    .subscribeNext { (viewModel) in
        // UI バインディング
    }
    .addDisposeBag(disposeBag)

データソースの更新をリアルタイムに同期

プログラムを書いていると、データソースの値を加工して別のところで使うという場面が多々あります。

このとき、何も考えずにプログラムすると、データソースが変更されても結果は変わらないという挙動になります。

1
2
3
4
5
6
7
8
9
10
11

var a = 1
var b = 2
var c = ""

if a + b >= 0 {
    c = "\(a + b) is positive"
}

a = 4

print(c)        // ""

こういった挙動でかまわないという場合もあるでしょうが、ほとんどの場合データソースの変化に合わせて挙動が変わってくれたほうが嬉しかったりします。そんな時は全部 Observable にします。

1
2
3
4
5
6
7
8
9
10
11
12

let a = Variable(1)
let b = Variable(2)

let c = combineLatest(a, b) { $0 + $1 }
            .filter { $0 >= 0 }
            .map { \($0) is positive" }            

c.subscribeNext {
    print($0)
}

a.value = 4

Operators

Rx には、Stream を操作するためのいろいろな演算が用意されています。Stream を別の形に変換する map や、複数の Stream を結合する merge や concat がなどがあります。

Stream の合成は使いドコロとしては API 通信などの時間の掛かる処理とキャッシュデータを返すストリームとを合成するなどが考えられます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

sequenceOf(1, 2, 3, 4, 5)
    .map { $0 * $0 }
    .subscribeNext {
        print($0)
    }
    .scopedDispose()


let dataFromCache = CacheStore.fromCache()
dataFromCache.concat(API.call())
    .subscribeNext {
    }
    .addDisposeBag(disposeBag)
// もしくは
API.call()
  .startWith(dataFromCache)
  .subscribeNext {
  }
  .addDisposeBag(disposeBag)

[参考] iBeacon(3) - リージョン監視とレンジング - Enamel Systems

そこで、1秒間隔だと通知間隔が短すぎるので、5秒間隔とか1分間隔とかに変えたい時にどうするかですが、CLLocationManager クラスに設定があればよかったのですが、特になさそうなので、RxSwift を使ってストリームのフィルタで対応する方法のメモです。

CLLocationManager の初期設定とかは参考サイトを見てください。

ReactiveX/RxSwift

1
2
3
4
5
6

locationManager.rx_didRangeBeaconsInRegion
    .sample(interval(5, MainScheduler.sharedInstance))
    .subscribeNext { (tuple: ([CLBeacon]!, CLBeaconRegion!)) in
        debugPrint("beacons: \(tuple.0), region: \(tuple.1)")
    }
    .addDisposableTo(disposeBag)

Rx の sample を使って、ストリームを interval 毎にサンプリングしてやるだけです。

Time-shifted sequences - Introduction to Rx

RxSwift も使いやすくて、めっちゃ便利です！

いつも Signal を自分で制御するイディオムを忘れてしまうので、メモ書きです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import Foundation
import UIKit
import ReactiveCocoa

class MyViewModel {
    let (changed, sink) = Signal<Void, NoError>.pipe()

    func doAction() {
        // do something
        sendNext(sink, ())
    }
}


class MyViewController : UIViewController {
    let viewModel = MyViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()

        viewModel.changed |> observe(next: debugPrintln)

        viewModel.doAction()
    }
}

ankurp/Dollar.swift という JavaScript の Lo-Dash や Underscore と同じ感じでコレクションを扱うためのライブラリがありますが、 each が配列しか受け付けることが出来ないので、SequenceType を受け取れるように拡張する方法のメモです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import Dollar

extension $ {
    class func each<T: SequenceType>(array: T, callback: (T.Generator.Element) -> ()) -> T {
        for elem in array {
            callback(elem)
        }
        return array
    }
}

$.each(["a", "b", "c"]) { (s: String) in println(s) }
$.each(["key": "val"]) { (e: (String, String)) in println("\(e.0) = \(e.1)") }
// a
// b
// c
// key = val

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

extension Array {
    func each(block: (T) -> ()) {
        for item in self {
            block(item)
        }
    }

    func each<U>(block: (U) -> ()) {
        for item in self {
            block(item as! U)
        }
    }

    func eachWithIndex(block: (T, Int) -> ()) {
        for (i, item) in enumerate(self) {
            block(item, i)
        }
    }

    func eachWithIndex<U>(block: (U, Int) -> ()) {
        for (i, item) in enumerate(self) {
            block(item as! U, i)
        }
    }
}

使い方はこんな感じ。

1
2
3
4

[1, 2, 3].each { (n: Int) in println(n) }
[1, 2, 3].each { println($0) }
[1, 2, 3].eachWithIndex { (n: Int, i: Int) in println("index \(i), n \(n)") }
[1, 2, 3].eachWithIndex { println("index \($1), n \($0)") }

配列の中身が AnyObject だった時に、型指定するときとしない時でどっちも動くようにするのに、メソッドを2つ定義しました。

このへん、Generics の達人のかたに、もっといい書き方あるよって教えて欲しいです。

Swift の Dictionary に map を実装してみた。

ついでに reduce も。

1
2
3
4
5
6
7
8
9

extension Dictionary {
    func map<T>(transform: (Key, Value) -> T) -> [T] {
        return Swift.map(self, transform)
    }

    func reduce<T>(initial: T, combine: (T, (Key, Value)) -> T) -> T {
        return Swift.reduce(self, initial, combine)
    }
}

使い方はこんな感じ。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var dict = [String: String]()
dict["hello"] = "world"

let array = dict.map { (k: String, v: String) -> String in
    return v
}
println(array)      // ["world"]


dict = [String: Int]()
dict["a"] = 1
dict["b"] = 2
dict["c"] = 3
dict["d"] = 4
dict["e"] = 5
let n = dict.reduce(0) { (n, d) -> Int in n + d.1 }    // 15

Ruby の map っぽい感じで使えるにしたかったので。

定義や概念などは、語るコンテキストで捉え方が違ったり、論争の元になるので、今回はあえてこういう定義付けをさけ、実践で利用する場合にどういうメリットがあるのか、どういうふうに使えばいいのかに焦点を当てました。

一部、寝ぼけていたのかおかしな部分があったりもしますが（React.js が Flux アーキテクチャに則っているとか変なこと書いてます。。。）、今号はいろいろおもしろい話が満載ですので、是非読んでみてください。

こんにちは。iOS8 から SeparatorInsets をゼロにする方法が変わりました。今までの UITableView の separatorInset に UIEdgeInsetsZero を入れるだけだと、iOS7 では効きますが、iOS8 では効かなくなりました。

1

tableView.separatorInset = UIEdgeInsetsZero

iOS8 にも対応するには

iOS8 からは UIView に追加された layoutMargins というプロパティにも UIEdgeInsetsZero をセットする必要があります。ただこのプロパティ、iOS8 以降でしか利用できないプロパティなので、分岐が必要になります。。

1
2

tableView.layoutMargins = UIEdgeInsetsZero
cell.layoutMargins = UIEdgeInsetsZero

全体に適用する簡単な例

全体に適用するには UIAppearance を使うと便利です。iOS7 と iOS8 に対応したコードは次のように書けます。

1
2
3
4
5
6
7
8

let version = NSString(string: UIDevice.currentDevice().systemVersion).doubleValue

UITableView.appearance().separatorInset = UIEdgeInsetsZero
UITableViewCell.appearance().separatorInset = UIEdgeInsetsZero
if version >= 8 {
    UITableView.appearance().layoutMargins = UIEdgeInsetsZero
    UITableViewCell.appearance().layoutMargins = UIEdgeInsetsZero
}

僕も iPhone アプリを開発しているのでこのあたりは結構気を使ってはいるんですが、いかんせん自分のやり方がほんとに正しいのか、やや疑問なところもあります。 そこで、今の自分のやり方を晒して、世の iPhone アプリ開発者の人に突っ込んでもらえればと思い記事を書くことにしました。

間違っている箇所もあると思いますので、ドンドンツッコミをお願いします！

この記事で何が出来るようになりたいか

このまとめ記事で、何が出来るようになりたいか。それは次の2点です。

1. UITableViewCell （可変長高さ）を Auto Layout を使ってキレイにつくりたい
2. UIScrollView （可変コンテンツ）を Auto Layout を使ってキレイにつくりたい

こんな感じのやつです。

UILabel の中身によって UITableViewCell の高さが変わるやつと、UIScrollView の中身をページングで切り替えるときに中身の個数を動的に差し替えるやつです。

それぞれ作り方をさらします。

ソースコードは

hamasyou/autolayout

にあるので、参考にしたい方はどうぞ。

iOS8 以降だけに対応するのであれば

ちなみに、iOS8 以降だけに対応するのであれば、TableViewCell.xib で ContentView に対して何も考えずに Auto Layout でレイアウトして、TableViewController を継承したクラスで次のように tableView.rowHeight に UITableViewAutomaticDimension を設定し、tableView:estimatedHeightForRowAtIndexPath: で UITableViewAutomaticDimension を返すようにするだけで解決します。

1
2
3
4
5
6
7
8
9
10
11
12

class MyViewClass : UIViewController, UITableViewDelegate {
    @IBOutlet weak var tableView: UITableView!

    override func viewDidLoad() {
        super.viewDidLoad()
        tableView.rowHeight = UITableViewAutomaticDimension
    }

    func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
        return UITableViewAutomaticDimension
    }
}

tableView に estimatedRowHeight というプロパティがありますが、これに UITableViewAutomaticDimension を設定して、tableView:estimatedHeightForRowAtIndexPath: を実装しない方法だと上手くいきません。バグなんじゃないか？？。。。

Auto Layout のおさらい

作り方を晒す前に、まずは Auto Layout のおさらいをしておきます。

Auto Layout は Storyboard やプログラムから「制約」を利用してレイアウトを組み立てるものです。基本的に Auto Layout に対応したアプリでは、 UIView(frame: CGRectMake(xx, xx, xx, xx)) みたいな作成方法はしなくなります。

Auto Layout を使うと、”画面のこのコンポーネントから◯pxずらしてこのコンポーネントを配置する” や “このコンポーネントとこのコンポーネントのサイズを同じにする” みたいなことをなんとなく直感的に記述（または、設定）できます。

Auto Layout を Strobyboard 上で設定すると、その制約が実際にコンポーネントに反映されるのは、UIViewController#viewDidLayoutSubviews のタイミングになるようです。

UITableViewCell での Auto Layout の作用

UITableViewCell で Auto Layout を使うときに注意しなければならないのは、awakeFromNib のタイミングでは、セルの Auto Layout が設定されていないということです。

まぁ、これは当然といえば当然で、カスタムの UITableViewCell は再利用を前提に作られるので、実際にセルのコンテンツが設定されるは UITableViewDataSource#cellForRowAtIndexPath の段階になるからです。 このメソッドの中でセルのコンテンツを設定するわけです。

セルの高さが問い合わせられるのはセルのコンテンツを設定する前！！

で、まぁ普通に UITableView を使っているとドハマリするのが、セルの高さを返す UITableViewDelegate#heightForRowAtIndexPath のメソッドが呼び出されるのが、cellForRowAtIndexPath の前ということです。 セルの高さを計算できるのはセルのコンテンツが設定された後なんじゃないの？って思うわけですが、高さの問い合わせが来るのはセルのコンテンツを設定する前なのです。。

じゃあ、どうするかというと、僕はもう割りきって、heightForRowAtIndexPath の中で cellForRowAtIndexPath を呼び出して、セルにコンテンツを設定した後にセルの高さを計算するようにしています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

    // MARK: - UITableViewDataSource

    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 2
    }

    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("customCell") as CustomTableViewCell

        switch indexPath.row {
        case 0:
            cell.thumbView.image = UIImage(named: "Image1")
            cell.labelView.text  = "いろはにほへとちりぬるをわかよたれそつねならむうゐのおくやまけふこえてあさきゆめみしゑひもせす色はにほへど散りぬるを我が世たれぞ常ならむ有為の奥山今日越えて浅き夢見じ酔ひもせず"
        case 1:
            cell.thumbView.image = UIImage(named: "Image2")
            cell.labelView.text  = "Cozy lummox gives smart squid who asks for job pen."
        default:
            break
        }
        return cell
    }

    // MARK: UITableViewDelegate

    func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
        let cell = self.tableView(tableView, cellForRowAtIndexPath: indexPath) as CustomTableViewCell
        var newBounds = cell.bounds
        newBounds.size.width = tableView.bounds.width
        cell.bounds = newBounds

        cell.setNeedsLayout()
        cell.layoutIfNeeded()
        return cell.preferredView.bounds.height
    }

    func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
        return UITableViewAutomaticDimension
    }

高さを計算するときに、cellForRowAtIndexPath を呼び出してセルにコンテンツを設定した後、セルの width にテーブルビューの width を設定してあげて、一度 cell のレイアウトを更新します。

セルの width にテーブルビューの width を設定しているのがミソ です。

Storyboard 上ではカスタムセルの横幅がデフォルトで320pxで作成されるので、iPhone5S まではセルの横幅を気にしなくてもセルの layoutIfNeeded だけを呼び出せば勝手に中のコンテンツの高さ決まっているように錯覚していたのですが、 実は Storyboard 上で320pxでセルが作られているのでたまたま偶然いままではうまくいっていただけっぽいです。

本来は、セルの横幅が決まった上でセルのコンテンツの Auto Layout にしたがって layoutIfNeeded しないと行けないのです。セルの横幅を設定せずに layoutIfNeeded だけでコンテンツの高さに合わせてセルの高さを決めていると、 iPhone6 Plus になったときにセルの高さがおかしくなってしまいます。

heightForRowAtIndexPath と estimatedHeightForRowAtIndexPath の違い

セルの高さを計算するメソッドは heightForRowAtIndexPath ですが estimatedHeightForRowAtIndexPath というメソッドも用意されています。 このメソッドは何なのかというと、UITableView は大量のデータを表示する場合でも、表示領域+αの部分だけしかセルをインスタンス化しないという設計になっています。 ですので、cellForRowAtIndexPath は表示領域+αの部分分だけ呼び出されるのですが、セルの高さの計算メソッドは、そうではありません。

スクロールバーの範囲を計算したり色々するために、セルの高さの計算は、データがどれだけ大量にあっても全ての数分呼び出されてしまうのです。

で、heightForRowAtIndexPath と estimatedHeightForRowAtIndexPath の違いですが、estimatedHeightForRowAtIndexPath はセルの大まかなサイズを返すメソッドとして用意されています。

heightForRowAtIndexPath と estimatedHeightForRowAtIndexPath が両方用意されている場合は、全てのセルの高さを一旦 estimatedHeightForRowAtIndexPath で計算したあと、 表示領域+α分の回数だけ heightForRowAtIndexPath が呼び出されるという形になります。

estimatedHeightForRowAtIndexPath を定義しない場合は、全てのデータ分だけ heightForRowAtIndexPath が呼び出されるので、データが多い場合は結構きつくなります。 なので、忘れずに estimatedHeightForRowAtIndexPath も定義しておきます。

返す値はなんとなくの定数(44pxとか)でもいいですし、UITableViewAutomaticDimension を返すでもどちらでもよさそうです。

setNeedsLayout と layoutIfNeeded は何？

setNeedsLayout はそのコンポーネントに、再レイアウトが必要なフラグを設定するメソッドになります。再レイアウトが必要なコンポネントは次のタイミングの layoutSubviews の呼び出しの時に再レイアウトされます。

layoutIfNeeded はそのコンポーネントが再レイアウトが必要なフラグが立っているかを確認して、再レイアウトが必要であれば layoutSubviews を呼び出してくれるメソッドです。

コンポーネントのレイアウトを強制的に更新したい場合は

1
2

view.setNeedsLayout()
view.layoutIfNeeded()

のコンボでレイアウトを更新します。この処理を行うと、Auto Layout にしたがってレイアウトが設定されます。

レイアウトを更新したらセルの高さが決まっているはずなので bounds.height を返します。

preferredView って何？

UIView 関連のコンポーネントには、推奨サイズというのが設定されているコンポーネントがあります。例えば UILabel であれば、ラベルの文字数をきっちり表示できるサイズが推奨サイズになりますし、 UIButton であればボタン名が表示できるサイズが推奨サイズになります。

コンポーネントの推奨サイズを取得するメソッドが UIView#intrinsicContentSize になります。実はこのメソッド、Auto Layout と深い関係があります。

例えば、UILabel の制約を次のように設定したとします。

親のコンポーネントに対して、Top、Trailing、Leading を 0 に設定しています。こうすることで UILabel が親のコンポーネントの上左右の padding が 0 で表示されるわけです。

ここでのポイントは、bottom に制約を設定していないことです。bottom に制約を設定していないので、本来であればこのコンポーネントは高さが決まらずに ambiguity（曖昧）な状態なはずです。

でも UILabel や UIButton は ambiguity にはなりません。これは、コンポーネントに推奨サイズが設定されているので、そのサイズでコンポーネントが表示されるからです。

UILabel を使って、テキストがどれだけ多くなっても全て表示したいというときには、このように bottom に制約を設定せずに、Lines を 0 に、Line Breaks を Character Wrap に設定します。

推奨サイズを持たないコンポーネントがある

コンポーネントの中には、推奨サイズを持たないコンポーネントが存在します。UIView がそうです。UIView は子のビューのサイズによって自身のサイズが変わるため、 推奨サイズを持ちません。

逆に考えると、中のコンテンツのサイズが動的に変わる場合でも、UIView が親にいる限り、子のコンポーネントは好きにサイズが変わってよく、子のサイズが決まった段階で UIView のサイズ（bounds）が決まるということです。

この性質を使うと、UITableViewCell の中身が複雑に Auto Layout される場合でも、セルの高さを簡単に計算できるようになります。

セルの中に UIView を配置して、その中にコンテンツを並べる

カスタムの UITableViewCell には、ContentView という UIView が予め用意されていますが、この ContentView 、いまいち上手く Auto Layout してくれません。。 やり方が悪いだけのような気もしますが、僕は ContentView の子に UIView を入れるようにして、この UIView の上左右の padding を 0 に設定してレイアウトを始めるようにしています。

bottom の制約を設定しないのがミソです。bottom の制約を設定しないことで、UIView は縦方向に自由に伸び縮みして、子のコンポーネントのサイズに合わせて高さが勝手に変わるようになります。

最後のコンポーネントを配置し終えたら、そのコンポーネントの bottom を親に対して設定をすれば、UIView の高さが子のコンポーネントの Auto Layout から決まるようになります。

推奨サイズをもつコンポーネントで位置とサイズで矛盾が起きた場合

上の画像では、最後の要素の UILabel の bottom を親の Preferred View に対して設定していますが、UILabel の推奨サイズの高さと Preferred View からの bottom の位置とでコンフリクトが起きます。

Storyboard 上では、コンフリクトが起きると、赤い矢印マークがでます。実際には UILabel の高さを bottom の位置にまでの高さに設定することで矛盾は起きないのですが、 コレだと、高さが結局 UIView の高さに依存してしまい、UIView の高さは bottom を設定していないことから曖昧なサイズになってしまいます。

これだと思った様なレイアウトになりません。で、こんな時に設定するのが制約の priority です。制約同士でコンフリクトが起きた場合に、どちらの制約を優先的に適用するかを決めるのが priority になります。

今回は、ラベルの高さを推奨サイズで配置して、その位置を元に UIView の高さを決めたい ので、UILabel の bottom の制約の priority を下げます。UILabel の推奨サイズが決まる priority (Content Hugging Priority) が 251 なので、bottom の priority を 250 以下に設定すれば、 UILabel の推奨サイズを優先的に設定して、その高さからの bottom の位置が決まるようになります。

高さが決まらない UIView を配置すると、Storyboard 上での作業がしずらい場合

高さが決まらない UIView を使うと、Storyboard 上で制約に合わせてコンポーネントの位置を自動調整するときに困ることがあります。

そんな時は、高さ（height）を適当に設定して、制約のところの Placeholder Remove at build time にチェックを入れておきます。 こうすることで、Storyboard 上の作業のときだけ制約が設定されて、実行時には制約が削除される状況を作ることができます。

UIView を使って擬似的な Preferred View を作ると高さ可変のセルが簡単につくれる

このように、セルの ContentView の子要素に Preferred View を用意して、コンテンツのサイズで UIView の高さが決まるようにすることで、 Auto Layout を使った配置の中でセルの高さを可変にすることが結構簡単にできるようになります。

他にもっと良いやり方があるかと思いますが、参考になればと思います。

UIScrollView で Auto Layout を上手く使う方法

UIScrollView も UITableViewCell と考え方は同じで、中のコンテンツを Auto Layout するときには Preferred View を用意して、 こいつにサイズを計算させて UIScrollView の contentSize を決めてやるようにします。

UIScrollView のまとめ

UIScrollView はビュー自体の frame とコンテンツ部分の contentSize の二つの要素を持ちます。frame はスクロールビュー自身の位置やサイズを表します。 contentSize はスクロールビューが表示するコンテンツのサイズを表していて、スクロールビューのサイズよりも大きい contentSize の場合には、スクロールビューの中でスクロールが発生するということになります。

UIScrollView と Auto Layout

UIScrollView で気を付けないといけないのは、contentSize は中に含まれるコンポーネントの frame や bounds で決まるわけではない ということです。

UIScrollView の contentSize はコンポーネントの intrinsicContentSize によって決まります。ここが UIScrollView でハマる一番のポイントかなと思います。

つまり、intrinsicContentSize （推奨サイズ）が決まるコンポーネントのみをコンテンツとして表示する場合には contentSize は Auto Layout が自動で計算してくれるということです。

例えば UIImageView を UIScrollView の中に入れたとします。UIImageView の intrinsicContentSize は UIImageView の frame や bounds ではなく、表示する UIImage の size になります。 なので、UIImageView だけを UIScrollView に入れると、UIImageView のサイズをいくら Storyboard 上で設定しても、勝手にスクロールされてしまうのです。

UIScrollView のサイズに合わせて画像をページングする方法

UIScrollView の contentSize は intrinsicContentSize によって決まるというのは、上で書きました。 じゃあ、contentSize をプログラムで上書きしちゃえば上手くスクロールするんでは？ということで、さがすと出てくるのが大体 viewDidLayoutSubviews の中で contentSize を設定すればいいじゃんっていうプログラム例です。

1
2
3
4
5
6
7

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()

    let contentWidth = CGFloat(preferredViews.count) * scrollView.bounds.width
    let contentHeight = scrollView.bounds.height
    scrollView.contentSize = CGSizeMake(contentWidth, contentHeight)
}

ぶっちゃけ、僕もこの方法が結局妥当かなという結論に達しました。先に UIScrollView に画像を動的に追加して、ページングできるようにするコードを掲載します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

import UIKit

class SecondViewController: UIViewController {

    @IBOutlet weak var scrollView: UIScrollView!

    var preferredViews: [UIView]!

    override func viewDidLoad() {
        super.viewDidLoad()

        let images = [UIImage(named: "Image1"), UIImage(named: "Image2"), UIImage(named: "Image3")]
        self.preferredViews = [UIView]()

        for image in images {
            let preferredView = UIView(frame: CGRectMake(0, 0, image.size.width, image.size.height))
            let imageView = UIImageView(frame: CGRectMake(0, 0, image.size.width, image.size.height))
            imageView.image = image
            imageView.contentMode = .ScaleAspectFill
            imageView.clipsToBounds = true
            preferredView.setTranslatesAutoresizingMaskIntoConstraints(false)
            imageView.setTranslatesAutoresizingMaskIntoConstraints(false)
            preferredView.addSubview(imageView)
            scrollView.addSubview(preferredView)

            preferredViews.append(preferredView)
        }
    }


    override func updateViewConstraints() {
        super.updateViewConstraints()

        var prevView: UIView? = nil
        for preferredView in preferredViews {
            let imageView = preferredView.subviews[0] as UIImageView
            preferredView.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("H:|[imageView]|",
                options: nil, metrics: nil, views: ["imageView": imageView]))
            preferredView.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("V:|[imageView]|",
                options: nil, metrics: nil, views: ["imageView": imageView]))

            if prevView == nil {
                scrollView.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("H:|[preferredView(==scrollView)]",
                    options: nil, metrics: nil, views: ["scrollView": scrollView, "preferredView": preferredView]))
            } else {
                scrollView.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("H:[prevView][preferredView(==scrollView)]",
                    options: nil, metrics: nil, views: ["scrollView": scrollView, "prevView": prevView!, "preferredView": preferredView]))
            }
            scrollView.addConstraints(NSLayoutConstraint.constraintsWithVisualFormat("V:|[preferredView(==scrollView)]",
                options: nil, metrics: nil, views: ["scrollView": scrollView, "preferredView": preferredView]))

            prevView = preferredView
        }

    }


    override func viewDidLayoutSubviews() {
        super.viewDidLayoutSubviews()

        let contentWidth = CGFloat(preferredViews.count) * scrollView.bounds.width
        let contentHeight = scrollView.bounds.height
        scrollView.contentSize = CGSizeMake(contentWidth, contentHeight)
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }
}

UIScrollView の中に画像を3つ表示して、それをページングスクロールするコードになります。Paging Enabled のオプションは Storyboard 上で設定しています。

画像を直接 UIScrollView にいれてしまうと、intrinsicContentSize の問題で表示が意図したとおりにならないので、UIImageView をラップする PreferredView を作成しています。

PreferredView の中に UIImageView を隙間なく配置し、PreferredView を ScrollView の縦横のサイズと同じサイズにして、Auto Layout で左から順番に配置しています。 ぶっちゃけ、この処理であれば、UICollectionView を使うほうが早いし楽だし美しいと思います。

UIScrollView で Auto Layout を使って頑張ってスクロールコンテンツを配置したいときに、参考になるといいと思っています。

RACCommand で検索処理とかしてるときに、ローディング画面やインジケータを表示したいということがあると思います。そういうときに使える Signal のイディオムです。コードは Swift で書いています。

MVVM で viewModel が searchCommand を実装しているとします。また、ローディングインジケータの表示には MBProgressHUD を使っているとします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

searchButton.rac_command = viewModel.searchCommand
searchButton.rac_command.executing
    .subscribeNext({ [weak self] (executing) in
        if let weakSelf = self {
            if executing as Bool {
                MBProgressHUD.showHUDAddedTo(weakSelf.view, animated: true)
            } else {
                MBProgressHUD.hideHUDForView(weakSelf.view, animated: true)
            }
        }
    })
searchButton.rac_command.errors
    .subscribeNext({ (error) in
        // エラー時のメッセージ表示処理
        println(error.localizedDescription)
    })

executing Signal はこういう風につかうんですね。

で、いつか直るだろうと思ってたけど、GM でも直っていない Swift の多次元配列の定義の謎に関してです。だれか理由分かる人いたら教えてください。。

下のようなコードがあるとします。

1
2
3
4
5
6
7
8
9

typealias NameAndValue = Dictionary<String, String>

let dict: [[NameAndValue]] = [
  [
     ["name": "",    "value": ""],
  ],
  [
     ["name": "",    "value": ""],
  ]]

typealias で別名つけて2次元配列を定義しているだけです。要素が Dictionary になっています。ここまでは普通にコンパイルが通ります。

ですが、これをこんなふうに…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

let dict: [[NameAndValue]] = [
  [
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
     ["name": "",    "value": ""],
  ],
  [
     ["name": "",    "value": ""],
  ]]

配列の要素を増やしていきます。そうするとだいたい 10件くらい からコンパイルが遅くなり、15件過ぎたくらいから コンパイルエラーが出るようになります。

1

Cannot convert the expression's type '[[NameAndValue]]' to type 'StringLiteralConvertible'

意味がわからんです。。

仕方ないので

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

var dict: [[NameAndValue]] = [[],[]]
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])
dict[0].append(["name": "",    "value": ""])

dict[1].append(["name": "",    "value": ""])
dict[1].append(["name": "",    "value": ""])
dict[1].append(["name": "",    "value": ""])
dict[1].append(["name": "",    "value": ""])
dict[1].append(["name": "",    "value": ""])

こうやって、プログラムでデータ登録するようにしました。。

本書は、NetBeans API を構築した筆者がデザインパターンやコーディング作法だけではうまくいかない問題、後方互換性を維持したままライブラリを発展させる方法、を重点的に解説しています。なるほど、 デザインパターンや設計方法を学んだ次に読むべき本 として挙げられている理由がよくわかる内容になっています。

社内ライブラリと API 設計は別物

本書で扱う API という言葉は、例えばオープンソースライブラリのような、多くの人に共有されるものという位置づけになっています。社内で使うようなライブラリなどの API とはニュアンスが違う感じがしました。

一度リリースしたら、後方互換性を維持して発展させていかなければならない、そういった類のライブラリや API を作る開発者向けの本です。

本書のテーマ

本書のテーマは、次の2つに集約されると思います。

• 後方互換性を維持する API のデザインパターン
• 優れた API であるためにどうするか

NetBeans API で培った経験則を余す所なく記載してくれているため、ボリュームがスゴイことになっています。また、作って終わりの API の作り方を教えているわけではないので、おそらくほとんどの開発者には なんとなくわかった気になるだけか難しくて後回しにする ような内容かもしれません。

はっきり言って、本書が役に立った！と感じる開発者は少ないかもしれませんが、少なくとも GitHub でソースコードを公開している開発者は頑張って読んでもらうのがいいと思いました。それくらい内容が濃く、経験者しかわからないことが書いてあります。

後方互換性を維持する API のデザインパターン

開発者は、API の現在のバージョンをコーディングしている場合に、未来について考えることが求められます。私に言えることは、それは、今までの API 設計でよく行われた方法ではないということです。また、今日までに書かれた書籍やその中の助言は、この種の思考にはあまり役に立ちません。それらには、単一バージョンの場合のデザインパターンが説明されていることがほとんどです。

これが、新しいデザイン本が必要な理由 です。今日のシステムはコンポーネントの組み合わせで出来ています。おそらく今後もこの傾向は変わらないと思います。コンポーネント利用者の経験（投資）をムダにしない為に、よりよい発展を目指す上で、後方互換性を維持することは重要なことになります。これが、本書を読む理由 です。

優れた API であるためにどうするか

では、どのように API 設計をすればいいか。その方法も本書に書かれています。

• メソッドとフィールドの優れたシグニチャ
• ファイル操作
• 環境変数とコマンドラインオプション
• API としてのテキストメッセージ
• （ネットワーク）プロトコル
• API の振る舞い
• I18N と L10N のサポート
• API の品質検査方法（正しさの証明）
• 理解しやすさ
• 一貫性
• やりたいことが満たせる API を発見できること
• 単純なことを簡単に行えること
• 投資の保全（利用者を尊重すること）

API に優れた名前をつけることや 驚き最小の法則、シンプルで一貫性のある I/F にするというのは基本的にな事になります。こういったことを踏まえた上で、この API を利用してくれているユーザを尊重すること（次のバージョンでメソッド名を変更するなんてとんでもない！）が大切だと書かれています。

後方互換性を保ち、API のユーザの投資をムダにしない設計の方法を学びたい人、新しい視点を身につけたい人に本書はおすすめです。

- オブジェクト指向アプリケーションフレームワークには、伝統的なデザインパターンとは異なるスキルが必要
- クラスを API として扱って、頭痛の種を軽減
- 将来、改善できるように API の発展計画を準備

目次

• 【第1部　理論と正当性】
  • 第1章　 現代的なソフトウェア構築の技芸
  • 第2章　 APIを作成する動機
  • 第3章　 優れたAPIを決定づけるもの
  • 第4章　 絶え間なく変わる標的
• 【第2部　実践的設計】
  • 第5章　 必要以上に公開しない
  • 第6章　 実装ではなく、インタフェースに対してコーディングする
  • 第7章　 モジュール方式アーキテクチャの使用
  • 第8章　 クライアント用とプロバイダ用のAPIを分離
  • 第9章　 テストの容易性に留意する
  • 第10章　他のAPIとの協調
  • 第11章　APIの実行時の側面
  • 第12章　宣言型プログラミング
• 【第3部　日々の生活】
  • 第13章　有害で極端な助言
  • 第14章　API設計のパラドックス
  • 第15章　API宇宙の発展
  • 第16章　チームワーク
  • 第17章　ゲームでAPI設計スキルを向上させる
  • 第18章　拡張可能なビジターパターンのケーススタディ
  • 第19章　終焉の手続き
• 終章：将来

ReactiveCocoa

リアクティブプログラミングの詳細は省くとして、RACSignal のイベントには next と completed と error があります。それぞれ、subscribeNext、subscribeCompleted、subscribeError でハンドリングできるやつです。

で、HTTP API 等を呼び出す際に API 呼び出しの結果を JSON にパースして、結果をモデルに設定するみたいなことをやりたい時に、次のように行います。（Swift で記述しています。）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

RAC(self, "model") <~ API.loadData()

class API {
    class func loadData() -> RACSignal {
        return RACSignal.createSignal({ (subscriber: RACSubscriber!) in
            let url = NSURL(string: "http://localhost:300/search")
            let configuration = NSURLSessionConfiguration.defaultSessionConfiguration()
            configuration.HTTPAdditionalHeaders = ["Accept": "application/json"]
            let session: NSURLSession = NSURLSession(configuration: configuration)
            let task: NSURLSessionDataTask = session.dataTaskWithURL(url, completionHandler: { (data: NSData!, response: NSURLResponse!, error: NSError!) in
                if error == nil {
                    // data をパースしてモデル化
                    subscriber.sendNext(model)
                    subscriber.sendCompleted()
                } else {
                    subscriber.sendError(error)
                }
                session.invalidateAndCancel()
            })
            task.resume()
            return nil
        })
    }
}

こうすると、API の呼び出しが成功した場合には subscriber.sendNext の結果がきちんと self.model に設定されるわけですが、API の呼び出しが失敗して subscriber.sendError が呼び出されてしまうと、例外がなげられます。

ではどうするか。

catchTo を使って sendError に備える

そこで catchTo を使います。

1

RAC(self, "model") <~ API.loadData().catchTo(RACSignal.empty())

catchTo は sendError が呼び出された場合に代わりに投げる RACSignal を指定します。そうすることで、ネットワークエラー等で API の呼び出しが失敗した場合には、RACSignal.empty() で何も起きなかったことになる（正確には sendCompleted が呼び出される）ようになります。

sendError 時に処理を行いたい場合には catch を代わりに使用します。

1
2
3
4

RAC(self, "model") <~ API.loadData()
    .catch({ (error: NSError!) -> RACSignal! in
        return RACSignal.empty()
    })

以上です。

1
2
3
4
5
6
7

typealias JSONDictionary = Dictionary<String, AnyObject>
let json = NSJSONSerialization.JSONObjectWithData(data, options: .MutableContainers, error: nil) as JSONDictionary

let str1 = json["foobar"]! as String    // String
let str2 = json["foobar"] as AnyObject? as? String  // String?

let str3 = json["foobar"] as String     // これはコンパイルエラー '(String, AnyObject)' is not convertible to 'String'

最後のはなぜコンパイルエラーになるかというと、Dictionary の subscript が2種類定義されていて、期待したのと違う方が呼び出されているからです。

1
2
3
4
5
6

struct Dictionary<Key : Hashable, Value> : CollectionType, DictionaryLiteralConvertible {
    ...
    subscript (i: DictionaryIndex<Key, Value>) -> (Key, Value) { get }
    subscript (key: Key) -> Value?
    ...
}

json["foobar"] の戻り値は (Key, Value) か Value? のどちらかですが、as String を付けた際に Optional ではないと判断されてしまい (Key, Value) が戻り値の型と判定されます。それでコンパイルエラーになるわけですね。

期待した通りに取得するには、json["foobar"] の戻り値を Value? として扱う必要があるので、

1
2

json["foobar"]!
json["foobar"] as AnyObject?

のどちらかでアクセスする必要があるわけです。! を付けると unwrap されるので nil が入っていると実行時エラーになります。逆に as AnyObject? as? String でアクセスすると Optional 型になってしまいます。

API のインターフェースと相談して、どちらの型で処理するか決めるといいんじゃないかと思います。

Swift の配列は mutable か immutable

Swift では配列を mutable/immutable の区別なく定義することができるようになりました。

1
2
3

var numbers = [1, 2, 3]
numbers[0] = 0
println(numbers)    // [0, 2, 3]

let で定義すると immutable、var で定義すると mutable になり、配列の代入はすべてコピーで行われるようになっています。

Force UnWrapping 型!

で、ハマったのが次のようなコードです。

1
2

var numbers: [Int]! = [1, 2, 3]
numbers[0] = 0    // error: '@lvalue $T7' is not identical to 'Int'

Force Unwrapping 型とでも言うんでしょうかね？変数に必ず値が入ってることを保証するために ! が付いた型です。 この型で定義した配列には、値の追加や変更ができなくなっています。。

これで何が困るかというと、UIKit 使って UIViewController のサブクラスにプロパティを定義する際に 初期化を viewDidLoad で行う時には、! をつけないと initializer が必要になってしまうので、プロパティの定義には ! を付けていました。

そうすると、mutable で扱いたかったプロパティなのに、変更できないという問題にぶち当たったわけです。。どうすんだこれ。。。

コンパイルエラーの例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class MyViewController: UIViewController {

  var numbers: [Int]!

  override func viewDidLoad() {
    super.viewDidLoad()

    self.numbers = [1, 2, 3]
  }


  func myFunc() {
    self.numbers[0] = 0     // コンパイルエラー
  }
}

うまくいく例

対応としては、一旦変数で受けて、変更後に元に戻すっていうので何とかなりますが、コンパイラの方でなんとかならんもんですかね。。

1
2
3
4
5

  func myFunc() {
    var nums: [Int] = self.numbers
    nums[0] = 0
    self.numbers = nums
  }