プログラミングの最近のブログ記事

　こちらのブログ更新の放ったらかしだった。そして１年以上開けて，再び久し振りのXcode。今度はバージョンが5.1だから，また勉強し直しである。

　しかし開発ツールが着実にバージョンアップしているのは頼もしい。かつてと比較するとADCやiTunes Connectとのやり取りは自動化されて大変楽になっているし，アイコンやスタートアップ画像の管理も分かりやすくなっている。見た目もすっきりして，iOS7アプリをつくるにふさわしい開発環境としてちゃんと進化している。

　というわけで，手持ちのアプリをiOS7時代に対応させるべく，ゴールデンウィークの連休を費やして最新事情を勉強。今度のWWDC2014で置いていかれないためにもアプリのアップデートをすることにした。

　なるほど話題になっていたことはこういうことだったのかと，浦島太郎状態で情報理解を進め，なんとかアップデート作業に結びつけ，申請と承認を経て，アプリがアップデート配信となった。周回遅れとはいえ，めでたいことだ。

--

　Xcodeはとても気に入っている開発ツールなのだが，Androidの側でもAndroid Studioという新しい開発ツールが昨年発表されている。

　ぼちぼちAndroidにも手を出してみようかなと思っていたりする。開発したアプリをAndroidでも動かせないかなと思っているから。でもまだ何も手を付けていないので，まだまだ時間はかかりそうだけど。

　本業が慌ただしく、長らくプログラミングからは遠ざかっていた。

　まだ完全に手が空いたわけではないのだが、放置しておくつもりもなかったので，連休を機会に開発環境を整えて，新しいOSやデバイス上で実行できるようにすることから始めることにした。

　手持ちのアプリのアップデートよりもiOSのバージョンアップの方が速いくらいで、いまや最新の開発ターゲットはiOS6で，デバイスはiPhone5となってしまった。

　案の定，古いソースコードはそのままではビルドで警告が出まくるし、ライブラリの挙動がまた微妙に変化してしまっているし、画面サイズがもう一つ増えた。

　アプリ内広告のモジュールも新しくする必要がある。開発マシン上の証明書や鍵が混乱しているようなので，新しく証明書と鍵，プロビジョニングを取り直して，ようやくアプリのアップデート。

　また少しずつ勉強し直そうと思った。

　こちらは開発ブログということで、最近リリースした新幹線予約アプリEX489の開発裏話など書いている。

　リリース当初は、辛辣レビューの洗礼を受けて、てんやわんやといった感じではあった。しかし、情報提供をしてくれるユーザーの皆さんのおかげで、アプリのバグをあれこれ発見し、修正作業を続けているといったところである。

　こちらが『大丈夫」と安心しても、実際のフィールドで利用され始めると、あれこれ穴が見つかるものだなと痛感した。こればっかりは謙虚に受け止めなければと思う。

--

　バグは設計上の不足や実装対応を後回しにした部分が引き起こしたものなどもあったが、大きく悩ませた問題の原因は、コーディングの際のタイプミスだった。

　たとえば、どこかで「self.」を忘れていたために起こるメモリエラーの類いだ。

　思い返せば、こうした作業をしていた時が、夜を徹して眠気の最高潮の時期だったものもあり、要するに注意力散漫になっていたために引き起こした人為的「凡ミス」だったというのは笑うしかない理由である。

　もっともこちらが苦笑いしても、アプリ利用者には迷惑な話だったので、もう単純に詫びるしかない。申し訳なかった。

--

　しかも、こうした突貫作業がコードの見直しをしていた時に起こっていたから、以前動作チェックして安心していたところに気づかず問題が入り込んだ形になった。

　リリース前にすべてのテストをやり直すべきだったとはいえ、個人の隙間時間プログラマであることもあって、なかなか手が回らなかったというのが正直なところだ。

　とにかく、今後は突貫作業はなるべくやらないようにして、できるだけ問題予防的に開発を進めないといけないなと思う次第である。

　２本目のアプリの開発と記録を始めます。

　開発は初期段階にあるので，完成するかも，リリースするかも分かりません。だとすれば，記録ぐらいは残しておくかなという感じです。

　１本目のアプリの改善を後回しにして２本目に取り掛かるのは，２本目をスクラッチで作ることでプログラミングのノウハウをさらに得てから１本目に戻った方がより良いと考えたからです。

　１本目の「Ride on Time」は，東京暮らしで欲しいと思った時刻表アプリを勢いで作ったものでした。そのためプログラム的にはMVCをあまり考慮せず，分割整理されていないソースコードとなっていました。

　２本目のアプリは，その辺を少し意識して設計・プログラミングすることでノウハウを得ようという訳です。

--

　さて，動機はともあれ，２本目のアプリとして何を開発するのか。

　やはり欲しいと思ったものを作るのが一番なので，１本目を開発するにあたって同時に欲していたアプリにすることにしました。東京暮らしの最後に遭遇した鉄道関係の体験に由来するものです。

　短期間の間に新幹線を使ってあちらこちらへ移動するという体験をしました。仕事で頻繁に使用する人間ではなかったので，新幹線を日常遣い的に乗る体験は新鮮でした。

　そのときに大変役に立ったのがJR東海の「エクスプレス予約」（EX予約）サービスとIC乗車券によるタッチ改札でした。これは帰省するときに利用していたのですが，普段遣いの乗車だとさらに効果を発揮することが体感的に理解できました。

　けれども，当時のEX予約はiPhoneには対応していませんでした。現時点でも対応していません。

　そこで「EX予約が出来るアプリが欲しい」という願いが出てくることになります。この願いを持つ人はかなり多いようです。

　２本目は「EX予約アプリ」にすることにしました。

--

　あとで検討しますが，EX予約をスマートフォンで使いたいという要望に応えるためのいくつかのアプリがiPhone用やAndroid用にリリースされています。

　また，JR東海は2011年に入ってスマートフォンの普及に対応するための取組みを発表しましたので，直に予約サイトがiPhoneで使いやすくなると思います。

　ということはEX予約アプリを新規につくる意味はないんじゃないか？という風にも考えられます。

　けれども，他の多くのアプリと同様，同じ目的を達成するとしても様々なアプローチが併存して選択できることは悪い事ではないはずです。

　しかも，現在リリースされているEX予約アプリは，ほとんど同じアプローチで開発されており，正直「予約は可能だけど使いやすくはない」と感じます。これは新規アプリを開発するに十分な理由です。

　まあ，出来るかどうかは分かりませんから，とにかく挑戦することにしたわけです。うまくいけば完成して，ちょっと違うEX予約への道筋がつくかも知れません。

　長らく更新してませんでした。

　昨年11月下旬から今日まで，Mac App Storeが生まれたり，iPad2が登場して，本当にiOS 4.3が登場したりとApple的には賑やかな出来事が続いています。

　そしてXcode 4.0も正式リリースされました。とりあえずiOS 4.3環境をターゲットに開発を再開してみることにしました。

　東日本大震災が起こり，心が落ち着かない日々なのですが，だからこそプログラミングでもして気持ちを落ち着けようかと思った次第です。

--

　以前リリースした時刻表アプリ「Ride on Time」の改善にも取り組まなければならないと考えているのですが，まだ満足いく改善デザインを思い描けていないため，もう少し後で取り組むことにしました。

　試行錯誤しながらコーディングしたアプリなので，ソースコードがスパゲッティ化していることも作業に取り掛かることを難しくしている理由です。

　辛抱して活用し，改善を待ち望んでいる皆さんには大変申し訳ないのですが，新しいアプリを先に開発することにしました。

--

　iOSでは写真アルバムからの画像を選び出す手段としてイメージピッカー UIImagePickerControllerクラスを提供しています。

　iPad上では，これをPopoverというUIで使用しなさいという条件が付いています。ボタンを押すと現れる吹き出しのようなインターフェイスがPopoverです。

　Popoverの横幅は320ピクセルとされていて，これはiPhoneの横幅と同じなので，テーブルビューなどをそのまま持ってきてPopover内に表示することができます。Popover内がiPhoneアプリのように見えるのも当然です。

--

　ところで，イメージピッカーで写真を選択する場合，範囲選択の編集をさせることができます。allowsEditingプロパティをYESにすれば，選択後に拡大縮小と範囲を移動させる画面が用意されます。

　そして，ピックアップした画像をおさめたNSDictionary型からUIImagePickerControllerEditedImageをキーとして編集結果を取り出すという手順になります。ちなみに，UIImagePickerControllerOriginalImageをキーにすると編集されてないオリジナル画像が取り出せます。

　ところが，この方法を素朴に採用すると横幅最大320ピクセルの画像しか取り出せず，それを拡大するとぼやけてしまいます。

　というのもイメージピッカーがPopoverの中でしか使えないためです。Popoverの大きさを拡大すれば，原理的にはイメージピッカーの切り抜きサイズも大きくなるはずですが，残念ながらPopoverは，縦方向はともかく，横方向は320ピクセルに制限されているため，数値を大きく指定して引き伸ばしてもすぐに幅320ピクセルへ縮んでしまいます。

--

　iPadでイメージピッカーを使用して，大きなサイズの画像を切り抜けないのかというと，そうでもありません。

　幸い，イメージピッカーはオリジナル画像とともに切り抜こうとした矩形範囲の座標をUIImagePickerControllerCropRectキーで教えてくれるのです。

　であれば，こちらでオリジナル画像を切り抜けば良いだけのこと。画像の切り抜き方法は，ググるとあれこれ出てきますので，それを参考にしましょう。

　ところが，うまく切り抜いてアプリも動いているにもかかわらず，処理を繰り返していると頻繁に「落ちる」。メディアを自在に閲覧できるiPadがどうして？と訝しく思えるのですが，どうも画像を保持するUIImageViewでは1024ピクセル以上の画像を扱わないで欲しいらしい。かなりメモリにシビアなのが現状です。

　というわけで，切り抜いた画像を1024ピクセル以内にリサイズすることにして，やっと問題が解消しそうです。

　新しいアプリの開発を始めて，iPadとiPhoneのユニバーサルアプリを勉強しています。Appleの「iPadプログラミングガイド」や『iPadプログラミングの作法』などが参考になります。

　ユニバーサルアプリのメリットはそれほど大きくありません。iPadとiPhoneの個別修正があった場合，変更無い方も一緒に更新作業が必要になる煩雑さがユーザーにはあるかもしれませんし，有料アプリの場合には価格設定を分けられないというのも困るかもしれません。

　開発の手間も減るわけではありませんが，配信手続きが一回で済む点は便利かなと思います。なにしろ，あのAppStoreですから，願わくはシンプルに済ませたいものです。

--

　現時点で，ユニバーサルアプリの開発は，iPhone OS3.2（iPad）とiOS4（iPhone）というメジャーバージョンの異なるOSを想定して作業することになります。

　iOS4からマルチタスクやアプリ切り替え機能が追加されたので，アプリのコア設計も変わってしまっています。その上，iPadとiPhoneは画面解像度が違いますから，UIデザインは二重作業です。

　ところでiPhone3G(S)からiPhone4では解像度が縦横２倍に変わりましたが，この場合のグラフィック処理も２倍で考えるのかと思っていましたが，実はiPhone4においてもプログラミング段階では320x480という座標値でプログラムを作ることになります。

　iPhone4ではそれが高解像度に自動変換されるということが売りのようです。ただし，アプリ内で使用する画像ファイルなどは，２倍の大きさで作り込んでおかないと，低解像度がそのまま引き延ばされた格好になるので見栄えしないというわけです。

　というわけで，新しいiOSでは，プログラミングの手間が増えるというよりも，グラフィック素材の準備に手間がかかるようになっています。どちらかといえば絵心が無くてプログラミングをしているような人間には，悩ましさが増している今日この頃です。

　CoreDataにストアしてあるデータをTableViewでセクションとインデックス付きで表示する際，CoreDataからセクション名を取得する方法があります。

　私が作っているアプリは主に電車の時刻表を扱うので，始発から終電までの発車時刻を並べて表示しています。その際，１時間毎にセクションにまとめて表示します。

　セクション名は，始発が朝５時で終電が夜中1時まであれば，5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,0,1という順番になることを意図しています（最後の方が24時，25時でなく0時，1時ってところがミソです）。

　最後の0,1は最初の5,6...よりも小さい数字ですが，データ取得する際のソート指定において内部的に24,26になるようにしてあるわけです。

--

　さて，

　セクション名を取得する方法としてNSFetchedResultsControllerに対してsectionsメソッドでセクションの集合を取り出し，ひとつひとつセクションを取り出して名前を取得していました。

　iPhone OS3.1.3までは，この方法で意図した順番にセクション名を取得できました。ところがiOS4上では，全く同じプログラムなのに取得されたセクション名の並び順が0,1,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23となってしまう挙動に変わってしまっています。

　最初は開発環境の変化で，諸々の設定が適切でなくなったせいなのかと，あれこれ設定を変えてみたのですが，現象に変化はなし。シミュレーターでも実機でもiPhone OS3.1.3では従来通り意図通り動作しているのですが，iOS4では並びが変わってしまいます。

--

■実験

　とにかく実験してみましょう...

○取得方法その１：セクション自体の集合を取得してひとつずつ名前を取り出す

NSArray* fetchedTitles1 = [fetchedResultsController sections];
for (id section in fetchedTitles1) {
NSLog(@"Sec %@",[section name]);
}

○取得方法その２：セクション名の配列を取得して名前を取り出す

NSArray* fetchedTitles2 = [fetchedResultsController sectionIndexTitles];
for (NSString *secname in fetchedTitles2) {
NSLog(@"SecNm: %@",secname);
}

　取得方法その２は，１文字しか取得してくれないので，10番台は「1」20番台は「2」にまとめられて表示されます。
　なお，今回の実験のデータは終電が0時台の時刻表を使用したので，0時だけが注目点になります。

■結果

【iPhone3G + iPhone OS3.1.3】意図した並び...

○取得方法その１
2010-07-17 03:52:31.996 RideOnTime[78:207] Sec 5
2010-07-17 03:52:32.002 RideOnTime[78:207] Sec 6
2010-07-17 03:52:32.007 RideOnTime[78:207] Sec 7
2010-07-17 03:52:32.013 RideOnTime[78:207] Sec 8
2010-07-17 03:52:32.019 RideOnTime[78:207] Sec 9
2010-07-17 03:52:32.024 RideOnTime[78:207] Sec 10
2010-07-17 03:52:32.030 RideOnTime[78:207] Sec 11
2010-07-17 03:52:32.044 RideOnTime[78:207] Sec 12
2010-07-17 03:52:32.050 RideOnTime[78:207] Sec 13
2010-07-17 03:52:32.055 RideOnTime[78:207] Sec 14
2010-07-17 03:52:32.060 RideOnTime[78:207] Sec 15
2010-07-17 03:52:32.065 RideOnTime[78:207] Sec 16
2010-07-17 03:52:32.071 RideOnTime[78:207] Sec 17
2010-07-17 03:52:32.077 RideOnTime[78:207] Sec 18
2010-07-17 03:52:32.083 RideOnTime[78:207] Sec 19
2010-07-17 03:52:32.089 RideOnTime[78:207] Sec 20
2010-07-17 03:52:32.094 RideOnTime[78:207] Sec 21
2010-07-17 03:52:32.099 RideOnTime[78:207] Sec 22
2010-07-17 03:52:32.156 RideOnTime[78:207] Sec 23
2010-07-17 03:52:32.167 RideOnTime[78:207] Sec 0

○取得方法その２
2010-07-17 03:52:38.298 RideOnTime[78:207] SecNm: 5
2010-07-17 03:52:38.305 RideOnTime[78:207] SecNm: 6
2010-07-17 03:52:38.310 RideOnTime[78:207] SecNm: 7
2010-07-17 03:52:38.316 RideOnTime[78:207] SecNm: 8
2010-07-17 03:52:38.321 RideOnTime[78:207] SecNm: 9
2010-07-17 03:52:38.326 RideOnTime[78:207] SecNm: 1
2010-07-17 03:52:38.331 RideOnTime[78:207] SecNm: 2
2010-07-17 03:52:38.338 RideOnTime[78:207] SecNm: 0

【iPhone3GS + iOS4】意図せざる並び...

○取得方法その１
2010-07-17 03:48:12.698 RideOnTime[497:307] Sec 0
2010-07-17 03:48:12.702 RideOnTime[497:307] Sec 5
2010-07-17 03:48:12.708 RideOnTime[497:307] Sec 6
2010-07-17 03:48:12.713 RideOnTime[497:307] Sec 7
2010-07-17 03:48:12.718 RideOnTime[497:307] Sec 8
2010-07-17 03:48:12.723 RideOnTime[497:307] Sec 9
2010-07-17 03:48:12.729 RideOnTime[497:307] Sec 10
2010-07-17 03:48:12.734 RideOnTime[497:307] Sec 11
2010-07-17 03:48:12.739 RideOnTime[497:307] Sec 12
2010-07-17 03:48:12.744 RideOnTime[497:307] Sec 13
2010-07-17 03:48:12.749 RideOnTime[497:307] Sec 14
2010-07-17 03:48:12.754 RideOnTime[497:307] Sec 15
2010-07-17 03:48:12.760 RideOnTime[497:307] Sec 16
2010-07-17 03:48:12.765 RideOnTime[497:307] Sec 17
2010-07-17 03:48:12.770 RideOnTime[497:307] Sec 18
2010-07-17 03:48:12.775 RideOnTime[497:307] Sec 19
2010-07-17 03:48:12.781 RideOnTime[497:307] Sec 20
2010-07-17 03:48:12.785 RideOnTime[497:307] Sec 21
2010-07-17 03:48:12.790 RideOnTime[497:307] Sec 22
2010-07-17 03:48:12.796 RideOnTime[497:307] Sec 23

○取得方法その２
2010-07-17 03:48:15.293 RideOnTime[497:307] SecNm: 0
2010-07-17 03:48:15.295 RideOnTime[497:307] SecNm: 5
2010-07-17 03:48:15.306 RideOnTime[497:307] SecNm: 6
2010-07-17 03:48:15.309 RideOnTime[497:307] SecNm: 7
2010-07-17 03:48:15.312 RideOnTime[497:307] SecNm: 8
2010-07-17 03:48:15.314 RideOnTime[497:307] SecNm: 9
2010-07-17 03:48:15.316 RideOnTime[497:307] SecNm: 1
2010-07-17 03:48:15.319 RideOnTime[497:307] SecNm: 2

--

　ご覧のようにiOS4だと0が始めに来てしまいます。おかげでセクションと時刻データとの組み合わせにもズレが生じて，TableViewが混乱してしまっています。

　デベロッパドキュメントにはinitWithFetchRequest:managedObjectContext:sectionNameKeyPath:cacheName:メソッドについて次のように書いてあります。

sectionNameKeyPath
A key path on result objects that returns the section name. Pass nil to indicate that the controller should generate a single section.

The section name is used to pre-compute the section information.

If this key path is not the same as that specified by the first sort descriptor in fetchRequest, they must generate the same relative orderings. For example, the first sort descriptor in fetchRequest might specify the key for a persistent property; sectionNameKeyPath might specify a key for a transient property derived from the persistent property.

　う〜む，iOS4ではこの記述通りになっていないような気がするのですが...。

　Core Dataを使ってアプリを開発しています。Macソフトを開発したときにかじったことがあるので，今回も3.0でCore Dataが採用されたことをいいことに（2.0ごめんなさい）データ管理はCore Dataに頼ってしまおうという魂胆。

　『iPhone SDK3プログラミング大全』や『サンプルプログラムでマスターするiPhone SDK』の解説を記憶呼び戻しに使いながら，通称「HMDTの赤本」（『Happy Macintosh Developing Time -Third Edition-』）のCore Dataページでおさらいをしていたのですが，やはりどうしてもスッキリしない。

　いや，実際アプリ自体は正しく動いているので，それでいいんだろうとは思うのだけど，どうしても言質が取りたいという気持ちがあって，公式ドキュメントもひっくり返してみたものの，こちらも状況証拠ばかり...。

--

　スッキリしていなかったのは，Core Dataのエンティティに基づく管理オブジェクト同士のリレーションを結びつける方法。リレーション関係にするつもりの管理オブジェクトを別個に生成したら，この関連をどうすれば登録できるのかについて，真正面から書いてくれているものがほとんど無かったのです。

　確かに公式ドキュメント「Core Data Programming Guide」の77-78頁には，「anEmployee.department = newDepartment;」というコードと後は全自動ですとかなんとか説明があります。あとはプログラミングやってりゃ分かるでしょ...的な空気が充満していて，「まぁ，そりゃそうだけど...」と流されてプログラミングはしているわけですが，う〜ん。

　日本語の解説書はほとんど一つのエンティティモデルの例だけを扱っていて，最も詳しいはずの赤本もMac開発だとIB中心の記述に留まってしまうため，モヤッと感は消えないままなのでした。

--

　最近ようやく「Core Data」の本が登場した模様。さっそく手に入れて読んでみました。副題に「Mac OS X」としか書いていませんが，実際にはiPhoneに関する記述も１章分載っています。

　さて，丸ごと一冊Core Dataの本ですから，私をスッキリさせてくれるのかどうか，気になりますが，その結果は。
　
　わ〜い！スッキリ！スッキリ！

　To-OneリレーションとTo-Manyリレーションに関する解説で，ハッキリと例示してくれました。To-Oneの場合では，

　NSManagedObject *foo = ...;
　NSManagedObject *wow = ...;
　[foo setValue:wow forKey:@"..."];

　ってな感じ（名前は改変してます）でインスタンスをセットすればいいのだと示してくれてました。To-Manyの場合はNSSet絡みでさらに納得のいく解説（それは本をお買いください...）。

　これで自信を持ってコーディングできます。この本，CoreDataの入門としては良さそうなので，誰か翻訳するといいのに...。

　Cocoaプログラミングにおいて，インターフェイス・ビルダー（Interface Builder: IBと略）の存在は大きいものです。昨今，たくさん出版されたiPhone向けのプログラミング本の多くも，まずはIBを使ってアプリの画面をデザインすることを紹介するところから始まります。

　IBは，その名前の通り，操作画面（インターフェイス）の構築（ビルダー）を行なう開発ツールです。まずは見た目をデザインして，あとから動作をプログラミングすることが出来るため，直感的とも言われます。

　しかもIBは，Cocoaプログラミングのパワーを利用しているので，コードを書くようなプログラミングをしなくても，IB上でインターフェイスを構築する操作の延長だけで，簡易なプログラムを完成できてしまう機能も持ちます。

　今日ではVisual BasicやFlashなどもポピュラーになり，この手の開発方法も目新しくはなくなりましたが，IBが登場した時代において革新的であったことに間違いはありません。

--

　しかし，IBが出来ることにも限りがあります。IBを起動してご覧いただければわかりますが，最初こそまっさらで分かりやすそうな顔をしています。ところが操作を始めて作業が進むと，次第に扱う要素や項目が増えて，全体を把握することが難しくなってくることに気がつきます。

　さらにIBで構築した画面を踏まえてコードによるプログラムを付け加えていく過程でエラーが発生すると，どこに問題があるのか追いかけることが難しくなるのです。IB上での作業の間違いなのか，コードの間違いなのか，あるいはその２つの接続部分なのか...，判別するだけでも大変です。

　そういう場合，ほとんどがIBでの設定忘れや接続間違いといった原因です。IBが用意する多彩な設定項目は柔軟性の象徴ではありますが，同時に，設定間違いを見落としがちな原因を作っているのです。

--

　もしCocoaプログラミングを本格的に挑戦したいということであれば，遅かれ早かれIBを使わない脱IBプログラミングにステップアップする必要が出てきます。

　「画面の部品を直感的に配置することが出来る」というIBの道具的なメリットを除けば，IBの操作で実現できることは，コードを直接書いて実現できます。

　特にiPhoneプログラミングは，Macと違って画面が320x480と比較的狭いため，自分で方眼紙に画面設計図を描いて，座標数値をコードで手入力しても労力はたかが知れています（その部分だけIBを利用して，座標をメモれば楽ですね）。

　このような脱IBプログラミングをすることによって，iPhoneのより高度なアプリ開発へステップアップすることも可能です。少なくとも，IBとの組み合わせで複雑化してしまうことを避けることが出来ます。

--

　もちろん，IBを完全に捨てる必要はありません。実際，IBはパパッと画面を作るのには便利です。直感的であることのメリットが全くなくなったわけではないのです。

　そのようなIBの存在を前提にしながら脱IBプログラミングを目指すことによって，初級から中級へのステップアップが出来るというところに，Cocoaプログラミングの楽しさがあります。

　ちなみに，このようなコードベースのiPhoneプログラミングについて書いているのが鳥の絵表紙の『iPhone SDK アプリケーション開発ガイド』（オライリー）です。プログラミングに慣れた方々の評価も高い本です。ただし，内容はSDK2.0ベースのため，新しい機能については触れられていません。

　同様にSDK2.0ベースですが，脱IB（コートベースの）プログラミングへ誘ってくれるのは『iPhoneデベロッパーズクックブック』（ソフトバンククリエイティブ）です。日本で最初に翻訳出版されたiPhone開発本ですが，実はコードベースのプログラミングによる本だったという点は興味深いです。

　
　アップル社の公式ドキュメント（開発関連文書）は，大半が英語のままで，日本語の翻訳されたものも限られるため，かなり敷居が高く受け止められていますが，実は結構親切な説明をしてくれています。

　日本語にも翻訳されている『Coding How-To's』という文書は，よく使うコードの塊を整理して紹介してくれているので，IBでIBで実現していることをコードでどう書くのかを知るのを手伝ってくれます。

　またコードに慣れた頃に，全体を見渡すつもりで『iPhone OSプログラミングガイド』を読んでみると，コードの背景がハッキリしてくるのを手助けしてくれるかも知れません。少々手強いので，技術解説文書に慣れていない頃にはチンプンカンプンかも知れませんが，必読であることには変わりありません。

　さらにアップル社としては『iPhoneヒューマンインターフェイスガイドライン』という文書も必ず読んで理解して欲しいと望んでいます。オリジナリティ溢れる独創的なアプリを開発する人たちにとっては目の上のたんこぶみたいな文書ですが，ベースとなるiPhoneに込められた設計思想を知ることも大事でしょう。

　以上の公式ドキュメントは，バージョンはともかく日本語翻訳されていますので，開発を進めていく過程で目を通すことをおすすめしておきます。

　書籍もそうですが，サンプル（書籍付録やアップル公式のもの）をいろいろ見ていくことも重要ですね。