読者様から秀和システムに届いたメールで、サポートページの「ダウンロードボタン」をそのままクリックしてダウンロードするとサンプルプロジェクトが破壊される事がわかりました(情報感謝です)。

 sample-iosbug130210.zipがダウンロードされ、そのままパスワードが聞かれず(なぜ聞かれないのか不明)に解凍される事でサンプルプロジェクトが破壊されてしまうのが原因みたいです。

 対応するつもりですが、今のところは次のステップで問題を回避してください。

1)サポートページのダウンロードボタンを右クリック(またはcontrolキーを押しながらクリック)して現れたメニューから「リンク先のファイルをダウンロード」を選び、ダウンロードフォルダにsample-iosbug130210.zipをそのままダウンロードする。
1

2)ダウンロードフォルダにできたsample-iosbug130210.zipをダブルクリックし、現れたパスワード入力画面でパスワードを入力して解凍する。

 ご迷惑をおかけします。
 あと、Xcode 5対応用PDFのダウンロード準備できました~。
 ↓以下のリンク先で「補足情報について」の「hosoku.pdf」をダウンロードだ!
出版社:サポート
AD
 Foundationフレームワークが提供するNSArrayなどは範囲外のインディックスを指定したりすると例外オブジェクトを投げるようになっていて、投げられた例外オブジェクトをキャッチしない場合、アプリケーションはそのまま異常終了します。

 例えば0~9までの10個のオブジェクトしか格納していない時に、100番目の格納オブジェクトを要求されても、NSArrayは対処できないわけです。
 この場合、Foundationフレームワークはnilオブジェクトを返すという消極的な対応策は取らず、プログラマに間違っている事を積極的に伝えようとします。これが例外オブジェクトを投げる行為です。
 
 NSMutableArrayならnilをaddObject:しようとしたら例外が投げられます。
 Empy ApplicationテンプレートのAppDelegateで、次のような2行を追加すれば、この現象を簡単に再現できます。
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
// Override point for customization after application launch.
self.window.backgroundColor = [UIColor whiteColor];
[self.window makeKeyAndVisible];
NSMutableArray* array = [NSMutableArray array];
[array addObject:nil];

return YES;
}


------------
サンプルプロジェクト:addNil.zip

 NSMutableArrayはnilオブジェクトを収納対象外としています。代替策としてはNSNilオブジェクトを使う方法があるんですが、これは各自で調べてください。

 とにかく、この場合、Runさせるとデバッガは一番外の関数であるmainで停止してしまって、発生箇所を特定しにくい状態です。コンソール画面である程度の情報は得られますが、できれば直接の原因発生箇所で止まってもらいたいものです。

テン*シー*シー-1

 このような場合、例外ブレークポイントが役立ちます。
 ナビゲーターセレクタバーからShow the Breakpoint Navigatorタブを選び、下にある「+」ボタンを押してください。ポップアップメニューからAdd Exception Breakpoint…を選びます。

テン*シー*シー-2

 現れた吹き出しは、そのままDoneボタンを押してください。

テン*シー*シー-3

 これで、あらためてRunさせるとaddObject:nilメッセージのところで止まるようになります。

$テン*シー*シー-4
AD

改訂本が出ます

 ただ今、年末進行でデバッグ本の改訂作業ちゅ~♩

$テン*シー*シー-1
俺は今、年末進行でナーバスになってるんだ、インタビューなら後にしてくれ風に

 最近は、MacBook Air 11インチ(2012年版)にナナオの24インチをつないで作業してる。
 iMac(2009年版)のHDD交換の時に切り替えたんだけど、想像以上に快適なんで、未だにそのままなんですよ。

修理に旅立ちます

 2010年版のAirは「動作がちょっと鈍いんだけど、軽さ、大きさとのトレードオフでしゃーないかー」って感じだったけど2012年版Airはサクサク動きます。SDカードスロットルが無いんだけど、最近クラウド環境が整ってきてるんで13より11インチかな。軽さは正義。
 これで電池時寿命そのままでレテナ(IGZO希望)になったら最強かもね。

 改訂本は、サポートページで出してる「Xcode 4.3.2との違いの補足説明」を本に反映させる作業がメインです。特に追加ってものはありません。まあ、ARCについて入門本の補足で説明した程度の話は追加してる。
 なので、本持ってる人は特に買い替えの必要は無いです。

 UILabelがiOSバージョン6から文字ごとにスタイル設定できるようになったんで、そのあおりをくらって本文の展開がうまくできなくなってる点も補正。
 プロパティtextはcopy属性なのに、同じNSStringオブジェクトのアドレスが入ってくるってくだりね。
 別のアドレスが返ってくるんですよ~。バージョン6から。
 別に、本で説明したMutableじゃないNSStringはcopyメッセージに対し、自分自身をretainしてから返すんだよって話が変わったわけではないです。
 UILabelが受け取ったNSStringをmutableCopyかしてNSMutableStringで持ってるっぽい。
 ま、ここらへんの話はデバッグ本読んだ人は理解してもらえるんじゃないかと。


 しっかし、ARC導入でいよいよ熟練工に優しく入門者の学習に厳しい環境になってますな。
 ドリル本で「Storybordやxibは、熟練工には本当にありがたい存在なんだけど、入門者がGUIを学習するには邪魔になる」って書いたけど、同じように、メモリ管理を学習する時にはARCが邪魔になるんだよね。
 まあ、メモリ管理の方は、学習してなくてもARCに任せてりゃなんとかなるけどね。昔みたいにretain忘れでゾンビ化、アプリ強制終了ってのは起こりにくくなってる。初心者でもそれなりに動作するアプリが作れる、それがARCのいいところおぉおおおお。
 なんでもstrong指定して、循環参照をばんばん作りそうで怖いけど。
 Core Foundationフレームワークと連携したりする時、な、なんすかCFRetainってぇえ、とかなっちゃうんだろうな~。

 というわけで、デバッグ本は「所有権ポリシー」をARCオフで説明し、オンにするとARCが代行してくれるんだよって感じにしてます。

 たぶん来年1月の末に出ます。
 来年て書くと余裕、来月と書くと涙。
AD