UIScrollViewのcontentOffsetでスクロール位置にオフセットを付けてバーにめり込んでいるように見せかけるのが正解だと思う。

たしかに、UIScrollViewをおいても同じことができます。ただ、それを言い出せばUIScrollViewでなくともUIViewControllerのビューにもうひとつUIViewを作ってその上にコンテンツをいろいろのせておいて、そのUIViewのオフセットを (0, -44) とかに設定しておいてもいいでしょう。この方法でもいいんですが、あえてこの方法を使っていないのには理由があります。UINavigationBarは必要に応じて表示したり消したりすることがあります。バーを表示しているときは UIScrollViewのオフセットを(0, -44)にして、非表示のときには (0, 0)に戻して、などと処理をすることは面倒なだけでなく、思わぬバグを招くことが多いのです。コメントを頂いたような方法を使っていないのは上述のバグを生まないようなコードにしたいというのが最大の理由です。可読性もあがりますし、あちこちに注意書きを書かなくてすみます。
またUIScrollViewで実際に何かをスクロールさせているような場合のときは、オフセットを(x, -44)にするだけでなく、frameサイズも適切に設定してやらないとpagingEnabled=YESのときスクロール時のストップ位置が思わぬところになってしまったり、より面倒くさい事態になりそうなので個人的にはこの目的のためにUIScrollViewを使うというのは好みではありません。
一方で前エントリで紹介した方法のリスクとしては、iOSの仕様がかわって挙動がかわってしまうことがあげられます。ただこのリスクは個人的には、オフセットを操作してやる方法でも大差ないと考えています。

最後に、どんな実装が最適なのかは制約事項とユースケース次第で状況によると思いますので「〜〜が正解だと思う」というのは一概にいえなくて、多種多様な実装方式のメリット／デメリットを押さえていくのがこれまたiOSプログラミング道だと思っています。いろんな実装方式があると思っていますので、いろいろ教えてもらえるとありがたいです。今回のようなコメントを頂くことで、仮説と検証もより深みを持ちそうです。id:rryuさん、コメントありがとうございました。

translucentがNOであるような、UINavigationBarを表示するとUIViewController自体のoriginが(0, 44)などになる。

translucentをYESにして、透明にすれば問題はすぐ解決しますが、表現の問題として時には半透明でない方がよい場合が有ります。そういった状況に対処する方法です。UINavigationBarはtranslucentをYESにしておき、backgroundColorを設定してやればうまく行きます。

ViewController側で次のようにコーディングすればよいでしょう。

- (void)viewDidAppear:(BOOL)animated {

self.navigationController.navigationBar.translucent = YES;

self.navigationController.navigationBar.backgroundColor = [UIColor blackColor];

こういう要求に対するコーディング、わかってしまえば簡単なんですが調べるのには結構時間がかかってしまうものなんです・・。

まず画面のレイアウトです。XcodeはEclipseやNetBeansなどほかの開発環境と比べてかなり広く画面を使うため、画面の領域をどれだけ節約できるかが細かな時間の節約になります。レイアウトは3種類選ぶことができますが、個人的にはCondensedがおすすめです。

DefaultやAll-in-Oneのレイアウトでは、ターゲットやファイルのペインとエディタが統合されていますが個人的にはこれらは別々の方が使いやすいと感じています。もともと俯瞰的にコードを眺めるためエディタのエリアは広くとりたいと思っています。このためには、エディタがウインドウの一部に統合されているより独立している方が便利です。Xcodeは一つのファイルに長々とコードを書くとパフォーマンスが劇的に悪くなる、また設計／管理の観点からもファイルは意味のある小さな単位に分割しておくべきですからファイルブラウザとエディタは分離していた方が心理的にも分かりやすいからです。

このほかのカスタマイズはキーボードショートカットの変更が一点。Developer Documentationの検索をFirefoxの検索ショートカットと合わせてCmd+Kに割り当てています。

Xcodeのカスタマイズは以上2点です。

iOS向けプログラミングでは、開発環境はMac上のXcode、開発言語はObjective-Cを使います。さらに実際のiPhoneやiPadといったデバイス上で自作アプリを動作チェックするためには有償の開発者登録(10,800円/年)が必要です。この開発者登録が高いと感じるか、安いと感じるかは人それぞれの感覚次第かと思いますが個人的にはアプリの審査と親切なフィードバック／iOS上に繰り広げられているビジネスモデルへの参加価値といった点から開発者登録は割安に感じるぐらいの価値があると思っています。

さて、実際のプログラミングですがObjective-Cという、C++/Javaなどの言語の経験をバックグラウンド持っている自分としてはやや取っ付きにくい言語を使います。このことを取り上げてiOS向けプログラミングは難しいと言う人も時々見聞きしますが、個人的には言語の持つ文法やコンセプトの違いは最終的なプログラムにさほど大きな影響をもたらさないと思っています。開発生産性の違いを指摘する人もいますが、今や開発言語は言語自体の開発生産性だけで語れるものではなく、フレームワーク、開発環境など開発を取り巻く全体をみて判断する必要が有ります。では、iOS向けXcode、Cocoa Touch、Objective-Cの組み合わせはどうでしょうか。

開発環境 Xcode は、EclipseやNetBeansなどモダンなJava開発環境に慣れた人にとっては力不足感を感じると思います。Microsoftの開発環境はさほど詳しくないので評価しづらいですが、すこし使った経験だけで判断してもVisual Studioは十分に洗練されており、Xcode は発展途上という言い方をされてやむを得ない差があると感じます。シンタックスエラーの検出、入力補完は今やリアルタイムに実施されるのが当然ですが Xcode にはそれが有りません。バージョン管理システムとの親和性もまだまだ改善の余地を感じます。Xcodeの力不足感、Objective-Cの文法への戸惑いはiOS向けアプリケーション開発にとって最大の心理的障壁といっても過言ではないようにも思えてきます。次期メジャーバージョン Xcode 4 Betaも少し試用しましたがようやくモダンな機能がいくつか追加されたものの、Eclipse、NetBeans、Visual Studioに追いつくにはまだ数年を要するのではないかと感じました。

さて、一方でiOS向けフレームワークCocoa Touchはどうでしょうか。今まで主にJavaベースで、いくつかのリッチクライアント・フレームワークを使ってきましたがCocoa Touchほど洗練されたフレームワークは無いだろうという印象を持ちます。APIドキュメントの説明が不足しているが為に生産性を損なっていることも有りますが、枯れたMVCモデルを採用しつつもモダンに仕上がったAPI郡は圧巻です。iPhone/iPadはAppleがハードウエアから、OS、フレームワークまで一貫して製造しているためフレームワークがデバイスに最適化されているということは当然です。ハードウエア/OSの組み合わせに最適化されているからこそ、「特殊な状況下におけるバグ回避のコード」をほとんど書かずにすみます。全くゼロというわけではありませんが、今までに経験したハードウエア、OS、フレームワークの組み合わせの中では最も少ないと思っています。この効果は絶大です。Xcodeが押し下げている開発生産性を補って十分なメリットを感じます。

機種依存やバグ回避のコードをほとんど書かなくてよいがために、フレームワーク上にバグ回避フレームワークを作り上げる必要が有りません。Cocoa Touchを直に使った方が生産性が上がり、パフォーマンスも損なわれません。Cocoa TouchのAPI郡は既に十分抽象化されているためこれ以上ラッパーやGlueコードを書くことは多くの場合無意味です。このため、iOS向けアプリケーション開発ではいかにCocoa Touchのコンセプトをつかみ、APIを正しく使えるかが開発生産性だけでなく最終的なアプリケーションコードの品質を左右するといって言い過ぎではないでしょう。

ググって調べた情報を鵜呑みにして開発するのではなく、しっかりとコンセプトの再確認と自身による検証がiOS向けアプリケーション開発では「急がば回れ」になる。ということがこの半年の開発経験による結論です。また、次回以降のメモではもう少し具体的な検証結果を残していくことにします。

言語環境を変更するにはシステム環境設定から、言語とテキストで順番を入れ替えるだけ。?さて、英語環境にしたときに困るのが、いくつかのアプリケーションは日本語環境でなければ正常に動作しないこと。Illustrator、Photoshop、Safariあたりがそう。Illustratorはプラグインの読み込みにいくつか失敗し、Photoshopは実用上困ったことはないけれど一部メニューが文字化け、SafariはAccept-Languageがenになって一部Webが文字化け。そういうときには、個別にアプリケーションに対して言語設定を実施。Mac OS X 10.5 LeopardまではFinder.appから設定できたけど、Snow Leopardではできない模様。

コマンドラインで次のように入力。

defaults write $(mdls -name kMDItemCFBundleIdentifier -raw /Applications/Adobe\ Illustrator\ CS4/Adobe\ Illustrator.app) AppleLanguage “(ja)”

のように入力してアプリケーションを再起動すれば完了。

少し前の話ですが、7月末頃、iOS 4.0からiOS 4.0.1にアップデートしようとしたところ、「iPhone”iPhone”を復元できませんでした。不明なエラーが発生しました(9)」というエラーがでてアップデートが完了しません。iMacを再起動してみたり、MacBook Pro側で試してみたり、違うUSBポートから実行してみたりなどかなり多くのパターンを試してみましたがどのパターンもだめ。

何度試してもiPhone 4側にiTunesにつないで復旧せよ、という表示のまま。仕方なく、渋谷のApple Storeへ持ち込み。Apple Storeでも現象が再現し、iPhone 4本体は交換となり無事復旧しました。

ちなみに交換してもらったため、本体への技適マーク表記がなくなっています。iOS 4は技適マーク表記があるので電波法上問題はありませんが、本体に印字されているという希少価値がなくなったのはちょっと残念。まあ、新しくなったのでよしとしましょう。

ブログに書くのが遅くなりましたが、iPhone 4が届きました(6月29日)。2年間つかったインターネットマシンことSoftBank 922SHからの機種変。なんだかんだ、届いてから1ヶ月ぐらいですね。

Retina Displayは確かにおそろしくきれい。デバイスの持つ表現力もさることながら、iOS自体もこれに向けて周到に準備が整えられていたのが大きいと思います。高ppi対応は記憶が正しければ、Mac OS X Leopardあたりから本格的に入り始めたので3年の月日をかけて熟成させ、MacではなくiPhoneに最初に導入された訳です。WindowsもVistaからは高ppi対応が入っていて、2007年当時、これからはディスプレイが「○?○万画素！」と謳われて電気屋で売られる想像を当時していましたが予想は外れて、2010年ようやくスマートフォンがその戦いを始めようとしているようです。

iPhone 4を約１ヶ月使っての感想です。iPhone 3GSも平行して使っていますが、使ってみるとiPhone 4は確かに優れていますがiPhone 3GSを置き換えるほどではないことに気づきました。なぜなら同じアプリがiTunesによって同期され、Mobile Meによってメールや連絡先などの情報は同期されているので使い勝手は何ら変わらないからです。言い換えれば、iPhoneの魅力はやはりアプリであって、iPhoneというデバイス自体の機能や性能差というのは微々たるものだと感じるようになりました。

メディアファクトリー様からリリースされた「ダーリンは外国人 in English」の電子書籍アプリ。こちらも、東京カレンダーと同様、NetFront Magazine Viewerをお使いいただいています。「ダーリンは外国人 in English」は「英語のみ」「英語と日本語」を切り替えるモードがあり、英語の学習教材としても便利です。

ついに、ウチにもiPadが届きました。モデルは悩んだ末、Wifi版の64GBです。3Gは、主にGPSのために確かに欲しかったんですが、いろいろとユースケースを考えた結果Wifi版にしました。今回、うちのiPadのユースケースとして最も活躍してもらおうと思っているのがフォトストレージとしての機能。別売のカメラ接続キットをつなげばSDカードあるいは、カメラから直接写真を取り込むことが出来ます。少なくとも試した限り、NikonのRAWフォーマット(NEF)も読み込むことが出来ます。

今回は、ひとまずiPad本体、ケース、カメラ接続キットを購入。

3G版ではないiPadのためにPocket Wifiを事前に購入済み。しかも、Emobileの契約が今月でちょうど2年だったため追加購入で1円です。

さて、iPadを少し本格的に個人使用として使ってみましたが、ゲームや地図、写真はもちろんのこと、少々の仕事もできそうです。Mac向けで有名なドローソフトOmniGraffleのiPad版を使ってホビープロジェクトのアプリ設計図を描いてみました。5,800円と(iPadアプリとしては)少し高めなこと、まだ日本語が使えない点を考えるとまだまだですが、確かにOmniGraffleの操作感が再現されています。一通りクラス図まで描き終えてみましたが、マウス＋キーボードで作業するのと比べれば圧倒的に作業効率は悪いし、まだまだバグもたくさんあります。しかしながら、紙にペンで書いていくのと同じぐらいのテンポで描かざるを得ないことによって、思考はそれなりに深くなるような、そうでもないような。