A-Liaison BLOG

また誰得な妄想ネタですみません＞＜

突然ですが、Objective-Cでパターンマッチがやりたいんです。MLだとかOCamlだとかScalaだとかみたいに。
MLの例: http://kktoppa.web.fc2.com/smlnj4.html
OCamlの例: http://www.geocities.jp/m_hiroi/func/ocaml04.html

パターンマッチがないせいで、StoryboardでSegueを使ったとき、こんな何かの冗談みたいなコードを書かなくちゃいけないんです。

見ての通り、大学時代に恩師が「アホのn段重ね」と読んでいたif~elseの重ね技です。これ以外に方法がないんです。

だからこういうコードが書きたいんです。厳密には関数型言語のパターンマッチと違う気がしますしなんか色々とメチャクチャな文法になってますが、だいたいなんかこんな感じのコードが。

しかし残念ながらObjective-C (CでもC++でもいいですけど) の文法を捻じ曲げるのは極めて難しいです。

Rubyならこんな感じでパターンマッチを実現するライブラリがあるみたいです。素敵ですね。
http://www.callcc.net/diary/20120303.html
https://github.com/k-tsj/pattern-match

というわけで今日もアホのn段重ねでSegueを使おうと思います＼(^o^)／

iOS 6も発表されて、皆さんARCやBlocksをガンガン使用する感じのプログラミングスタイルに変化してきていると思うのですが、そこで問題になってくるのが後方互換性の話です。特にiOS 4。Blocksを使うとなるとどうしても以下の様に非同期で実行されたBlocksの中からViewを書き換えるようなコードを書きたくなるのですが、

__weak MyViewController *__weakSelf = self;
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse* response, NSData* data, NSError* error){
 __weakSelf.label.text = [[NSString alloc] initWithData:data encoding:NSUTF8Encoding];
}];

このようなコードを安全に実行するためにはselfを一度__weakな変数に代入して、それをBlocksにキャプチャさせるようにしないと、以下のような理由で安全ではなくなってしまいます。

• __strongを使うと、対象の変数をキャプチャしているBlocksの実行が終わるまで対象の変数がreleaseされなくなるばかりか、最悪の場合は循環参照が発生してメモリが絶対に開放されなくなってしまいます。
• __unsafe_unretainedを使うと、Blocksの実行が終わるまでの間に対象の変数がreleaseされてしまうとEXC_BAD_ACCESSでクラッシュします。

しかしながらiOS 4では__weakが使えず、状況に応じて__strongや__unsafe_unretainedでごまかす必要があります。このようなときにiOS 5では__weakを使い、iOS 4やno-ARCなプロジェクトではそれなりに適切な何かを使って実装するような仕組みが欲しくなります。

そこで便利に使えるのが__has_feature(objc_arc_weak)と__has_feature(objc_arc)マクロです。こいつらを使うと簡単に現在のビルド環境・ターゲット環境がARCを導入しているか、weakは使用可能か、を判断できます。たとえば私は以下の様なマクロを組んで、

// ARC & memory management
// Use these prefixes to be compatible with ARC on iOS 5/ ARC on iOS 4.X / non-ARC
// 
#if __has_feature(objc_arc_weak) // iOS 5 or above
#define __my_block_weak __weak
#define __my_block_weak_unsafe __weak
#elif __has_feature(objc_arc) // iOS 4.X
#define __my_block_weak __strong
#define __my_block_weak_unsafe __unsafe_unretained
#else // iOS 3.X or non-ARC projects
#define __my_block_weak __strong
#define __my_block_weak_unsafe __block
#endif

こんな感じのコードにしてます。

__my_block_weak MyViewController *__weakSelf = self;
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse* response, NSData* data, NSError* error){
 __weakSelf.label.text = [[NSString alloc] initWithData:data encoding:NSUTF8Encoding];
}];

こうするとどの環境でも（比較的）安全にblocks内部でselfを触ることができるという寸法です。

ここで気になるのが__has_feature(objc_arc_weak)の判定条件です。個人的にこいつはiOS SDK 5.0以上を使っていたらターゲット環境がiOS 4とかiOS 3とかでも無条件で1を返してしまって使えないんじゃないのかと危惧していたのですが、なんとIPHONEOS_DEPLOYMENT_TARGETの値を見てきちんと値が変化する仕組みになっています！なので例えばSDKは最新だけれどiOS 3もサポートしたいみたいなプロジェクトでは__has_feature(objc_arc)の値が自動的に0になって良い感じに分岐してくれるというわけです。安心して使いまくりましょう！

非同期のテストができないのでGHUnitを使っていたのですが、やっぱりCmd+U一発で単体テストが走る便利さがいいなーと思い、ためしにSenTestingKitで非同期のテストができないかやってみたらできちゃったので公開します。

https://github.com/akisute/SenAsyncTestCase

ライセンスはMITライセンスとします。

使い方とか例とかはREADMEを見たりテストケースを見てみたりしていただければ一発でわかるかと思います。あ、もちろんSenTestingKit.frameworkが必要ですよ。

Twitterに流したら思ったよりも好評でしたので、ブログにも上げておきます。

こちらがiOS 2地点でのNSURLConnectionクラスを使った非同期通信のテストケース。

こちらがiOS 5でのNSURLConnectionクラスを使った非同期通信のテストケース。

Blocksはやっぱり偉大です。一つしかテストケースがないうちはまだマシなのですが、これが10個とかになると楽さが全く違ってきます。ぜひためしにURLだけ変えて同じテストケースを10個作ってみてください。iOS 5のBlocksを使ったコードはほとんどコピペだけで終わりますが、iOS 2でのdelegateを使ったコードは他にも変更しなければならない点が多数出てくるはずです。

また実際にこのコードを走らせてみると、理由はよくわからないのですがiOS 5で追加されたAPIを使ったコード（Blocks)のほうがそうでないコードよりも毎回2倍程度（0.1秒程度）高速に動作しているみたいです。ちょっと謎ですが、新しいAPIにはパフォーマンス面でのメリットもありそうです。GCDのおかげかな？

Cocoaフレームワークは非同期処理時のロックを取るために、NSLockingというプロトコルと、NSLock, NSRecurrsiveLock, そしてNSConditionalLockという3種類のロックの実装を提供しています。が、残念ながらちょっとまともな非同期コードを書こうと思うとこれでは全然足りません。っていうか、NSConditionalLockがロック抜けるときにしか条件値を書き換えられない実装なのが正直いけてないと思います。これじゃCounting Lock（最初に決めた数だけ同時にロックできるロック。Counting Semaphoreともいう）にもRead/Write Lock（書き込みロックと読み込みロックの二種類が用意され、書き込みロックが取られていない限りは、何個でも同時に読み込みロックが取れる、効率のいいロック）にも使えません。というわけで、Objective-Cで書かれたCounting LockとRead/Write Lockを見つけましたのでご紹介いたします。

http://cocoaheads.byu.edu/wiki/locks

中身はpthread.hのpthread_mutexを使って実装しているようです。一見危なそうですが、Cocoaフレームワークが使用するスレッドは全て内部実装がpthreadなので全く問題ありません。

ぼちぼちTwitterにつぶやいていたらTogetterにまとめてくださった方がいらっしゃるので、せっかくなのでこちらでも紹介したいと思います。

http://togetter.com/li/189550 （githubみたいにembedできればいいのになーなんて＞＜）

結構気合い入れて調べたのでおすすめです。

■2012年11月11日追記
iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.com/questions/11836225/ios6-udid-what-advantages-does-identifierforvendor-have-over-identifierforadve が一番詳細かなと思います。
追記終


つい先日TechCrunchがiOS5よりUDIDの使用が非推奨になると報道し、巷はiOSでのUDIDの使用についての話題で俄然盛り上がっています。セキュリティ的によろしくないから良い変更だという声もあれば、すでに認証用として使っていてシステム改修が必要という悲観の声もあります。しかし私はどちらかというとUDIDをバリバリ使っちゃってる方陣営の人なので、セキュリティの問題については知っていても、やはりUDID相当の物が無いと不便だなぁと思ってしまうのです。そこでプログラマらしくコードで解決することにしました。

UDIDにはセキュリティの懸念があるし、もう使えなくなる。だったらもっといいIDを超簡単に生成して使えるようにすればいいじゃない。ということでUnique Installation Identifier (インストール毎ID、UIID) を生成するライブラリを早速書いてみました。
ソースコードはこちら。MITライセンスです。
https://github.com/akisute/UIApplication-UIID
昔のgistはこちら

使い方は超簡単で、

1. アプリが一度削除されたとしても同一のUIIDを返すようにしたいのであれば、#define UIID_PERSISTENT=1して、Security.frameworkをプロジェクトに追加する
2. UIApplication+UIID.hをimport
3. [[UIApplication sharedApplication] uniqueInstallationIdentifier]で取れます

はいこれだけです。


■そもそもどうしてUDIDを使うのか

たいていの場合は以下のような理由です。

• ログイン機構なしに簡易にユーザーの識別をしたいときに、毎回同じ値を返し、かつユーザー事に異なる値が取得出来る何かが必要になるので、UDIDを使う
• UDID値の取得がいつでもどこでも可能、さらに超簡単で外部ライブラリのインストールなど面倒なことが一切無い
• しかもAppleのドキュメントにそう使えって書いてある。・・・補足すると使ってもいいよ、ぐらいのニュアンスで、使えという風に推奨はしてないみたいです＞＜ またUDIDのみをキーとしてユーザー情報を保存するな、とも書いてますね。

■UDIDは何がまずいの

主にまずい理由はセキュリティです。特にガラケーのかんたんログインの問題が参考になるのですが、iOSの場合は以下のようなセキュリティ問題が発生します。

• 相手のUDIDがわかってしまえば、簡単になりすましが可能
• UDIDの値を返すメソッドの実装を差し替えて、任意の値を返すように出来る。JailBreakしているユーザーであれば誰でも簡単に実行可能、そのためのアプリもCydiaで検索すれば転がっている
• UDID自体、様々な方法で取得可能。アプリをインストールさせてそこ経由で集めてみたりはもちろん（その際値を取得することに対する警告すら出ない）、iTunesからでも値を確認できる
• 上記三つの理由のため、その気になればたやすく任意のユーザーになりすませる
• さらに恐ろしいことにUDIDは端末事に一意になるため、一度値が特定されてしまうと端末を買い換えない限りずっとなりすまされてしまう、リセットできない

■UIIDだとどうなる

Unique Installation Identifier, UIIDはUDIDと異なり「アプリのインストール基盤毎」に一意な値を返すような実装になっています。簡単にまとめると、あるアプリAが、デバイス1, 2, 3にインストールされた場合、UIIDは1, 2, 3の全てで異なる値になります。ここまではUDIDと同じですが、UDIDと違うのはデバイス1に別々のアプリA, B, Cがインストールされた場合、それぞれ異なる値になります。中身は単にCFUUIDというiOSに元からある良くできたID生成ルーチンなんですが、これにより以下のようなメリットが得られます。

• 外部からIDの値を取得するのが困難。推測も十分に長い上に独立な値なため困難、取得も（UIID_PERSISTENT=1でビルドすればKeychainを使うので）困難です。
• 万が一何かの間違いで流出したとしても、アプリごとに異なる値になるため他のアプリのセキュリティが犯されたりはしない。また同様の理由で他の悪意のあるアプリからUIIDを取得して攻撃することもできない。
• プログラム的にUIIDをリセット可能。UUID_PERSISTENT=0であればアプリを消せばユーザーが任意にリセット可能。
• Keychainを使ったメリットとして、ユーザーがデバイスを乗り換えてもiTunesのバックアップに値が保持されるため、それから復元を行った場合UIIDの値が引き継がれる。
• 通常のアプリであればUDIDを使っていたケースのほとんどはこのUIIDでそのまま代用可能、あとは過去のUDIDとUIIDのヒモ付だけサーバー側でやってしまえば完全に乗り換えられる
• それでもどうしてもデバイスごとに一意な値が欲しいならhttps://github.com/gekitz/UIDevice-with-UniqueIdentifier-for-iOS-5/blob/master/Classes/UIDevice+IdentifierAddition.mなど使えばよいのかなと。ただしこの実装はMACアドレスの値を使っているため、MACアドレスの値がわかってしまえばIDをたやすく生成可能で、UDIDの持つセキュリティ上の問題は残ります。

■使用上の注意

UDIDよりは問題が少ないですが、それでもこのUIIDだけで認証を行うような作りのアプリには間違ってもしないように！以下のような問題があります。

• そもそもこの値は完全にユーザーと一意にヒモ付いた値ではありません。UIIDはあくまでアプリのインストール単位とヒモ付いているだけです。複数のデバイスを一人のユーザーが所有していたりすると完全にアウトですし、インストールされた端末が譲与された場合も対応できません。
• プログラム的にUIIDはリセット可能なので最悪の場合でもずっとなりすまされるのは回避できるのですが、その際にヒモ付けられていたユーザー固有の情報が消えてしまいます。ログインIDとパスワードで認証をしているのであれば、ログインIDはそのままにしてパスワードだけをリセットすることで、なりすましの問題を解決しつつ、ユーザーの一意性は保ったままにできるため、万が一の際はログインIDとパスワードを使っている方が圧倒的に利便性が高まります。
• 以上の理由により、UIIDはあくまで簡易的・一時的にユーザー認証をする時に使用し（たとえばユーザーが購入したアプリ内課金の商品をアプリが消されるまでの間だけ履歴として持っておいたり、ゲームのランキング等で匿名だけれど点数ランキングに参加できるようにしたり）、正式で完全なサービスはログインIDとパスワードによって提供するべきです。そうすることで一人のユーザーが複数のデバイスでサービスを使えるようになります。さらにはAndroidとも連携できたりしますしお得です。

■っていうか

全部高木先生が一年前に言っている通りになっちゃってるじゃないすか！っていうか私が作った物もこの高木先生がおっしゃってる「アプリ専用の（セキュアな）独自IDを生成してそれを保存して使う」というものの実装にすぎません。しかしまったく、せっかく警告してもらっても、人間実際に問題に直面しなければなかなか手をつけないものですね＞＜

しかし、しかしですね、あえてここで一言、エンジニアとして申させていただきたい。

私、エンジニアが欲しいのはセキュリティ上正しい実装の方法だとか、概念だとか、ましてやどこそこのログイン方法はいけてないから直せや、などという文章でもないのです。我々が欲しいのは、「すでに実装されている、セキュリティ上正しくて、猿でも理解できて、1分で組み込めて、どのような環境でも動き、ユーザーが会員登録なんて面倒極まりないことをしなくても済むユーザー認証の手段」なんです。要するに、

// 何か良くわからんけどこのトークンをHTTPS経由でPOSTして認証しておけば超スーパー確実かつセキュアで猿でも実装できてハッピーになる
[[NSAuthentication sharedUser] authenticationToken]

↑コレが今すぐ欲しいんですよ、我々エンジニアというのは。そうすれば誰だってUDIDを使って認証するみたいな面倒くさいことするわけ無いじゃないですか。頼まれたってやりませんよ。

私はユーザー認証をしたいだけなんです、それも可能な限り楽に。口で何と批判しようが、正しい方法を教えようが、世の中は決して変わらないと思います。みんな楽をしたいから。なのでAppleには是非UDIDを廃止するこの機会にぜひ上記のような何かをUIKitなりFoundationなりに組み込んで欲しいですね。こういうところも、良いプラットフォーマーの責務の一部じゃないかなと。

Xcode 4.0 から LLVM が標準のコンパイラとなり、各種警告が非常に厳しくなっています。その中でも特に今回は文字列リテラルに 0円 が含まれているときの警告について回避策を発見したのでご紹介したいと思います。

Objective-C では文字列リテラルは @"abesi" のように @"" で囲んで表現します。このリテラルは（あくまで推測で確定ではないのですが）コンパイラによってコンパイル時に CFSTR("abesi") に置換され、 CFStringRef 型としてプログラム中に定義されているようです。さて問題はここからで、 Xcode 4.0 が内部的に構文解析のために使っている LLVM がこのリテラル中に 0円 、要するにNULL文字が含まれていると以下のような警告を出すようになってしまったのです

CFString literal contains NUL character

普通はNULL文字をリテラル中に含めたいということはまず無いのですが、SMTPの通信部分を書いたりしていると通信プロトコル自体が命令を 0円 で区切れみたいな要件を求めてくるため、どうしてもリテラルの中に 0円 を含めたいときが出てきます。 まぁ、具体的には以下のライブラリなんですけどね。

http://code.google.com/p/skpsmtpmessage/source/browse/trunk/SMTPSender/Classes/SKPSMTPMessage.m

sendState = kSKPSMTPWaitingAuthSuccess;
NSString *loginString = [NSString stringWithFormat:@"000円%@000円%@", login, pass];
NSString *authString = [NSString stringWithFormat:@"AUTH PLAIN %@\r\n", [[loginString dataUsingEncoding:NSUTF8StringEncoding] encodeBase64ForData]];
NSLog(@"C: %@", authString);
if (CFWriteStreamWriteFully((CFWriteStreamRef)outputStream, (const uint8_t *)[authString UTF8String], [authString lengthOfBytesUsingEncoding:NSUTF8StringEncoding]) < 0)
{
 error = [outputStream streamError];
 encounteredError = YES;
}
else
{
 [self startShortWatchdog];
}

そして私と同じライブラリの同じ箇所でぶつかった人を発見。

http://stackoverflow.com/questions/5814520/how-do-i-create-a-login-string-that-contains-2-embedded-nulls-and-the-login-an

さて回避方法はないものかと探してみたところ、ちょうど良い回避策が発見できました。

http://stackoverflow.com/questions/6211908/nsstring-with-0

NSStringのstringWithFormat:に %C を埋め込んで、そこに 0 を渡せばうまくいくみたいです！

int main() {
 NSString *string = [NSString stringWithFormat: @"Hello%CWorld!", 0];
 NSData *bytes = [string dataUsingEncoding: NSUTF8StringEncoding];
 NSLog(@"string: %@", string);
 NSLog(@"bytes: %@", bytes);
 return 0;
}

さっきの例だと、

sendState = kSKPSMTPWaitingAuthSuccess;
NSString *loginString = [NSString stringWithFormat:@"%C%@%C%@", 0, login, 0, pass];
NSString *authString = [NSString stringWithFormat:@"AUTH PLAIN %@\r\n", [[loginString dataUsingEncoding:NSUTF8StringEncoding] encodeBase64ForData]];
NSLog(@"C: %@", authString);
if (CFWriteStreamWriteFully((CFWriteStreamRef)outputStream, (const uint8_t *)[authString UTF8String], [authString lengthOfBytesUsingEncoding:NSUTF8StringEncoding]) < 0)
{
 error = [outputStream streamError];
 encounteredError = YES;
}
else
{
 [self startShortWatchdog];
}

このようにすればばっちり上手く回避できました！

よく外部のライブラリやFrameworkをiOSのプロジェクトに取り込むときに、つけないと動かないからつけてねと言われる、 Other Linker Flag = -ObjC -all_load のフラグ。これって何をやっているのか今までずっと気になっていたので、ちょっと調べてみました。

こういうことらしいです。
http://developer.apple.com/library/mac/#qa/qa1490/_index.html

This flag causes the linker to load every object file in the library that defines an Objective-C class or category. While this option will typically result in a larger executable (due to additional object code loaded into the application), it will allow the successful creation of effective Objective-C static libraries that contain categories on existing classes.

このフラグは、Objective-Cのクラスまたはカテゴリを定義しているライブラリに含まれる、全てのオブジェクトファイルをロードするようリンカに促します。これによってたいていの場合実行ファイルのサイズが大きくなってしまいますが（アプリに追加のオブジェクトコードが読み込まれるので）、既存のクラスに対するカテゴリを含むObjective-C静的ライブラリを正しく使えるようになります。

へぇぇ！全く知らなかったです。ちなみに -all_load はというと、

-all_load forces the linker to load all object files from every archive it sees, even those without Objective-C code. -force_load is available in Xcode 3.2 and later. It allows finer grain control of archive loading. Each -force_load option must be followed by a path to an archive, and every object file in that archive will be loaded.

-all_load は全てのオブジェクトファイルを全ての認識できる静的ライブラリ（アーカイブ）から全部ロードしてくる（意訳）

とかそういうことらしいです。なるほどねー。

ということは -all_load はより強力な -ObjC に見えますが、実際には -ObjC は -all_load と違って上記に記載されているオブジェクトファイルのロードの挙動変化以外にも何かやっているようで、実際 -all_load -ObjC 両方指定してあるとリンクできるのに、 -all_load だけではリンクが通らない場合がありました。なのでやっぱり必要なときはまず -ObjC だけを試してみて、それでも駄目なら両方設定するのがいいみたいですね。


余談ですが、上記の内容を調べていたとき、リンカとかローダについて詳しく学ぶには以下の本がよいとオススメしていただきました。

Linkers and Loaders (日本語訳版もありますが、訳がひどいので英語版の方がよいとのことです。ここでは日本語版のリンクはあえて紹介しません)
http://linker.iecc.com/



KindleかiBooksで欲しかったのですが、残念ながら紙の本しかないですね・・・＞＜

※2011年04月23日現在での情報です。以下の問題は全て Apple に対して報告いたしましたので、ひょっとしたら将来的に修正されるかもしれません。


現在の仕事にて課金情報を安全にアプリケーション内に保存したいということになり、それならばということで iOS に最初から用意されている Security.framework を使って Keychain 領域に情報を保存するアプリを作ることにしました。この Security.framework は全てC言語にて実装されており、そのまま使うと非常に取っつきづらいです。そこで、 Apple がサンプルコードとして提供している GenericKeychain プロジェクトの KeychainItemWrapper クラスを使って Keychain 領域にアクセスすることにしました。

最初は問題ないように見えたのですが、実はこの KeychainItemWrapper クラス、Version 1.2には深刻なバグがあります。それは、複数の KeychainItemWrapper クラスのインスタンスを使って複数の識別子を持った情報を保存しようとすると、同時に一種類しか保存できなくなる（二つめを保存しようとするとステータスコード25299が返却されて保存できなくなる）というものです。

原因を調査した結果、以下のページに記載されている内容が問題だとわかりました。
http://useyourloaf.com/blog/2010/3/29/simple-iphone-keychain-access.html

The combination of the final two attributes kSecAttrAccount and kSecAttrService should be set to something unique for this keychain. In this example I set the service name to a static string and reuse the identifier as the account name.

サンプルで提供されている KeychainItemWrapper クラスにはこれらの一意となるキーが指定されておらず、単に検索用の kSecAttrGeneric だけが指定されていたため、一意キーの指定がおかしくなって二つ目の Keychain アイテムが保存できなくなっていた、というわけです。

そこでこちらの問題を修正した KeychainItemWrapper クラスをご用意しました。
https://gist.github.com/938375

ライセンスは元となるAppleのオープンソースライセンスに準拠します。改変・再配布・利用すべて自由ですが、その際ソースコードの最上部にあるAppleのライセンス条項コードは絶対に改変しないでください。Apple先生に何か言われても私は知りませんよ＞＜


■修正版 KeychainItemWrapper の使い方

基本的には通常の KeychainItemWrapper と何ら変わりません。

// インスタンスを作る
KeychainItemWrapper *wrapper = [[KeychainItemWrapper alloc] initWithIdentifier:@"com.akisute.keychain.KeychainTestApp.item1"
 serviceName:@"com.akisute.KeychainTestApp"
 accessGroup:nil];

// 値を保存する
// いったんresetKeychainItemしているのはmyValueがnilのとき保存されているデータを削除したいから
// 基本的に値(kSecValueData)として保存できるのはUTF-8のNSStringのみです。内部的にNSDataに変換されてKeychainに保存されます。
// それ以外の情報を保存したい場合はすみませんが未対応です＞＜ Base64文字列にするとかJSON文字列にするとか工夫して回避してください＞＜
 NSString *myValue = @"abesi";
[wrapper resetKeychainItem];
[wrapper setObject:myValue forKey:(id)kSecValueData];

// 値を取り出す
NSString *resultValue = [wrapper objectForKey:(id)kSecValueData];
NSLog(@"resultvalue = %@", resultValue);

たまには技術ネタを書きます。 iOS で IPアドレスや MACアドレスを取得するためのObjective-Cクラスを書いてみました。
コードはこちら。

https://gist.github.com/662203

ライセンスは記載のとおりMITライセンスです。

参考にしたサイトはこちら。

http://stackoverflow.com/questions/677530/how-can-i-programmatically-get-the-mac-address-of-an-iphone
http://iphonesdksnippets.com/post/2009/09/07/Get-IP-address-of-iPhone.aspx


■ほんのちょっとだけ説明

BSDのioctl()関数を使いますと、デバイスのIO周りのありとあらゆる情報を取ってくる事ができます。・・・らしいです。それを使ってIPアドレスやMACアドレスを取ってみました。大本のコードは確か StackOverflow あたりにあったのですが、もろにC言語ベタベタだったので使いやすくするためObjective-Cのクラスにしています。といってもまだまだ改善点が山ほどありますので好き勝手に触りまくってください。

っていうか今気づいた、二番目のサイトそのまんまほとんど同じコードじゃないですか＞＜ 別にいまさら作らなくても良かったですね。

Twitterにメッセージを送信する際に、クライアント側でメッセージの長さを判定して画面に表示したいというような要件があると思います。当然、このような場合には入力されたメッセージを取ってきてその長さを求めてやれば良いのですが、どうやら UTF-8 などのマルチバイトな文字コードを使っていると文字列の長さを正確に求めるのが大変なようです。


■何がどう大変なのか

図を書いてみました。「文」が文字数、「b」がバイト数を表しています。 Objective-C の場合は、「文」が　``[NSString length]`` を、「b」が [NSString lengthOfBytesUsingEncoding:NSUTF8StringEncoding] を表します。ほかの言語の場合もそれぞれ相当するメソッドまたは関数が用意されていると思います。



上のケースが一般的な UTF-8 文字列です。この場合、バイト数はマルチバイトになってしまうため実際の文字数（我々人間が見て自然な文字数）とは一致しませんが、その代わり UTF-8 文字数が実際の文字数と一致するため問題なく長さを求めることができます。

面倒なのが下のケース。ウムラウト記号や濁点・半濁点が一文字として入力されてしまっている場合です。通常滅多にこのような文字列に遭遇することはないのですが、まれにこのような文字列を入力させる処理系があるようです。で、この場合はウムラウト記号や濁点・半濁点も一文字として認識されてしまうため、実際の文字数と文字列長判定メソッドが返す文字数が異なってきます。そこまで厳密にしなくてもよいのでは・・・と思ったのですが、なんと Twitter はきちんとこのような場合も自然な文字列の長さを測定して140文字かどうかを判断しているらしいです。


■対策：Normalizeする

このように実際の文字数と UTF-8 上の文字数が異なっている場合には、 Normalize と呼ばれる処理を行って文字を圧縮する必要があります。 Objective-C の場合には以下のようなメソッドが標準で用意されています。

// NFD
– (NSString *)decomposedStringWithCanonicalMapping

// NFKD
– (NSString *)decomposedStringWithCompatibilityMapping

// NFC
– (NSString *)precomposedStringWithCanonicalMapping

// NFKC
– (NSString *)precomposedStringWithCompatibilityMapping

これらのメソッドは、 Unicode 文字列をそれぞれ NFD, NFC, NFKD, NFKC と呼ばれるフォーマットの文字列に変換してくれます。それぞれの文字列がどのような表現を表しているかは、以下のページを参考にしてみてください。英語ですが図説がついてるので非常にわかりやすいです。
http://unicode.org/reports/tr15/
http://homepage1.nifty.com/nomenclator/unicode/normalization.htm

ほかの言語、たとえばPythonやRubyなどでこの機能が提供されているかどうかはわかりません。あしからず・・・＞＜

前回記載できなかったエラーハンドリングについて軽くさわってみました。


■libHaruのエラーハンドリング
http://libharu.org/wiki/Documentation/Error_handlingに詳しく書いてあります。要するに、一番最初のPDFドキュメントを生成するところでエラーハンドラ関数を渡したらあとはエラーが発生するたびにその関数が呼び出されるみたいです。

// まずはヘッダファイルの中で
// ユーザーデータ用の構造体の宣言と、エラーハンドラ関数のプロトタイプ宣言をしておく

typedef struct _PDFService_userData {
 HPDF_Doc pdf;
 PDFService *service;
 NSString *filePath;
} PDFService_userData;

// エラーハンドラ関数のシグネチャは常にこうでなければならない
// 関数名は自由に決めて良いが、引数と返り値は決められている
void PDFService_errorHandler(HPDF_STATUS error_no,
 HPDF_STATUS detail_no,
 void *user_data);

// 注意点として、エラーハンドラ関数はHPDF_Newより前の行で実装しておかなければならない
// （プロトタイプ宣言しておいてもだめみたいです）
void PDFService_errorHandler(HPDF_STATUS error_no,
 HPDF_STATUS detail_no,
 void *user_data) {
 // ユーザーデータを取得する
 // C言語の構造体からでもObjective-Cのクラスが取り出せますよ
 PDFService_userData *userData = (PDFService_userData *)user_data;
 HPDF_Doc pdf = userData->pdf;
 PDFService *service = userData->service;
 NSString *filePath = userData->filePath;

 // エラーハンドリング後、PDF関連の処理を続行したい場合は
 // このHPDF_ResetError関数を呼び出す必要がある。
 // これを呼び出さないと後続の処理がうまくいかない。
 HPDF_ResetError(pdf);

 // 逆にエラーハンドリング後、PDF関連の処理をすべて中断したい場合には
 // HPDF_Free関数を使ってpdfオブジェクトを解放するとよい。こうすると、以後の
 // HPDF関連の関数はすべて何もしないで終了してくれる。ただし、同じpdfオブジェクトを
 // 2回HPDF_Freeしてしまうとエラーになるため、HPDF_HasDocを使って制御すること
 HPDF_Free(pdf);
}

// あとはPDFドキュメント生成時に関数とユーザーデータを引数として渡す
int main(int argc, char** args) {
 PDFService_userData userData;
 HPDF_Doc pdf = HPDF_New(PDFService_defaultErrorHandler, &userData);
 userData.pdf = pdf;
 userData.filePath = @"/var/tmp/hogehoge.pdf";
 // 以下省略
}

■CとObjective-Cをつなげる
C言語的にはこれでよいのですが、Objective-C、ひいてはCocoa Touchフレームワーク的にはこういうエラー処理はdelegateにしてしまったほうが便利です。たとえば、PDFファイルを生成するためのObjective-CクラスPDFServiceに、PDFServiceDelegateを持たせて運用してみましょう。libHaruのエラーハンドラ関数を以下のように作ってみます。

void PDFService_defaultErrorHandler(HPDF_STATUS error_no,
 HPDF_STATUS detail_no,
 void *user_data)
{
 // ユーザーデータを展開
 PDFService_userData *userData = (PDFService_userData *)user_data;
 HPDF_Doc pdf = userData->pdf;
 PDFService *service = userData->service;
 NSString *filePath = userData->filePath;
 
 // 以後のPDF作成処理をすべてストップする
 HPDF_Free(pdf);
 
 // Delegate呼び出し
 if (service.delegate) {
 [service.delegate service:service
 didFailedCreatingPDFFile:filePath
 errorNo:error_no
 detailNo:detail_no];
 }
}

あとはこのDelegateを適当なViewControllerなどに準拠させて、

#pragma mark -
#pragma mark delegate method
- (void)service:(PDFService *)service
didFailedCreatingPDFFile:(NSString *)filePath
 errorNo:(HPDF_STATUS)errorNo
 detailNo:(HPDF_STATUS)detailNo
{
 NSString *message = [NSString stringWithFormat:@"Couldn't create a PDF file at %@\n errorNo:0x%04x detalNo:0x%04x",
 filePath,
 errorNo,
 detailNo];
 UIAlertView *alert = [[[UIAlertView alloc] initWithTitle:@"PDF creation error"
 message:message
 delegate:nil
 cancelButtonTitle:@"OK"
 otherButtonTitles:nil] autorelease];
 [alert show];
}

とすると、冒頭のイメージのようになります。

製作期間二日。この程度の物に二日とか許されるのは小学生までよねー・・・orz
一応自機も動くしあたり判定もあるしゲームオーバーにもなるよ！すごいよcocos2d！

---

以下、全然関係ないけど設計のお話です。

(2009年08月30日追記) 以下の内容に従って作ってみた結果がこちら：http://akisute.com/2009/08/blog-post_29.html
見ての通り大失敗してます。やっぱり継承して作った方がうまくいくっぽいです・・・


Javaの継承システムでは、サブクラスはスーパークラスのコンストラクタを引き継がない。また、暗黙的にスーパークラスのデフォルトコンストラクタを最初に呼びだすことになっている。だから、これはコンパイルが通らないし、

class Parent {
 private String name;
 public Parent(String name) {
 this.name = name;
 }
}
class Child extends Parent {
 int age;
 public Child(int age) {
 // デフォルトコンストラクタがないし、明示的にSuper(String)を呼んでいない
 this.age = age;
 }
}

これもコンパイルが通らない。

class Parent {
 private String name;
 public Parent(String name) {
 this.name = name;
 }
}
class Child extends Parent {
 int age;
 public Child(int age) {
 super("child");
 this.age = age;
 }
}
public static void main(String[] args) {
 // ChildにはSuperのコンストラクタが継承されないのでこれはできない
 Child child = new Child("akisute");
}

ところがObjective-Cの継承システムでは、サブクラスがスーパークラスのイニシャライザをすべて受け継いでしまう。なぜならイニシャライザも何の変哲もないタダのメソッドだから。だから、こんなコードが書けてしまう。

@interface Parent : NSObject {
 NSString *name;
}
@end
@interface Child : Parent {
 int age;
}
@end
@implementation Parent
 - (id)initWithName:(NSString *)aName
 {
 if (self = [super init])
 {
 name = aName;
 }
 return self;
 }
@end
@implementation Child
 - (id)initWithAge:(int)anAge
 {
 // Parentにはinitが無いが、NSObjectにはあるので
 if (self = [super init])
 {
 age = anAge;
 }
 return self;
 }
@end
int main (int argc, char const *argv[])
{
 NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 // Childには無いinitWithNameが呼び出せてしまう
 Child *child = [[[Child alloc] initWithName:@"akisute"] autorelease];
 NSLog(@"@%", child);
 [pool release];
 return 0;
}

で、何が一体問題になるのかというと、この仕様のせい（おかげ？）で安易な継承が出来なくなっている。たとえば今回のcocos2dを使ったゲームでは、キャラは全部Spriteのサブクラスにしたかったんだけれども、そうするとSpriteクラスに最初から用意されているイニシャライザ（initWithFile:とかinitWithTexture:とか）が外に漏れてしまう。しかもこいつらを呼びだされると本来自分の作ったキャラクラスで呼びだしたかったイニシャライザが回避されて、任意の画像でへんちくりんなキャラを作られてしまう危険性がでてしまう。そこで、今回はこういうふうに継承ではなくてコンポジットを使ったコードにした。

@interface MSObject : NSObject {
 /** Sprite for this object. Can be changed to AtlasSprite for further performance. */
 Sprite *sprite;
 /** Hit box size */
 CGSize hitBoxSize;
}

後から考えたらこの方が正解だった。だって、こうしておけば外へ公開するAPIを変化させずに、中身のSpriteをよりパフォーマンスの良いAtlasSpriteに後からいくらでも差し替えられる！

時間を入力するためのUIが欲しかったので、こんな感じのカスタムUIPickerViewを作ってみました。ソースコードはこちら。
http://github.com/akisute/YourTurn/blob/8119bf028acf4908edb602d277544bc2cf6a5848/Classes/YTTimePickerView.h
http://github.com/akisute/YourTurn/blob/8119bf028acf4908edb602d277544bc2cf6a5848/Classes/YTTimePickerView.m


使い方はソースを見ていただければきっとご理解いただけると信じておりますので、UIPickerViewを使っていて気づいた点などをいくつか晒してみたいと思います。


■参考にした記事
id:paellaさんのダイアリーを参考にさせていただきました。ありがとうございます。
http://iphone-dev.g.hatena.ne.jp/paella/20090521#20090521fn1

基本的にはこちらの記事にまとめられている内容に従って、

// 2) ビューを返したい場合
- (UIView *)pickerView:(UIPickerView *)pickerView viewForRow:(NSInteger)row forComponent:(NSInteger)component reusingView:(UIView *)view {}

このデリゲートメソッドを使いカスタムViewを利用した実装を行ったのですが、一部私の実装とpaellaさんの記事で異なっている点があるので、ご紹介したいと思います。


■UILabelを直接デリゲートメソッドから返す
元記事では、

UIViewを返すデリゲート、必ずUIViewを返さないとうまく動いてくれません。このサイトやこのサイトで紹介されているようなUILabelを直接渡してあげる方法は、少なくとも私の環境(2.2.1)では何も表示されませんでした。

と、UIViewを返さなくてはダメとご指摘がありますが、どうやらUILabelでも大丈夫みたいです。ビルドターゲット = iPhone OS 2.2.1の環境で確認できました。

UILabelをそのままデリゲートから返却したときに画面に表示されなかった原因は、どうやらUILabelのframe.size.heightが0になってしまっていた（要するにつぶれてしまっていた）のが原因みたいです。そこで、以下のようなコーディングを行いました。

- (UIView *)pickerView:(UIPickerView *)picker viewForRow:(NSInteger)row forComponent:(NSInteger)component reusingView:(UIView *)view
{
 UILabel *label = (UILabel *)view;
 if (!label)
 {
 label = [[[UILabel alloc] init] autorelease];
 label.frame = CGRectMake(label.frame.origin.x, label.frame.origin.y, 20.0, 23.0);
 label.backgroundColor = [UIColor clearColor];
 // 以下初期化コードなど・・・
 }
 
 return label;
}

このように、label.frameの高さを無理矢理指定してやれば、きちんと画面に出せるみたいです。また、この方法を使えば、元記事で

ポイントはビューの座標。どうも各要素での{0,0}の位置はPicker内各Rowのど真ん中にあるらしく、サンプルのように負数を指定してあげないとどこかに寄った状態になってしまうみたいです。

とご指摘があったビューの座標も、特に気にせず普通に指定することが出来るようになりました。


■Pickerを、UIScrollViewのサブクラス（UITableViewなど）にaddSubviewする場合の注意点
この記事の見出しに貼り付けた画像では、作成したカスタムPickerをGroupedスタイルなUITableViewのfooterViewに貼り付けています。

 // Initialize time picker with a previously selected value
 timePicker = [[YTTimePickerView alloc] initWithFrame:CGRectZero];
 NSInteger initialValue = [[NSUserDefaults standardUserDefaults] integerForKey:_USERDEFAULTS_TIMEPICKER_INITIALVALUE];
 timePicker.time = (initialValue == 0) ? 300 : initialValue;
 timePicker.timePickerViewDelegate = self;
 [timePicker selectRowWithCurrentTime];
 self.tableView.tableFooterView = timePicker;

このように、UIScrollViewのサブクラスのサブビューとしてUIPickerViewを貼り付けると、そのままの状態ではうまくPickerのドラムが回転してくれないという症状が発生してしまいます。
これはどうやらUIPickerViewのスクロールとUIScrollViewのスクロールがけんかしてしまっているみたいです。そこで、スクロールする必要のないTableView側の設定をOFFにします。具体的には、Interface Builderを利用する場合、以下の赤枠でくくった箇所を設定すると良いようです。



こうすることで、綺麗にドラムが回転してくれるようになります。

NSTimerを初めて使ってみたのでハマったところをメモしておきます。


■NSTimerはNSRunLoopにretainされる。NSTimerは引数targetで与えられたオブジェクトをretainする。
いちばんハマったのがこの挙動です。
AppleのNSTimerについての公式ドキュメント(http://www.devworld.apple.com/documentation/Cocoa/Conceptual/Timers/Articles/usingTimers.html#//apple_ref/doc/uid/20000807-CJBJCBDE)にもクラスリファレンスにもきちんとと明記されていたのですが・・・思いっきり見落としてました。

これらがいったいどんな問題を引き起こすか。
たとえば普通のクラスと同じ感覚でdealloc中にNSTimerのinvalidateを呼び出すコードを書くと、永遠にdeallocが呼び出されなくなってしまいます。

// ViewControllerがNSTimerを使っているとして・・・
- (void)viewDidLoad
{
 timer = [NSTimer scheduledTimerWithTimeInterval:interval
 target:self // このselfはretainされる
 selector:@selector(timerFired)
 userInfo:nil
 repeats:YES];
}
- (void)dealloc
{
 [displayLabel release];
 [timerLabel release];
 // ここでinvalidateしてはいけない、永遠にdealloc自体が呼び出されなくなる
 [timer invalidate];
 [timer release];
}

なぜなら、

• NSTimerがdeallocを呼び出すオブジェクトをretainしている、したがってNSTimerがreleaseされるまでdeallocが呼ばれない
• NSTimerはNSRunLoopにretainされている、従ってNSTimerのinvalidateが実行されるまではNSTimerはreleaseされない
• invalidateを呼び出しているのはこのdeallocの中以外にない。・・・詰みました。

こうならないようにするためには、dealloc以外の箇所から、適切にinvalidateメソッドを呼び出してやる必要があります。ということで、ViewControllerの中でNSTimerを使うときは、以下の2点に気をつければ良さそうです。

1. NSTimerのオブジェクトは基本retainしない（自分でNSRunLoopにaddTimerとかしたい場合は別として）
2. 通常deallocのタイミングでオブジェクトをreleaseするのと同じようにNSTimerをinvalidateしたい場合は、- (void)viewWillDisappear:(BOOL)animated を使う

- (void)viewWillDisappear:(BOOL)animated
{
 if (timer)
 {
 // ここでタイマーをinvalidateする
 // invalidateするとNSRunLoopがretainされていたこのタイマーをreleaseしてくれる
 [timer invalidate];
 timer = nil;
 }
}

■userInfoはただのNSDictionary
そのまんまです。クラスリファレンスを見ても

The user info the new timer.

This parameter may be nil.

としか書いてなくて困ったのですが、本当にただのNSDictionaryです。適当に使ってくれってことでしょうか。


■次のタイマーイベントまでの間隔をリセットしたいときはsetFireDate:
たとえば何らかの理由でタイマーのFireイベントに登録していたセレクタを自分で呼び出しちゃって、次のタイマーイベントまでの間隔をリセットしたいときなどは以下のような具合にするとよいです。

if (timer)
{
 // timerのsetFireDateに、次にタイマーイベントが発生する日時をセットする
 // NSDateに、dateWithTimeIntervalSinceNowという便利なメソッドがあるのでこれを使う
 [timer setFireDate:[NSDate dateWithTimeIntervalSinceNow:interval]];
}

■っていうか
今このBlogを書くためにNSTimerでぐぐったらここに書いてあるようなことがいろいろ見つかってしまいました・・・＞＜
先にちゃんと調べてから作らないと無駄ですね−。

Pythonだと、

list = [{'no':1, 'name':'akisute'}, {'no':2, 'name':'abesi'}, {'no':3, 'name':'hidebu'}]
maxNo = max(list, key=lambda x:x['no'])

こんな感じでリストに含まれるオブジェクトの最大値を簡単に取り出せたりするのですが、Objective-Cでもできないかと思い調べてみました。ですが、NSArray自体にはそのようなメソッドが用意されていません。ひょっとして出来ないのかと思っていたら、ちょっと面白い方法で集計関数のようなものが実装されていることがわかりました。

Objective-CにはKey-Value Codingという概念があって、それを使って実装されているようです。Key-Value Codingについては正直全然理解していないのでここでの解説は避けます。すみません。

NSArrayのvalueForKeyPathを使って以下のように問い合わせを行うと、先ほどのPythonの例と同様にNSArray中の最大値を持つオブジェクトを取得することが出来るようです。

// noとnameプロパティを持つPersonクラスがあると仮定して・・・
id akisute = [[Person alloc] initWithNo:1 name:@"akisute"];
id abesi= [[Person alloc] initWithNo:2 name:@"abesi"];
id hidebu= [[Person alloc] initWithNo:3 name:@"hidebu"];
NSArray *array = [NSArray arrayWithObjects:akisute, abesi, hidebu, nil];
NSNumber *maxNo = [array valueForKeyPath:@"@max.no"];

valueForKeyPathの引数に、@max.noというキーを渡すところがキモです。これで、NSArrayのインスタンスに含まれるオブジェクトのnoプロパティの最大値を求めることが出来ます。
同様にして、名前の最大値を求めたいときには、

NSString *maxName = [array valueForKeyPath:@"@max.name"];

とすれば取れます。また、一番長い名前の長さを求めたいときは、以下のように指定することができます。

NSNumber *maxCountOfName = [array valueForKeyPath:@"@max.name.count"];

@max以外にも、@avg, @sum, @count, @min, @unionOfObjects, @distinctUnionOfObjectsなどが用意されているみたいです。

詳しくは荻原さんのObjective-C 2.0本をご参照あれ。いや、この本は本当に買ってよかったです。Objective-Cのバイブルですね。

詳解 Objective-C 2.0
荻原 剛志
4797346809

自分用メモ。
nilは「Objective-Cの空のオブジェクト」、NULLは「C言語の空ポインタ」と解釈する。もっとも良い例がNSFileManagerのcreateDirectoryAtPath:withIntermediateDirectories:attributes:error:です。
（http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html#//apple_ref/occ/instm/NSFileManager/createDirectoryAtPath:withIntermediateDirectories:attributes:error:）

リファレンスを読んでみると、attributes:の指定が不要なときはnilを、error:の指定が不要なときはNULLを引数として与えろと明示的に書かれています。これは、attributes:が(NSDictionary *)型＝NSDictionaryのオブジェクトを引数として受け取るのに対して、error:は(NSError **)型＝NSErrorのオブジェクトのポインタを引数として受け取るためだと考えられます。といっても私はObjective-CもC言語もド素人ですので、ひょっとしたら大嘘かもしれません。違ってたらごめんなさい＞＜


※追記：やっぱり定義そのものが違った＞＜
すたっくおばふろ曰く（http://stackoverflow.com/questions/557582/null-vs-nil-in-objective-c）
えらいひと曰く（http://www.libjingu.jp/trans/clocFAQ-j.html#objects-nil）


知らないとついつい全部nilもNULLも同じだろと思いnilって指定してしまいそうですね。おそらくnilを指定しても動くとは思いますが・・・Objective-CとC言語の混ざり合いというか関わり合いがこんなところで垣間見れて面白いです。

そう、Objective-CにはNilPointerExceptionのようなものがないんです。
Javaでは

int main(String[] args) {
 String str = null;
 int length = str.length(); //NullPointerException
 // bar()がnullだとNullPointerException
 Object result = Foo.bar().baz().abesi().hidebu();
}

Objective-Cでは

int main(int argc, char** argv){
 NSString *str = nil;
 int length = [str length]; //何も起こらない。lengthにはデフォルト値0が入る
 // barがnilを返したら、後続のbaz, abesi, hidebuもnilを返す。
 id result = [[[[Foo bar] baz] abesi] hidebu];
}

同僚の方（http://twitter.com/ksk_matsuo/status/1682599075）よりこっそり教えていただきました。ありがとうございます！

なんと言ってもJava人にとっていちばん恐ろしいのがこのNullPointerExceptionなのですよ。だからオブジェクトのメソッドを呼び出すときはいつでもオブジェクトがnullだったらどうしようガクブルと思いながらプログラム書いてるわけです。それがいきなり「Objective-Cになったらぬるぽなんてありません安心です＾＾」なんて言われても安心できないなぁ＞＜

• タッチイベントを扱うときはRMMapViewDelegateプロトコルを採用する
• シングルタッチ、ダブルタッチを感知したり、マーカー上のタッチやドラッグを感知したり、地図の移動およびズームを感知したりできる
• 現状、マップのドラッグやズームを使用不可能にするための手段は用意されていない。Delegateの返り値による操作もできない。
• UIMapViewにenableDraggingおよびenableZoomというインスタンス変数が用意されているが、mapView->enableDraggingのようにしてアクセスしようとするとコンパイルエラーになってしまう。

route-me上でタッチイベントを取得してみました。

こんな感じで、画面上のタップした点を取得することができます。

タッチイベントの取得方法は、
まずRMMapViewDelegateプロトコルを任意のクラスに適合させて、

@interface MapViewController : UIViewController  {
/* 中略 */
- (void) singleTapOnMap: (RMMapView*) map At: (CGPoint) point
{
NSString *message = [NSString stringWithFormat:@"(%f, %f)", point.x, point.y];
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"singleTapOnMap"
 message:message
 delegate:nil
 cancelButtonTitle:@"OK"
 otherButtonTitles:nil];
[alertView show];
}
/* 後略 */

適合させたクラスのオブジェクトをRMMapViewのdelegateプロパティにセットします。

RMMapView *mapView = [[[RMMapView alloc]
 initWithFrame:[UIScreen mainScreen].applicationFrame WithLocation:initialLocation.coordinate]
 autorelease];
mapView.delegate = self;

普通のUIViewとほとんど同じですね。

しかしこの方法では画面上の座標がとれるだけで、緯度経度を取ることができませんので、
RMMapViewのメソッドを用いて、緯度経度に変換します。

@interface MapViewController : UIViewController  {
/* 中略 */
- (void) singleTapOnMap: (RMMapView*) map At: (CGPoint) point
{
//ポイントをLatLongに変換して表示する
CLLocationCoordinate2D coordinate = [map pixelToLatLong:point];
NSString *message = [NSString stringWithFormat:@"(%f, %f)", coordinate.latitude, coordinate.longitude];
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"singleTapOnMap"
 message:message
 delegate:nil
 cancelButtonTitle:@"OK"
 otherButtonTitles:nil];
[alertView show];
}
/* 後略 */

これで緯度経度になりました。

ところで、地図のスクロールやズームを制限して利用したいというときがあると思います。
たとえば日本向けのアプリなのにアルゼンチンの地図をスクロールして表示されたら困るという場合です。

早速地図のスクロールを制限する方法を調べてみたところ、
RMMapViewにいかにもそれらしいメンバー変数を発見。

@interface RMMapView : UIView
{
RMMapContents *contents;
id delegate;
BOOL enableDragging;
BOOL enableZoom;
RMGestureDetails lastGesture;
float decelerationFactor;
}

しかしながらこのメンバー変数、プロパティも操作するためのメソッドもなく、外部から操作することができません。
ためしに無理矢理以下のようなコードを書いてアクセスしてみたところ、コンパイルではねられました。

RMMapView *mapView = [[[RMMapView alloc]
 initWithFrame:[UIScreen mainScreen].applicationFrame WithLocation:initialLocation.coordinate]
 autorelease];
//以下の行でエラー。アクセスできません
mapView->enableDragging = NO;

残念ながらまだこの機能は現在のバージョンのroute-meでは利用できないみたいです。

その他、delegateメソッドの返り値をNOにしたらスクロールしなくなるとかそういう機能がないか調べてみましたがやはりなさそうで、今のところ地図のスクロールおよびズームを制限するのは難しそうです。今後のバージョンアップに期待ですね。