iOS:StoryBoard Tips[初期画面を変更する]

StoryBoardありでプロジェクトを作ったりすると最初から初期画面が決まっている（→）がついていたり、空のStoryBoardにViewControllerを追加するとその画面が初期画面になりますが、StoryBoardでひと通り作成したあとに、やっぱりべつのViewControllerを初期画面にするときの設定方法です。

下の図のTabBarControllerが現在初期画面になっていますが、これをViewControllerに変える方法です。

StoryBoard上でViewControllerを選択し、
右の画面のAttribute Inspectorを開きます。
ViewControllerのセクションに"Initial Scene"というチェックボックスがあるので、これをチェックすると初期遷移のSegueが移動します。

iOSでOCMockでテストする【環境構築】

Objective-C用のMockライブラリ　OCMockを使うための環境構築

環境：
　Xcode 4.3.2
   OCMock 2.0

まずここからダウンロード。（ソースコードからやるやり方は後日追記予定）
http://ocmock.org/

"Download"のタブからdmgファイルをダウンロードします。
http://ocmock.org/downloads/ocmock-2.0.1.dmg　(2012/06/24現在の最新）

ダウンロードしたら開きます。
展開されて、iOS, OSX, Source　の３つのディレクトリが現れます。

iOSを開きOCMockのディレクトリをドラックアンドドロップでプロジェクトに追加。

libOCMock.aも同じくプロジェクトに追加。（ここではOCMockディレクトリ内に入れます）

そうするとこのようになるはずです。（注：プロジェクトに追加する際に、Copy items into destination ...にチェックいれるのを忘れないこと)

TargetのBuild Phasesのタブを選択し、Link Binary WIth Librariesのセクションを開きlibOCMock.aを追加します。

#import <OCMock/OCMock.h>を発見できるように、

 Build SettingのHeader Search Pathに$(SRCROOT)を追加。

ライブラリをリンクするために
Build Settingのother linker flagに -ObjC -force_load $(SRCROOT)/OCMock/libOCMock.a　を追加。

以上で環境設定は完了です。

試しにテストコード(SenTest)に

#import < OCMock/OCMock.h>


- (void)testExample

{

    id tableViewMock = [OCMockObject mockForClass:[UITableView class]];

}

を記載して、Cmd + Uでテストを実行してみましょう。

OnLab Data Conferenceに参加してきた

Onlab Data Conferenceに参加してきました。

データ分析に使えるサービスはよく知らなかったのでとても勉強になりました。
リーン・スタートアップでも言われていますが、検証するためにはデータが非常に重要で、それを行うためには、何を分析するのかという目的が必要で、さらには分析するためのデータが必要です。そのデータを集めるにはサービスをローンチする際にあらかじめそういった仕掛けを埋め込んでおかなければならないわけで、速くサービスを出すにはこういったデータ解析サービスをうまく活用していくことは必須だと思いました。
データをものすごく見ることも重要ですが、それをやりすぎると局所解に陥ってしまうというところのさじ加減も肝心だなと。
サービスの序盤のようにユーザーが少ないときは、母数も少ないのでデータ解析に頼るよりはユーザー一人ひとりにフォーカスをあてて話をするといったアナログなやり方のほうがいいという意見にはすごく同意でした。

予測分析 Peter Skomoroch(LinkedIn)

予測から戦略を立てるという例で映画シャーロック・ホームズをあげていました。
ストリートファイトでシャーロック・ホームズは予測から戦略を立てて戦っていて、戦い方は日頃から練習でつちかっている。
ビジネスでもストリートファイトのように考える。
データをしっかり見て分析する（例：ヤギと男と男と壁と）

データを壊すくらいデータをみる。

John Rauserのプレゼンを見るといい

http://www.justincarmony.com/blog/2012/05/13/video-look-at-your-data-john-rauser-velocity-2011/

平均は見ても意味が無い。大事な特徴的なデータが平滑化されてしまう。

データと直感だけではだめ、アルゴリズムに基づいている必要がある

・データはどのように反映している？

・意思決定へのサジェスチョンに使っている。ある特定のユーザーをとりあげて分析したり、A/Bテストを少数のユーザーに対して行う

データは適切な場所に保存することが重要、これには最初から準備しておく必要がある。

何かを消すときも消さずに消したことを保存しておいたほうがいい。

オートコンプリートを用意しておくことで最初からデータを整形できてデータ整理にもいいし、ユーザーにとてもよい。

一つひとつの数字を深掘りしていくことが重要

まずはユーザを集めてからデータを解析したほうがいい。（母数が小さいと統計が難しい

）

・データサイエンティストにはどんなひとがむいてる？

・ある程度のコーディングスキルと科学のバックグラウンド

アナリティクス・アクセス解析・KPI設定　Hiten Shah(KISSmetrics)

アクションができるメトリクスにフォーカスする。

GoogleAnalyticsでとれるようなデータはVanity Metricsだ。

例えばPage Viewとか。trafficが多いからといって必ずしもビジネスには役に立たない。

web analyticsでなくcustomer analyticsでないといけない。

すべての経験（ユーザー行動）をトラックする。

データを個々のユーザとひもづけることによって匿名状態でも個人の行動を解析することが可能。

ユーザーは複数のチャネルから来るので、カスタマーベースでトラッキングする必要がある。だれが価値のあるユーザーか（そのユーザーはどこからきてるか）みつけるのに役立つ。

重要なアクションをしたのはなぜか、など全体のカスタマーライフサイクルをトラッキングする。

速く学ぶ必要がある。他より速く学ぶのが勝つ方法。

・生涯価値を予測するには？

・単純な計算でもいいので予測をたてること。すでにあるサービスをモデルにする。

・仮設を立てるところから始め、どういったリスクが伴うのか知っておく

・プロダクトが市場にフィットするか？

・この製品がなくなったらどう思うか考えてみる。

・ユーザーが少ない時は？

・個々の人に落としこむ

HowToListenToYourUsers　Pete Koomen (Optimezely)

これが正しいと思ってやるのはナンセンス。

必ずしもうまくいくとは限らない。

最初のサービスは４ヶ月かけてつくったが誰もやらなかったし、お金は全く儲からなかった。

次のサービスは１ヶ月で初歩的なのをつくったがだめだったのでやめた。

OptimizelyはA/Bテストを簡単にできるサービス。

・作る前に１０人くらいのユーザの重要な問題にフォーカスする。

モックをつくる。仮設をつくるための情報を集める

・ユーザーと話す。人々は改善への貢献はそんなに嫌がらない。

そして売ることが大切（金を払う価値のあるものをつくる）
中古車屋のセールスマンみたいなのはつかってはだめ
近道するのも重要（例えば、期間毎にライセンス料を変えていたけど、実はライセンスが切れたときの実装は入れていなかったけどだれも気にしなかった）
スケーリングは気にしなくていい
ユーザーが利用をやめたときが分析するいいタイミング。
キャンセルボタンを消して、メールを送らないとキャンセルできないようにして、その時にユーザーになんでやめたのかを聞いたりした。
Flurry,Kontagent,KISSmetricsとかで分析する。

アクションがとれるデータとしてはA/Bテストがある。ただし十分なトラフィックが必要。
ただしRefinement = design decision ではない。

・テスト期間はどれくらい必要？
・最低２週間（トラフィックがある場合）。統計上必要な量で決まる。

QualitativeData and UX  Chrix Palmeiri (AQ)

・UX　どう感じ、どう使い、どう説明するのか
　ユーザーテストは対象は知り合いでもいいからやったほうがあいい

・質問票
　ユーザーテストをやるタイミングはユーザーのニーズとギャップがあるとき
　何にわくわくしているかわからないとき
　例えば、サインアップのときになぜ、何に期待してサインアップしたのか簡単な質問をしてプロダクトのフォーカスを決めた

・ユーザービリティテスト
　大きな質問を２，３する。
　スクリプトを作る。
　オープンエンドな質問とクローズタスク
　　１．目的を説明
　　２．タスクごとにコンテキストを設定する
　　３．すべて声に出す（だまったら質問する）
　　４．できるだけメモをとる
　以上を短時間でとにかく多くやる

・カードソーティング
　ラベルやカテゴリを決める前にやるといい（初期でやること）

メール配信と分析　Taylor Wakefield (MailGun)

今でもe-mailの利用は圧倒的に多い。だけど９０％はスパム。
e-mailの内容はhtmlのみはだめで、画像はデフォルトで消される場合が多い
textは短すぎてもだめで、ストーリー性が必要。
トラフィックが集中しすぎるとスパム判定されるので注意が必要。

パネルディスカッション

データだけでは局所的な最適解になってしまう。
もちろんクリエイティビティが必要。

iOSでGHUnitでテストする【環境構築】

GHUnitの環境構築方法です。

環境：Xcode4.3.2

STEP1. プロジェクトの作成

適当にTestGHUnitというプロジェクトを作ります。

STEP2. GHUnitの取得

２つの方法があります。git使っている人や男気があるひとは後者を使うといいと思います。

方法その１．
ビルドされてるのをそのまんまつかう。

https://github.com/gabriel/gh-unit/downloads　からGHUnitIOS ***.zipをダウンロードしてくる。（上のほうの新しいやつのほうがいいと思います. 0.5.2で確認）

解凍するとGHUnitIOS.frameworkというフォルダができているので
プロジェクト内のフォルダに保存。

ここではTestGHUnitの下にFrameworksというフォルダを作成してその中に入れておきます。

TestGHUnit/Frameworks/GHUnitIOS.framework

方法その２．
githubからソースコードをとってきて、自らビルドする。
メリットとしてはgitですぐに最新版にアップデートできる点。

$ cd TestGHUnit/
$ ls
TestGHUnit TestGHUnit.xcodeproj TestGHUnitTests
$ mkdir Frameworks
$ cd Frameworks
$ git submodule add https://github.com/gabriel/gh-unit.git
Cloning into gh-unit...
remote: Counting objects: 7028, done.
remote: Compressing objects: 100% (2426/2426), done.
remote: Total 7028 (delta 4687), reused 6667 (delta 4360)
Receiving objects: 100% (7028/7028), 39.60 MiB | 268 KiB/s, done.
Resolving deltas: 100% (4687/4687), done.
$ cd gh-unit/Project-iOS

makeします

$ make

makeしたら以下のようなエラーがでる場合があります。

Error: No developer directory found at /Developer. Run /usr/bin/xcode-select to update the developer directory path.

Xcode4.3からXcodeのパスが変わっているためxcode-selectで/Developerのほうを見に行ってミスっている

$ sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

で治る

STEP3. ビルドセッティング

まずテスト用のターゲットを追加します。

プロジェクトセッティング画面を開いて左下のAddTargetボタンを押し、EmptyApplicationを選びます。

ProjectNameを適当にUnitTestなどとします。

Use Core Dataや　Include Unit Tests などにはチェックいりません。

次にTARGETSのな家から作成したUnitTestを選択し、BuildPhasesの画面を出します。

Link Binary With Librariesのセクションを開き下の＋ボタンを押してフレームワークを追加します。

下のAdd Otherを選択します。

ビルドしたものをダウンロードした場合はTestGHUnit/Frameworks/GHUnitIOS.frameworkのフォルダを選択してOpenを押す。

自前でビルドした場合は、gh-unit/Project-iOS/build/Framework/GHUnitIOS.frameworkを選択。

そうするとこうなるはず。

もしも別の表記になっていたり、アイコンが違ったりしたら - ボタンを押して一回消してから上のをやり直すと治ったりします。

次にBuild Settingを開き、Other Linker Flagに -ObjC -all_load を追加します。

これでテストを書けば動く状態になっているはずです。

STEP4.　テスト

UnitTestのフォルダ内のAppDelegate.h(ここではYYAppDelegate.h)を消します。

そしてYYAppDelegate.m を以下のように変更

#import <GHUnitIOS/GHUnit.h>

@interface MyTest : GHTestCase {   

}

@end

@implementation MyTest

- (void)testStrings {

    NSString *string1 = @"a string";

    GHTestLog(@"I can log to the GHUnit test console: %@", string1);

    

    // Assert string1 is not NULL, with no custom error description

    GHAssertNotNULL(string1, nil);

    

    // Assert equal objects, add custom error description

    NSString *string2 = @"a string";

    GHAssertEqualObjects(string1, string2, @"A custom error message. string1 should be equal to: %@.", string2);

    GHAssertEquals(1, 1, @"test");

}

- (void)testNums {

    GHAssertEquals(1, 2, @"test");

}

@end

main.m を以下のように修正

        return UIApplicationMain(argc, argv, nil, @"GHUnitIOSAppDelegate");

そしてテストを実行。

UnitTestのiPhone Simulatorを選んで、　Runボタンを押せば完了です。

iOSでKiwiでテストする【環境構築】

Kiwiのドキュメントや他のサイトでも手順があったわけですが、そのままだとちょっとうまくいかなかったのでまとめておきます。(具体的にはKiwi.hのパスを通すところ）

　　環境　：　iOS4.3.2
　　Kiwi　：　 commit 04bf281d35f4cee2c763bfca5c196fdb75b28b36

まず適当にプロジェクト（TestKiwi）を作成します。（SingleViewApplication）

include Unit Testsにはチェックを入れておきます

プロジェクトの作成が終わったら、Cmd + Uでテストを実行すると失敗しますがこれでOKです。（テストでひっかかっているところはとりあえずコメントアウトしておきます）

次にKiwiを取得します。手動でダウンロードしてきてもいいですが、Kiwiが更新されたときの同期を楽にするためにgit submoduleを使っておきます。

$ cd TestKiwi

$ ls

TestKiwi TestKiwi.xcodeproj TestKiwiTests

$ mkdir Frameworks

$ git submodule add https://github.com/allending/Kiwi.git Frameworks/Kiwi

Cloning into Frameworks/Kiwi...

remote: Counting objects: 1627, done.

remote: Compressing objects: 100% (556/556), done.

remote: Total 1627 (delta 1035), reused 1592 (delta 1010)

Receiving objects: 100% (1627/1627), 12.65 MiB | 297 KiB/s, done.

Resolving deltas: 100% (1035/1035), done.

$ ls Frameworks/Kiwi/

Classes Kiwi.podspec Other Sources Templates

Examples Kiwi.xcodeproj Readme.md Tests

Kiwi License.txt Resources install-templates.sh

下記コマンドでKiwiのディレクトリを開いてKiwi.xcodeprojをどラックランドドロップでXcodeの左の枠内のTestKiwiTestsのディレクトリに持っていきます。

$ open Frameworks/Kiwi

そうすると下のようになるので、Kiwiのテスト用のファイルを追加していきます。

中身が空のObjective-Cのファイルを作りたいのでEmptyで作ります。

適当にKiwiSpec.mという名前で作成します。（写真では.mが抜けているので注意）

下のTargetにTestKiwiTestsがチェックされていることを確認。

KiwiSpec.mに#import "Kiwi.h"　を記載して、Cmd + U を実行するとエラーがでます。

Build SettingのHeader Search PathにFramework/Kiwiを追加

再びCmd + U でまだエラーがでます。

HeaderSearchPathに Frameworks/Kiwi/Classes　を追加

これでめでたくビルドが通ります。

KiwiSpec.hにテストコードを記載し、Cmd + Uするとまたたくさんエラーが。

まずProjectの設定画面をひらいてTargetのTestKiwiTestsを選択し、Build PhasesのTarget DependenciesにKiwiを追加します。

Link Binary With LibrariesにlibKiwi.aを追加。

 そしてBuid Settingsに移動して、 Other Linker Flagsに -all_load を追加。

 これで　Cmd + U でビルドが通るはずです。

UITableViewのcellForRowAtIndexPathのテンプレ

全部同じCellの場合はこれでOK。
Cellによって配置とか構成を変える場合は、別のCellIdentifierを用意する。

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    // See if there's an existing cell we can reuse
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Foobar"];
    if (cell == nil) {
        // No cell to reuse => create a new one
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Foobar"] autorelease];

        // Initialize cell
        cell.selectionStyle = UITableViewCellSelectionStyleBlue;
        cell.textLabel.textColor = [UIColor blueColor];
        // TODO: Any other initialization that applies to all cells of this type.
        //       (Possibly create and add subviews, assign tags, etc.)
    }

    // Customize cell
    cell.textLabel.text = [NSString stringWithFormat:@"Row: %d", indexPath.row];
    // TODO: Any other customization
    //       (Possibly look up subviews by tag and populate based on indexPath.)

    return cell;
}