#shibuya_sp 勉強会 vol1 : ATNDに参加してきたので、その時のメモです。

iOSアプリケーションのUnit Test – 岸川

テストを習慣化するには

なぜテストを書かないか

• テストの効果がわかりにくい
• iPhoneアプリのテストってどう書けばいいのかワカラナイ
• デバイス固有のデータを利用していたりする

ツール/フレームワークを使う

• 繰り返し実行するのが簡単
• 自動化できる
• テスト結果が見えてくるようになる

無理をしない

• モデルのテストは書きやすい
• 論理構造はそう簡単に変わらないはず
• 繰り返し実行するメリットがあるので(正常系/例外/異常/境界値)をちゃんとテストする

表示は論理構造が簡単にひっくり返る事があるので、テストを無理に書こうとしない

テストしやすいコードを書く努力はする

• テストしやすいコードは、使い易いコードなので良い設計にも繋がる
• メソッドをきちんと分けてあげる

単体テストをワークフローに取り入れる

• OCUnit
• GHUnit

OCUnit

• XCode標準
• XCodeと統合されてるが、アサーションが貧弱
• 非同期テストがサポートされてない

GHUnit

• XCode非標準
• アサーションが豊富
• まともなテストができる(teardown/setup)
• 非同期テストのサポート(waitを使える)
• OCUnitのテストケースも実行可能
• viewのテスト機能が追加された

Viewのテスト

GHVerifyView あらかじめ取っておいた画面の画像と照らしあわせてテストしてくれる 画像での比較

Flashからcocos2dに移植した話 – CAつりポンチーム

• Flashとcocos2dに移植した

• 1万７千件のレビュー

• 平均4.5☆

• Twitterによる拡散

• 完全無料広告なし
• アメーバピグ
• ストレスフリー
• App Storeのレビュー誘導

オフライン対応

非会員対応

• ほぼすべての機能を非会員でも遊べる
• 会員と非会員の差別化
• タイトル画面の対応のみ
• ポイントの管理をローカルにおいて、サーバ側からポイント管理を排除

iPod Touchのユーザーが30% => オフライン対応の成果?

cocos2dとFlash

大量の画像を書きだす

• 手動は日が暮れるので
• アクションを作って、画像ファイル名=レイヤー名にしてバッチで生成

texturepacker を知る

• 一枚の画像に素材を貼り付けて、座標データからファイルを切り出して表示する
• CSS スプライトみたいな

AutoSD

自動でRetinaと通常の解像度を作成できる

Spriteはフォルダ管理

Finder上でフォルダ構造そのままにSPriteを管理できて楽 texturepacker上に反映する

見ていて飽きないガチャを作れという司令

まずはFlashで動きを作る

1. 色を選ぶ
2. ガチャを出すアニメーション

自作AIRツールで座標の抽出

swfから座標の抽出をするソフトを作成した

• 座標系の違いを補正する スクリーン座標 -> デカルト座標
• Flash上のレイアウトがそのままcocos2dに移植

cocos2dを利王した最適化と高速化

• 描画処理の高速化
• テクスチャロードの非同期化

iPhoneのOpenGLの傾向と対策

• OpenGLの描画を呼び出すほどオーバーヘッドが大きなリ重くなる傾向
• なので、texturepackerを使ってテクスチャを一回でロードしたりして 呼び出し回数を減らした。

テクスチャロードの非同期化

• 非同期で先にテクスチャを読み込んで、読み込み待ちを減少させる
• addImageAsyncを使って非同期ロード

テクスチャフォーマットの調整

• RGBA4444に統一してる(32bit -> 16bit)

モーション制御の最適化

CCPawnやCCSequenceを処理コストが多いでの、人体とかが苦手だった。 モーションデータを削減して、モーション制御をNEONで並列処理にして最適化

コンフィグの微調整

ccConfig.hでCCUSESVBOを無効にするだけで結構変わる

Time Profiler

順次上から見て最適化をしていく

まとめ

• テクスチャは一枚にまとめてCCSpriteBatchNodeで描画
• NEONなどSIMDを使って最適化
• ccConfig.hをみてチューニング

OCTOBAから見た面白いAndroidアプリ – 丸岡

Android Market

アプリ削除率

• 37%?

OCTOBA

• 男性が多い
• 30-40代が多い

パーミッションの問題

Any.Do

• 機密ログデータの読取
• このパーミッションを要求するアプリはレビューしない

いろいろなパーミッション

• 機密ログデータの読取
• 連絡先データの読取
• SMSメッセージの送信
• アカウントの認証情報を利用
• 起動中のアプリケーション情報
• 端末ステータスとIDの取得

広告SDKでGPSデータを利用してターゲティングを使用したりするものもある。 組み込んだアプリでGPSを使ってなくても、パーミッションが求められる

レビューの基準

人気ジャンル

セキュリティが5月(2011)あたりが入ってる

• ツール・設定系
• ゲームエンタメ系

昔はツール系が多かったが、ゲームエンタメ系が増えてきている

検索キーワード

1. 電話帳
2. 時計
3. メール

使ってもらえるアプリの考え方 – fladdict

ATMアプリを考えてみる

架空の事例で考える

リサーチ

• 既存のATMの機能?
• 既存のATMの不便?
• どういう時に使う

既存のATMの機能

• 残高確認
• 入金、引き出し
• 送金
• 設定変更

オンラインバンキングを含めるともっとたくさんあるので、 どの機能をアプリに含めるのかを考える -> 絞り込む、利用の想定

シナリオ

• 通販などの振込
• 通常の送金
• 支払い忘れへの緊急対応
• 残高確認

逆にスマートフォンで保険や税金管理などの操作はしないとのでいらないはず

90%のユーザーが必要な機能を入れる

• ヘルプなしでわかるアプリを作る
• アプリを起動してからそのアプリのタスクを1-2駅程度の間に完了できるようにする

必要な機能を絞り込んでから、コンセプトを立てる

コンセプトの定義

iPhoneアプリは大体4つの形がある

• ユーティリティ型
• ナビゲーション型(TableView)
• タブ型
• 没入型(全画面)

それぞれのタイプをプロトタイピングして検証していく。

ユーティリティ型

• 最低限だけの機能
• 残高の確認
• 送金ができる

ナビゲーション型

ユーティリティより機能は増える

• ニュース
• 残高
• 送金
• 設定

タブ型

ナビゲーション型と似た機能を持つが、平行して機能を使える

没入型

iPhoneのUIに頼らないので時間がかかる

• 実際の画面に似せるなど
• ナビゲーションを出してみたり
• 現実のメタファ

今回はナビゲーション型かタブ型

ナビゲーション型

• 拡張しやすい
• 単純

タブ型

• 拡張に限界がある
• 平行して機能を利用できるのが利点

ナビゲーション型は階層が深いと、作業を切り替えるにコストがかかるので、タブ型の方がやりやすい

タブ型のメニュー

よく使うものから左から右へ配置していく

ニュースを残高確認後に見る人はあまりいない ニュースをATM側としては配信したいので、ニュースを左に持ってきて自動的に見せるようにした。

設定画面

• ピンコード
• アカウント名
• 銀行アカウントのパスコード

入力UI

• Pickerを使って桁ミスなくすなど
• 送金時はボタンのミスタッチをなくす
• スライドで送金処理を完了させる <= 難しいUIな気がする…
• 最初にボタンを詰め込みすぎない

---

Edit Qute for PC/Mac