関西 Cocoa 勉強会

グランフロント大阪

2014/02/15

SKAction in Sprite Kit

@studioshin さん

本のCapter 3の説明

の前に宣伝コーナー

What is Sprite kit?

1. iOS7 + OSX(10.9〜）の2Dgame用Framework
2. WWDC 2013 Start.

Cocos2D とか使っていれば馴染みある感じになっている。

1. SKView（スプライトを表示する土台となるView）
2. SKSene（スプライトの集合を管理して、レンダリングする）
3. SKNode (テキスト、画像、動画、パスやキャラクターなど）

View関連は「SKView <- SKSene <= SKNode(Subclass)」という感じのView構想になっている。

• 原点は左下。iOSとは違うので注意（おそらく計算便宜上）
• SKNodeの基準点はNodeの中心にある

Xcode 5 からSPliteKitGameのひな形

があるのでそれから作成する

Debug 表示で、Node数とFPSが出る。（値を変更するだけで、SpriteKitが出してくれる）

連続実行は一番ながい秒数が採用される。

カスタムアクション

• 子ノードのアクションを実行させる
• ブロックスを呼ぶ
• 繰り返し実行するアクション
• ノード自体を削除する

Crash Report

解析系サービスを試してみた

@itok さん ( http://itok.jp )

• CrashReport を効率よくあつめたい
• アプリ内で起きたエラーもできればあつめたい

FLURRY/Bugsense/CRITTERCISM/Crashlytics

FLURRY

マルチプラットフォーム

• iOS/Android/WindowsPhone/Java/BlackBerry/Web
• 完全無料
• 広告SDもある（これが収益？）
• バカ重たい

Bugsense

マルチプラットフォーム

• 有料プランがある
• 結構いいお値段（月額ナン10ドル）
• Mac用クライアントあり
• Github/JIRAとかと連携している
• Issue連結があるから、クラッシュがあるとIssueが上がる

CRITTERCISM

マルチプラットフォーム

• ログ取得は有料プラン
• ほんとに使おうと思ったらEnterpriceプラン出ないと使えんっぽい
• Github/JIRAとかと連結あり

アプリが落ちた時とかが画面見ててわかる

• CrashReportだけあってもユーザの操作がわからない
• どのViewをみてるとかなど、ログをSDK経由で残している
• ただしこの機能使うときは、有料プランで月額何十ドル

crashlytics

日本では有名

マルチプラットフォーム

• 完全無料（2012.1にTwitterに買収）
• Invitation必要だけど、メール登録すればいい
• Mac用アプリなどがって、Xcodeに対して設定する。
• ログも取れる

どこのサービスもクラッシュする方法が書いている。配列にnil突っ込んだり。

• デバッグ中はコンソール、ファイルに両方書き出し
• リリースではファイルに書き出して必要な時に送ってもらう
• DDLog で流せば、ファイル+TestFlight+Console

その他

• GoogleAnalystics / Debug Traceがない
• HookeyApp
• QuunyKit？自前
• CocoaLumberjack？

External Accessory開発のデバッグ

@Flowyさん

iOSデバイスにアクセサリを接続してしまうとXcodeでデバッグできない

結論：頑張る

デバッガを接続するパターン

アクセサリのストリームをファイルのや無線で代用

本番環境ではない。デバッグできる

1. アクセサリをシミュレートするサーバを使ってWiFi経由で接続。
   2. アクセサリのシミュレートサーバを作らなきゃいけないのが面倒
2. アクセサリシミュレートのサーバをアプリ内に立てる
   1. でかいのをアプリのためにひとつ作るハメになる。
3. デバイスを二台用意して、片方をアクセサリ、片方をデバッガ。Wifi経由ですべてのイベントを取得
   1. 本番環境には近いが、速度が遅い。
4. アクセサリを接続する
   1. ログデバッグ
   2. つらかった
   3. 最後はこうなる
   4. Instroments ではWifi越しに取れる

ログの出し方

1. Wifi経由でUDP。
2. ファイルログ
3. Debug 用View

Tips

FWのデバッガは、アプリよりFW屋に聞きに行くことが多し…

iOSアプリ内課金

@tworks さん (HHKBの会社のエンジニアさん）

広告＋アプリ内課金の話

（よく知らないけど、ラブカってラブライブの内部課金ぽい）

アプリの課金をAppStoreに支払う形になっている。

アプリはProductIDをAppStoreに投げて、AppStoreはアプリに返す。

サービス運営が、購入情報を保存させる。

自社サーバにラブカを保存させる方法：サーバプロダクトモデル

広告削除などをする

組み込みプロダクトモデル

アプリ内に予め作りこんで、アンロックする形のモデル。

課金モデル

1. 非消耗型
2. 消耗型
3. 自動更新型
   1. 非消耗型プロダクトに似てるが、期限がついてる。7/30/60日などパターンがある。
4. 非更新期購読型
   1. 独自に有効期限をつける。自前でサーバを立てて有効期限管理が必要になる（自然とサーバプロダクトモデル型になる）
5. 自動更新購読型
   1. ニューススタンドに使うモデル

サーバプロダクト、組み込み型のメリットとか

• サーバプロダクト
  • メリット：プロダクトに幅広く対応可
  • デメリット：サーバ運営
• 組み込み型プロダクト
  • メリット：実装が簡易
  • デメリット：扱うプロダクトが限定される（非消耗型、自動更新購読型）

アプリ内課金、非消耗型はRestore必須、消耗型は必ずしもサーバプロダクトモデルではないが、実運用上必要となる。（消耗型の場合、1000円課金の後、内部で削って使っていく形なので、サーバがなければデバイス変わるとそれが使えなくなってしまうため）

設定の機能制限も任意に実装しないとリジェクトされるはず。

決済機構は外部

購入者⇔オレオレ照会サーバ⇔決済サーバ

1. webサーバ建てる必要ある
2. 決済システムとの接続テスト
3. 購入者に対する信用アピール

アプリ内課金使うと、Apple/Google/Microsoftとアプリの通信部分のみの開発になる。

信頼性ははじめからある。

まとめ

1. 概念はMacOSXでも同じ。
2. 初めは非消耗型プロダクトで仕組みを理解するのがおすすめ
3. 「アプリ内課金＋広告 iPhone プログラミング」を読んでくださいな

質疑

1. ダウンロードするタイプは
   1. 非消耗型プロダクトに対してできる
2. 課金ユーザは？
   1. 開発中はテストユーザでしか課金ができず、実際には金額は使われない
3. テストに対してユーザの数が増えたが、今も変わらず？
   1. 変わらず。連番ユーザ増えてる。（Appleらしい）
4. Enterpriceはどうなる？
   1. そもそもStoreにないから無理じゃない。

TDD をはじめつつ仕事の成果を出す方法

@yashigani さん Fenrir Inc.

What is TDD ?

1. TestDrivenDevelopment

2. Red - Green -> Refecter

   1. テストを書いて落ちることを確認
   2. テストが通る最小限の実装をする
   3. テストが通ったら、それを維持したまま開発を進める

3. 嬉しい事

   1. リサイクルが終わるとテストが残る
   2. 人が探すとめんどくさい事を機械任せに

4. 型を守る

   1. Red のサイクルは重要
   2. テストがミスってることもあるので

テストを書く理由

• 要求仕様がどこの段階で実装されているのか
• 未来に追加変更するための手助けになる
• 動作保証
• 実装を早く進めるため

テストを書くと遅くなるのではないか？

1. 例えば API クライアントのようなもの実装を考える

   1. UI作って進める
   2. デバッグ実行

2. UI実装はコスト高い。

   1. 実装面倒
   2. UIのバグか、APIバグかわかりにくいことがあるのでイケてない。
   3. 試せる頃には絶対なにか忘れてる

3. デバッグ実行

   1. lldbとかから入力
   2. 毎回心込めて実行…？

4. テストは書くところは書いて、書かなくていいところは書かない

   1. テストを書いて何が嬉しいかを考える
   2. Model とか難しい処理の時はテスト書いた方がいい
   3. 逆にViewのテストとかはテストに合わない（仕様変更の影響が多い）

5. テストを導入する箇所にはコストを意識

6. 動作確認に使う

   1. 新しいAPIやライブラリの挙動を確認するとき
   2. テストを残しておくと、後々使える
   3. OS ver ごとに挙動の違いを検証

経験談 (失敗談)

1. テストが動かないまま放置してた
   1. 直さなかった
   2. CIテスト実行のjobはスクリプトの実行のみを削除、jobはそのまま
   3. その後忘れてて、空ジョブが回ってて毎回OK
   4. 悲しかった
2. 書いた日しか通らないテスト
   1. 過去30日のログのみを残す
   2. 特定の日から100日追加した
   3. 次の日試すとテスト落ちる
   4. 継続的にテストを実行する必要
3. テストを書くのもコスト
   1. 煩雑なデータを作る必要のあるテストは書くのが面倒
   2. テスト書かないと、デバッグ面倒だった
4. いいと感じる
   1. エラーケースを作るのが簡単
   2. 複雑な要件を徐々に実装していくのが容易
   3. テスト実行時にブレイクポイントを設定できる

BDD

Beer Driven Development

Behavior Driven Development

1. TDDのテストをより要求仕様に近い形で表現
   1. RSpecとかCucumber
   2. Cocoa/IOS BDDFramework
      1. Kiwi
      2. Specta
2. vs XCTest/SenTestingKit

   1. 使うのにセットアップ必要

   2. mesoddotannidejikkoudekinai

   3. 圧倒的に可読性が高い

まとめ

コストを考えて、考慮しつつ、無理せず導入するといい

やるなら絶対にCIまで

Kiwi/Spectaは同居できないので注意\

参考: https://github.com/yashigani/HREClient

CoreData and ACID

@t_motooka さん（webapp）

What is ACID?

1. RDBMSのトランザクション処理が備えるべき性質機能
   1. データが正しく処理させるための物
   2. ちゃんとやればやるほど、性能はおそくなる
   3. 頭文字（Atomicity Consistency Isolation Durability）

不可分性/原子性/Atomicity

1. 全部やるかやらないか
   1. 操作は全て成功するor全て失敗する

整合性 / Consistency

1. 一貫性
   1. 制約を設けて、データを保証する

排他制御 / Isolation

1. 独立性/排他性
   1. スレッドセーフに近い
   2. 性能とのトレードオフ性が高い

永続性 / Durability

1. コミットされたデータは永続
   1. プログラム側は永続性を気にしない

Acid/CoreData

1. Sqlite の整合性：Validation
2. 永続性：満たしてる
3. 原子性/排他性は？

２つしゃべると長いので、原子性。

原子性の話

銀行口座の例（DBサーバ）

1. A to B (500円)
   1. A -500
   2. サーバオチ
   3. 復活後口座の500円は戻ってる

CoreData は？

デモ：
エンティティは1口座1行入る形

1. Aさんに3000円
2. Bさんに1000円
3. AさんがBさんに500円
4. 同上（ただし異常）Bさんの残高増やす前に@throwを投げて落とす
5. Aさんの500円減るだけの保存処理をコメントアウト
6. Aさんの口座も変わらず、Bさんの口座も変わらず

Atomicityがあるとき

1. contextのsaveまではデータは揮発性

2. saveすると不揮発性

3. save は最後の最後に一回だけでOK?

   1. 途中でクラッシュしたら全部戻るけどいいの？
   2. 長すぎるトランザクションはパフォーマンス問題と仲良し

4. どこからどこまでをatomicにするか、しっかり検討してください

Atomicity を実装するには

1. メインのデータファイル + WAL
   1. Write Ahead Logging ログ先行書き込み
   2. データ変更が WAL に追記されていく
2. Check Point 処理
   1. WAL 内容をデータファイルに反映
   2. どのタイミングで使われているのかよくわからなかったのでまた今度
3. 動かすのも実装も大変

Atomicityが無いとき

1. Storeがひとつの時は大丈夫
2. データ容量とか歴史的事情により、Storeが２つ以上あるとき
   1. Storeが２つになることを前提に作ってるわけではないんではないか。
3. CoreData以外の操作を合わせて原子性をもたせるには？ 1. めっちゃ難しいよ
4. 保証は無理だけど、最大限がんばろう
   1. クラッシュを減らす
   2. ユーザの利益になるデータ不整合

RDBMS での実装例

1. 2相コミット(Two Phase COmmit）
2. データストアが複数存在する場合の話
3. 各ストアにコミットしていい？と聞きまわる
   1. 遅い、ロックかかる、途中で死によった、など…
4. 難しい

排他制御

1. データをどう正確に読ませるか

   1. A さんが更新
   2. Bさんが読みに来た
   3. AさんがRollback
   4. Bさんはどのデータを見た？

2. Isolation

   1. Dirty Read/Non-なんとかかんとか

まとめ

1. Atomicity どっからどこまで？
2. Isolationの話、は次回
3. CoreDataのベースにはRDBMSの内容

少しだけPR

突然の死 (AppStoreにあります）

1. AAを作るiOS App:: 突然の死
2. 簡単操作
3. Tweet できる
4. IAd でる

Github における僕の活動

@Cockscombさん via Hatena

CXCKeyValueObserver

1. Key Value Observation
   1. KVCoding でオブジェクトの状態を監視
   2. Model の更新アレば、Viewも更新する、という時に便利
2. obser... というメソッドに全部書かなきゃいけない
   1. removeObcerverforKeyPath: を呼び忘れてはいけない
   2. だんだん複雑になっていく
   3. 複数人開発に向かないっぽい…

僕はとりあえず、KVOが好きで…ほんとに好きで…好きなんですよ

そんなわけで、CXCKeyValueOberver を作った

1. Ovserver の処理を短くする
2. Blocks を使って宣言的に記述
3. 自動的に removeObserverforKeyPath へ登録するようにした

紹介はここまで

The UnitTesting For Objective-C

• Kiwi
• Nocilla

もうちょっと話すことあるんじゃない？か、と思った。

単体テストの事。

• XCTest
• BDDライブラリ
• 非同期テストライブラリ
• カスタムマッチャ(Assert より良いのがほしい)
• Mock/Stub/NetworkStub

XCTest

特に書くことは無い、だって。

BDD

• kiwi
• Specta

テストがちゃんと説明できて、無意味なテストにあまりならない

非同期テスト

同期的に処理されない時のテスト

• Kiwi
• Specta
• TRVSMonitor
• TKRGuarcl

カスタムマッチャ

便利な Assert。 0 != 0.0 は XCTestでは違うが、それを人的に合わす

• Kiwi
• OCHamcrasta
• Expecta

Mock / Stub

テストしたいオブジェクトが依存しているオブジェクトを擬似的に創りだしてテスト

• Kiwi
• OCMock

Network Stub

ネットワーク状態とかレスポンスを擬似的に作りだして、ネットワーク周りのテストを作り出す

• Mocilla
• OHHTTPStubs

まとめ

Kiwi がすごいやってくれるけど、やり過ぎじゃね、ということで、あえて使ってない。

OCMock には nice〜というmock object を使うと、宣言していないメソッドが呼ばれても起こられないという素敵なnice

雑談

AppCode の宣伝…？

iBeaconについて

@usamik26 さん。フェンリル

1. iOS7 で追加された。
2. BLEを利用
   1. ペアリングが不必要
3. 受信側デバイス
   • BLE 搭載のiOSデバイス
4. 発信側
   1. iBeacom仕様のビーコン発信を実装したもの
5. バックグラウンドでも検出できる
6. おおまかな距離の情報が取得できる（ものすごく近いか、遠いか、ものすごく遠い、の3段階。数cm、数m、程度）

WWDCのAirLocate サンプルが使いやすい

CoreLocation にビーコン検出の機能があるからそれを使う。

CLLocationManager を使う

お互いがビーコンを発信すると同時に受信する。相手のビーコンを取得したら通知するアプリ: Ninja Tryst

iBeacon ハッカソン

非開発者が多くて、アイデア出しの話になってた。

Beacon自身の距離測定の精度が悪いのが難点なのが今のところ残念