マルチタスキングを考慮した
iPadアプリ開発
NOV/18,2015 安達 彰典
自己紹介 : 安達彰典@adachi_c
• 趣味
・作ってるゲーム(C++) ・qMapEditor(objc)
(マップ・エディタ)
・qMapBuilder(Go)
(自動地形生成)
スライドの目的
• iOS9対応iPadアプリを作るにあたって苦労した
点、工夫すると良さそうな点を共有
目次
1.AppCode
2.開発フロー
3.Carthage
4.iPad開発の特徴
5.ワイヤーフレーム
6.その他考慮ポイント
7.モデル/ビューの完全な分離
8.描画関連デリゲート順番
9.Swiftについて
10.まとめ
iOS9とAppCode
• 使いたい
• 11月3日までAppCode3.2だった
• Xcode7に対応していない
• JetBrainsに金払いながらもXcodeを使ってる期間
iPadアプリ開発/最初の分岐
• iOS7に対応するのか?
• マルチタスキングに関係ないが苦難の道
• 主にSwiftライブラリ/8以上対応が多い
• ユニバーサルバイナリか?
• マルチタスキングに関係ないが苦難の道
iPadアプリ開発の特徴
• Split view
• iOS9の新機能
• Compact(SizeClass)とRegular(SizeClass)の2パターンの画面設
計が必要
• 回転
• LandscapeとPortraitも、traitCollectionから引っ張ってこれる
が、iOS7以前ではtraitCollectionがない
• 結局書き分ける
ワイヤーフレーム
• QAしやすいように作ることが全て
• 作り手も使い手も理解しやすいものを作る
• 状態遷移を明確化し、アプリ全体のルールとする
• 状態/イベント/アクション
その他考慮ポイント1
• 開発メンバーが2人以上ならこの辺を統一しておく
と良いかもしれない
その他考慮ポイント
• あとからのgrepを考慮
• 具象に対する呼び方、用語の統一
• クロージャかデリゲートか
• 迷ったらデリゲート
• 大事なやつはアクセサを作る
その他考慮ポイント
• assert
• スキあらばあらゆる箇所に入れる
• 状態数
• とにかく状態を減らす
• クロージャ
• ヒープ渡しでなく、スタック渡しするようにする
• デリゲートのほうが一本の線で表せてオブジェクト指向崩さない
その他考慮ポイント
• シングルトン
• 実質的なグローバル変数、追加時は厳格に協議
• オブジェクト指向を壊す
その他考慮ポイント
• NSNotification
• 逃げの設計
• オブジェクト指向を壊す
• メモリリーク+postNotificationで死はよくある話
その他考慮ポイント
• 値渡しか参照渡しか
• 値渡しを使う
• モデルはstructでいいかな感
• パフォーマンスが落ちるところだけ参照渡しに
モデル/ビューの完全な分離
• あちこちからビューの更新、モデルの更新というこ
とを避けたい
モデル/ビューの完全な分離
• メインループを意識する
• 1.ユーザアクション以外のイベント->モデル操作
• 2.ユーザアクション->モデル操作
• 3.モデル操作された分のビュー操作
• 1ループで
• モデル操作フェーズ
• ビュー操作フェーズ
• をわかりやすくする。
モデル/ビューの完全な分離
• ビューとモデルの不整合をなくすとは
• すなわち、状態の把握、同期
• レンダリング時にいつ何が呼ばれるかを整理
• その中でsplit時、rotate時の呼びだされ順を知る
描画関連デリゲート順
• 前提
• storyboardで基本の骨組みを作る
• 個々のビューはxibをロードする
• 状態が多いので、なるべくコード量を減らしたい
• 状態の数が多いほど不整合発生する
描画関連デリゲート順
• ビューの操作
• updateViewConstraints,
• updateConstraints
• layoutSubview
• からの操作に限定
• アニメーションなどもlayoutConstraintsのみ使う
描画関連デリゲート順
• 注意ポイント
• User Interaction/rotate/splitがどこに入るか?
• アニメーションをどうやるのか?
• タップハンドラなどから実行
• extensionしまくるのも手
• ヘルパを用意、これもgrepしやすいと良い
描画関連デリゲート順
• 何を使っていくか
• StoryBoard, Xibに定義していればコードを記述しな
くても良い
• 記述する場面(いずれもレアケース)
• xibをロードしないviewの生成、貼り付け、剥がし
• 回転やsplitしたあとで、状態がかわるとき
描画関連デリゲート順
• UIViewController
• 1.viewWillLayoutSubviews(ビューが再レイアウトされるときに呼ば
れる)
• 使わない
• 2.viewDidLayoutSubviews
• 使わない
• 3.updateViewConstraints(Constraintsが変更されるときに呼ばれる)
• 使わない
描画関連デリゲート順
• UIView
• 1.layoutSubviews(NeedsLayoutが有効時)
• 使う
• やること
• removeFromSuperview
• addSubview
• addConstraints
• 2.updateConstraints(NeedsUpdatedConstraintsが有効時)
• 使わない
描画関連デリゲート順
• 回転
• iOS7
• 1.willRotateToInterfaceOrientation
• 2.didRotateFromInterfaceOrientation
• 使う
• やること:
• C/Rの状態変更後のビュー調整
描画関連デリゲート順
• 回転
• iOS8,9
• viewWillTransitionToSize
• traitCollectionWillChange
• traitCollectionDidChange
• 使う
• やること:
• C/Rの状態変更後のビュー調整
描画関連デリゲート順
• Split View
• 0.デバイダーをつまんだ
• 1.applicationWillResignActive
• 2.デバイダーを動かす
• 3.各境界に達したときにlayoutSubviewが呼ばれる
• 4.デバイダーを離す
• 5.SizeClassが変わっていればdidChangeTraitCollectionが呼ばれる
• didChangeTraitCollectionで状態変化調整しておけば基本的になにもしなくて良い
結果こうなる
• TopViewController一強時代
• デリゲート経由での通知を使う
• Notificationやシングルトンをやめる
• よく使うところはオンメモリ(記事/リストのビューはキャッシュ)
• アニメーションはヘルパ
• コード的にはextensionを作りまくる
• Split View「そのもの」については対応しなくて良い
Swiftも使った所感
• enum無双
• varが定義でき、それぞれのcaseに機能もてる
• エンドポイントのURLかえすやつとか
• extention無双
• 可読性アップのためにとにかく分ける
• ジェネリクス
• 共通処理をまとめられる
• APIアクセスのコードなどで使ってます
• CommonRequestやCommonResponseを継承したものをFetcher<Res>などとしてわたして、クラス
毎のパースが動作
まとめ
• マルチタスキングとか使いたい、iOS9/Swift開発したいときは
deployment target iOS8以上がオススメ
• とにかく状態が多いのでQAしやすいように状態を整理するの
がオススメ
• コードでビューを制御しようとするといっぱいかかないとダ
メなのでxibやstoryboardに書くのがオススメ
• Swift使いたい人は、とにかくenumを伸ばしていくのオススメ

iOS9/iPadとマルチタスキング