Category Archives: Objective-c

iOS/Macのライブラリ管理に利用できるツールのCocoaPodsを使ったプロジェクトをJetBrains製のIDEのAppCodeで扱える様になりました。

利用できるようになったのはAppCode 1.6 EAP (build #120.38)からなので、まだ安定版(現在は1.5)ではworkspaceを開くときにXMLパースエラーとなって利用できません。
これでやっとAppCodeとXcodeどちらも、CocoaPodsを使ったプロジェクトが扱えるようになったので、ライブラリの管理はCocoaPodsを使っていくのがいいかもしれないですね。

Skitch

AppCode 1.6では補完やファイル/クラス/シンボル移動等が賢くなったり、リファクタリング系の機能も強化されています。
また、今日からライオンでも使える!Xcode4.4 Modern Objective-C Syntaxでコードをきれいにする方法 | Zero4Racer PRO Developer’s Blogで紹介されてるような、
Objective-C の追加されたリテラル記法も既にサポートされていたり、他のJetbrains製IDEからは結構遅れてますがやっとGithubプラグインがサポートされました。

OCUnit系のテストもCmd+Alt+RでSchemeを選んで(テストの場合はテストクラス/ケース毎に自動で作れる)実行できるので、
テストの実行も結構手早く出来るようになってます。(1.5からだった気もしますが、Schemeの切り替えは速くなるそうです)

Skitched 20120731 221903

テスト結果の表示はXcodeより見やすいような気がします。

色々とAppCode1.6では便利になってるので、まだ安定版ではありませんが試してみるのもいいかもしれないですね。
(ちなみに日本語等がパスに含まれてるとビルドできないバグが1.6にはあります。 Build: cannot build program with Japanese characters in path : OC-4799)

EAPビルドは下記からダウンロードできます。

—–7月5日追記—–
たくさんの”解けた!”連絡ありがとうございました!
お陰様で、先着5名様についてはすぐに埋まってしまいました。
(該当の方には別途ご連絡いたします)
採用へのご応募と、解けたかどうかの確認については引き続き受け付けておりますので、
是非チャレンジしてみてください。

また機会をみて開催させていただきます!
ご興味を持っていただき、ありがとうございました。
———-

みなさんこんにちは!
 
株式会社プラスアールではiOS/android問わずスマートフォンアプリ開発エンジニアを募集しています。
 
ただ単に募集をかけてもあまり面白くないので、
今回は特別に、下の問題を解けた方の書類選考を無しにいたします!
かつ、オフィスすぐそばにある野田岩のうなぎ(ランチ)をごちそういたします!
 
  
応募以外の方でも、
問題が解けた&ランチ時間帯に赤羽橋まで来ていただけるようでしたら、
野田岩のうなぎをごちそういたします。(応募以外の方は先着5名様まで)
 
 
是非チャレンジしてみてください。

[問題]
 
7×7のマス目上にチェスのコマであるクイーン(将棋の飛車と角を合わせた動き)をお互いが取り合う事のないように出来る限りの数置くことを考えます。下図のように既に2つのクイーン(♕)が置かれているとき、どのように置けばいいでしょうか?
クイーンの動き方
 
クイーンを置くべき座標(x,y)の積k(=x*y)が小さい順にアルファベットを並べるとある単語が完成します。

解けた方は次のメールアドレスまでご連絡ください!
[完成した単語]-[kの合計値]@plusr.co.jp
※[]は要りません。
 
応募以外でも、”解けた!”というご連絡だけでも構いません。
応募ではなくうなぎだけ希望の場合はその旨ご記載ください。
例:「うなぎ食べたい」
 
よろしくお願いいたします!
※応募の期限は有りません。

iOSアプリ(Objective-C)を書き始めて半年たったので、それまでに触ったりした開発ツールやObjective-Cのライブラリなどについてまとめてみる。

開発ツール

AppCode

個人的にはXcodeより好きなので、コードを書く時は基本的にAppCodeで書いていた。
デバッガー周りやエラー表示についてはXcodeの方いいところが多いので、Xcodeも併用する。(どっちにしてもxibやData ModelをいじるときにはXcodeが必要な気がするので両方共起動してる事が多かった)
AppCodeはリファクタリングやXcodeでAnalyzeとかしなくてもメモリ解放忘れとかわかるのと、Quick fix(Alt+Return)がすごく便利なので書くときにリズムを生むのに役立った。
WebStormも使っているので同じ系統のIDEに慣れているのもあるけど、JavaScript書いてる時よりObjective-C書いてる時のほうがIDEの機能を色々使った気がする。

どちらのIDEでもComplete Current Statementの機能はものすごく便利。

Ingredients :: Cocoa Documentation Viewer

Appleドキュメント形式のドキュメントビューアー。
そこまで使わなかったけど(ググる癖があったので)、Appleのデベロッパーサイトは好きじゃないので、ドキュメントビューアーで見られると便利だった。
日本語リファレンス – 福井高専IT研究会OfficialWiki もリファレンス的に便利。 
(JSReference でさりげなく両方共検索できるようにしている)

TestFlight

TestFlightでテスターにアプリをインストールしてもらっているので、これが無いと面倒くさすぎて辛い。
TestFlightの使い方と導入方法 で使い方とかまとめた。

その他

ライブラリ関係

ShareKit

Twitterに投稿する機能をつけるときに利用した。
そろそろiOS5とかにちゃんと対応したShareKit/ShareKit – GitHub 2.0が出るそうです。

ASIHTTPRequest

大抵のことができる通信ライブラリ。
[request release]; – All-Seeing Interactiveで開発終了宣言されてしまった…
(まだPull Requestのマージはやってるみたいだけど)

SVProgressHUD

ローディングとかのHUDを表示するライブラリ。
クラスメソッドで簡単に実行できるので便利。
ソースコードも読んで面白かった。

まあ似たようなものはいっぱいあるけど。

magicalpanda/MagicalRecord – GitHub

CoreDataをActiveRecord風に扱えるMagicalRecordの使い方 | Technology-Gymで使い方を書いた。
MagicalRecordを使い出してからCoreDataへの恐怖心は大分和らいだ。
正直CoreDataをそのまま触りたくは無い気がする。

JSONKit

plistでデータ持たせるよりJSONでデータ持たせるタイプ

GHUnit

iOSのテストフレームワーク。

等テストフレームワークについて色々書いたけど、今のところ安定して使えるGHUnitでテストを書いてる。

他 iPad

  • MGSplitViewController
    iPadのSplitViewControllerの代わりに使った。
    更新されてない+バグがいくつかあるので、forkしたものを使ったほうがよいのかもしれない。
    ARC対応してないけど2人でコミットしてる感じ http://t.co/COqXQY0y ARC対応とバグのパッチとかも取り込んでる感じ http://t.co/zONq3Biv ARC対応only http://t.co/fdfZkHZq
  • ATPagingView
    横にTableVewを並べたくなったので利用した。
    NavigationController内で使うと何かおかしな気がする…

ドキュメント

ドキュメントというほどドキュメントじゃないけど、作図とかスクリーンショット系のソフトウェア
正直iOS関係ない…

Skitch – Annotate, edit and share your screenshots and images…fast.

SkitchはGyazoに編集機能が追加された感じにスクリーンショットを気軽に貼付けできるので便利。
正直今はGyazoよりいいものになってる気がする。
設定でDirect linkをクリップボードに入れるようにすると便利になる。

Preferences

OmniGraffle

フローとかそういう図をかきながら整理するのに使える。
画像も簡単に入れられるのがいいところ。

blockdiag

テキストからブロック図を生成するツール。
エディタで図の元になるものを書くわけだけど、quickrun.vimでblockdiagのプレビューする | MemeTodoみたいな感じでプレビューしながら書いてた気がする。(不完全なので誰かがもっと良い方法をやってるはず)

redmineのwiki

redmineのWikiにとりあえず簡単なドキュメントとか書いたりするけど、正直redmineはあんまり好きじゃないです。

ATOK Pad

Skypeで書いてる時に、ATOK Padにとりあえず書いてからまとめてポストするために使ってる事が多い。

他の他

Stack Overflow

無いと結構厳しいですね。
iOS関係だとGoogle以上に優秀な感じがします。

GitHub

ライブラリ探すのにGithubを検索することは多い。
Google Code Search並の検索ができるようになるといいのだけど。

おわり

とりあえず色々使っていたソフトウェア等を書きだしてみた。
他の人の環境に興味があるので、2月だし他の人も書いてみるといいと思います。

ビルド -> Runあたりに何か無駄な時間が多いので、KIFやUI Automationなどの自動化やビルド周りを色々やっていきたい所。

前回のcedarに引き続き、BDDスタイルのiOSテスティングフレームワークのKiwiについての紹介。

Kiwiについては以下のサイトがとてもよくまとめてくれているので、そこを見るだけでもいい気がしますが、
最近になってKiwiの導入方法等も変わったので、新しくなったKiwiの導入方法についてです。
どちらにしても下記のサイトは参考になるのでKiwiを使うには読んでおくべきでしょう。

公式にもインストール方法のページGuide: Up and Running with Kiwi – GitHubがあるので、そちらも読むといいです。
とても細かくかいてあります。(絶対パスで指定したりする部分があるのが微妙ですが)

今回作成したサンプルプロジェクトは以下に置いてあります

まずはOCUnit環境の構築から始めます。(既にその環境ができてるなら飛ばしても大丈夫です)
ちょっと詳しくは知りませんが、OCUnit環境の上にKiwiの環境を重ねて作るというようなイメージで。

プロジェクトの作成

NewImage

既にできてるプロジェクトに追加する場合は、途中からOCUnitを追加するのと同じでtargetにTest bundleを加えてやればいい。とりあえずここまでやればOCUnitのテストはできてる状態。

NewImage

手動でターゲットにTest Bundleから追加した時はSchemeにそのターゲットのSchemeが追加されるが、
メインとなってるSchemeを選んでいるときにもTestを実行できるようにするには、メインSchemeの編集で、
Testの部分にTestターゲットを関連付けすればメインSchemeからTestを実行できるようになる。(プロジェクト作成でInclude Unit Testした場合はこれが自動で行われている)

NewImage

ここからがKiwiの導入

まずはKiwiを入れたいプロジェクトがあるディレクトリまでコンソールで移動しておく


➜  KiwiSample git:(master) ls
KiwiSample           KiwiSample.xcodeproj KiwiSampleTests
➜  KiwiSample git:(master) git submodule add https://github.com/allending/Kiwi.git Kiwi
Cloning into Kiwi...
remote: Counting objects: 1305, done.
remote: Compressing objects: 100% (453/453), done.
remote: Total 1305 (delta 821), reused 1288 (delta 807)
Receiving objects: 100% (1305/1305), 12.59 MiB | 1.19 MiB/s, done.
Resolving deltas: 100% (821/821), done.
➜  KiwiSample git:(master)ls                                                                                                                              [~/Dropbox/workspace/iOS/project/KiwiSample]
Kiwi                 KiwiSample           KiwiSample.xcodeproj KiwiSampleTests
➜  KiwiSample git:(master)git submodule update --init # Kiwiをアップデートしておく                                                                                         [~/Dropbox/workspace/iOS/project/KiwiSample]
Submodule 'Kiwi' (https://github.com/allending/Kiwi.git) registered for path 'Kiwi'
➜  KiwiSample git:(master) ✗ open Kiwi                                                                                                                       [~/Dropbox/workspace/iOS/project/KiwiSample]

このようにして、Kiwiをプロジェクトのgitサブモジュールとして追加しておきます。(まだプロジェクト自体には入っていない)こうしておけば、以降はgit submodule updateとかでKiwiがアップデートできるようになると思います。

そして、最後にopen KiwiでKiwiディレクトリを開くと、Kiwi.xcodeprojがあるので、それをプロジェクトに追加します。

NewImage

 

Kiwiの導入 – 設定

まずはのBuild Phasesタブ設定から

そして、プロジェクトに作ったテストターゲット(画面ではKiwiSampleTest)のBuild Phases -> Target Dependiciesから先ほど追加したKiwiを依存関係に加えておきます。

NewImage

NewImage

次に、同じくテストターゲットのBuild Phase->Link Binary With LibraiesからWorkspaceにあるlibKiwi.aを追加します。

NewImage

次はBuild Settingタブ

テストターゲットのBuild Setting -> “User Header Search Paths”に、追加したKiwi.xcodeproj内のソースを参照するように、Kiwi/Kiwi とパスを追加します。

NewImage

最後にテストターゲットのBuild Setting -> “Other Linker Flags“におなじみの-all_loadを追加します。

NewImage

これで、Kiwiの準備は完了で後はテストケースを書いていくだけです。
KiwiSampleTests.m という次のようなファイルをテストターゲットに追加していけばテストケースを書いていけます。


#import "Kiwi.h"

SPEC_BEGIN(MathSpec)

describe(@"Math", ^{
    it(@"is pretty cool", ^{
        NSUInteger a = 21;
        NSUInteger b = 21;
        [[theValue(a + b) should] equal:theValue(42)];
    });
});

SPEC_END

Kiwiのいい所はデフォルトでOCUnitと同じようにTestからテストを実行できるようなっている所。

NewImage

KiwiはBlocksを使ったBDDライクな書き方ができようになっていて、この辺はCedarと同じです。(語弊ありますが)
また、Kiwi自体にMockとStubの機能が含まれていたりするようです。

Kiwiについてのドキュメントですが、以前はkiwi-lib.infoがあってそこにまとまっていましたが、今はKiwi WikiというGithub上に集めているみたいなので(まだ未完成なのでドキュメントが行方不明です…)、そちらを参照するのがいいでしょう。

一応まだサイト上には過去のドキュメントが残ってるのでそれを見るのがいいかも。

導入方法の参考

おまけ

自分はAppCodeを普段使っているので、TestをAppCodeで走らせたいと思います。

Edit Configuration から OCUnitとしてターゲット:KiwiSampleTestsを指定します。

NewImage

そして、Configを作ったOCunit(画面だとKiwiTest)に切り替えて実行するとテストが実行できます。
(#import “Kiwi.h”でWarningが出てしまいますが、ちゃんと動作します)
OCUnitをAppCodeで実行するのと同じでグリーン、レッドバーで結果が表示されます。

NewImage

補完とか整形が若干おかしいのが残念ですが、構文自体は結構好きです。

 

cedarJasmineRobolectric 等他の言語でもテスティングフレームワークを色々と作成しているPivotal Labs.によるObjective-C向けのBDDテスティングフレームワークです。

今回は適当な導入方法について

まずはCedar-iOS static frameworkをビルドするために、Githubからcedarをcloneします。

➜  objectiveC  git clone --recursive https://github.com/pivotal/cedar.git

submoduleも含めて持ってきたいので–recursiveオプションでまとめてcloneします。

ダウンロードしたプロジェクトをXCodeで開く

➜  objectiveC  open cedar/Cedar.xcodeproj

NewImage

NewImage

ビルドすると、ProductsディレクトリにiPhoneUniversalのディレクトリがあるので、そこからcedar-iOS.frameworkを取り出しておく。
(イマイチ簡単にProductsディレクトリを開く方法がわからなかったので、cedar.frameworkをShow In Finderするなどして辿った)

プロジェクトに組み込む

GHUnitのようにアプリケーションとして動作させるので、プロジェクト作成時にInclude Unit Testはチェックしなくていい。
適当なプロジェクト名でEmpty Applicationなどを選んでプロジェクトを作成する。

次にテスト用のTargetを追加する。
add Targetから”UISpecs”というような名前をつけたTargetを追加する。
(この時Unit Test Bundleではなくアプリケーションから選ぶ、今回はEmpty Application)

NewImage

Target UISpecsの方に対して、先程ビルドしたcedar-iOS.frameworkを追加する。

NewImage

Target UISpecsのBuild SettingのOther Linker Flagsに対して-ObjC と -all_load を追加する

NewImage

最後にmain.mの書き換えを行う。
CedarApplicationDelegateを見に行くように書き換える(元々あるAppDelegateは消しても問題ない)

#import <UIKit/UIKit.h>
#import <Cedar-iOS/Cedar-iOS.h>

int main(int argc, char *argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    int retVal = UIApplicationMain(argc, argv, nil, @"CedarApplicationDelegate");
    [pool release];
    return retVal;
}

この状態になったら多分Runから起動できるようになる。
GHUnitと同じようにアプリケーションとして起動して、テスト毎にUITableViewで表示するような形になっている。

次はテストケースを書いてみる。
TestSample.mみたいな適当なクラスを追加する。

#import <Cedar-iOS/SpecHelper.h>

SPEC_BEGIN(FooSpecs)

describe(@"Something that shares behavior", ^{
    itShouldBehaveLike(@"a similarly-behaving thing");
});

describe(@"Something else that shares behavior", ^{
    itShouldBehaveLike(@"a similarly-behaving thing");
});

SPEC_END

実行してみると次のようにTableViewにグリーン、レッドが表示される

NewImage

 

これで、アプリケーションテストのために導入する方法は終わりなのだが、
cedarには C++ templatesを利用したMatchersというメソッドの書き方のセットが用意されていて、
それを利用するためにはObjective-C++でテストケースを書けるようにする必要がある。

先ほどの状態のままテストケースの書き方を少し変更するだけで Matchers の機能が利用できるようになる。
まずは、拡張子を.mmにしたTestSample.mmという感じにして次のようなファイルを作成する。

#import <Cedar-iOS/SpecHelper.h>

using namespace Cedar::Matchers;

SPEC_BEGIN(FooSpecs)

describe@"a similarly-behaving thing", ^{
    it(@"should do something common", ^{
        NSString *aString = @"something";
        expect(aString).to(equal(@"something"));
    });
});

describe(@"1 + 2", ^{
    it(@"should be 3", ^{
        1 + 2 should equal(3);
    });
});

SPEC_END

このようにusing namespace Cedar::Matchers;を入れることでMatchersを使ったテストケースを書けるようになる。
1 + 2 should equal(3); のように書けたりするので便利な気がする。

メソッドについては pivotal/cedar – GitHubを見る。

まとめると次のような変更を行えばいい。

  • 拡張子を.mmへ変更
  • using namespace Cedar::Matchers; をSPEC_BEGINの前に入れる

今回書いたサンプルはazu/Cedar-sample – GitHubに置いてあります

ものすごく簡略化した導入方法を紹介したが、Cedarはかなり色々な事ができるように作られてるようなので、今回の内容はごくごく一部な気がします。
OCUnit Logic Tests というように アプリケーションとしてではなくてOCUnitみたいにメニューのTestからテストできるようにもできたり、
標準でJUnit XMLレポートを出力できるなど 色々と奥が深そうです。