Outletにはweakを使う

きっかけはひとつのツイートから。

.@mfks17 あ！IBoutletも弱参照か。。。 @iphone_dev_jp [@tokyopengwyn]

— iphone_dev_jp (@iphone_dev_jp) June 8, 2012

自分はARCを利用するようになってからもずっと、weakではなくstrongを使用してOutletをプロパティ宣言し、viewDidUnload:やdeallocの中でOutletにnilを設定する方法をとっていたのだけれど、それでは動作上に問題があるのだろうか。心配になり調べてみると、すぐに次のような記事を発見。
Outlet には weak を | Cocoaの日々情報局

結論からいうと、strongを使用してOutletをプロパティ宣言しておきviewDidUnload:やdeallocの中でそれらにnilを設定するという方法でも問題はない。が、上の記事でまとめられているとおり、次のような方針に従いweakを使用するというのがより適切な方法のようだ。

• 通常 UIButton などのパーツは Ownerになる親ビューが存在するので weak が適している
• ただしトップレベルのビュー（どのビューにも属さない）の場合はOwnerとなる親ビューが存在しないので strongにする

たしかに、コードがすっきりするし、何かの間違いで循環参照になってしまう危険性を回避することもできるので、言われてみるとこの実装方法の方が良いように感じられる。

まずは『Mobile Design Pattern Gallery』をサクッと読んでおけ

O'Reilly eBookのセール中に$9.99で購入した*1『Mobile Design Pattern Gallery』*2を先日読み終えた。

普段iOSアプリ制作を行なっている自分にとって興味深い話題を扱っている本だしセール期間中だったこともあり、勢いで購入して読み始めることになったのだが、英語で書かれた本を、しかもeBook（PDF/EPUB）という形式のものを、果たして自分はきちんと最後まで読み切ることができるのか、読み始めた当初は若干心配だった。ところが、いざ読み進めてみると、思いのほか抵抗なく読むことができた。そして、この本が今後の自分のiOSアプリ制作に力を与えてくれる本だということを実感した。感想をまとめてみることにする。

本書の良いところ

プラットフォームに依存せずにUIのありかたを考えられる

本書は章ごとに特定のUIの構成要素に着目し、その構成要素を使用しているアプリのスクリーンショットを実例として多数掲載している。実例として取り上げられているアプリは特定のプラットフォームに依存することなく、iOS、Android、BlackBerry、WebOS、Symbian、Windows Mobileといった多くのプラットフォームから選び抜かれている。また、章の冒頭ではその章で取り扱うデザインパターン全てをプラットフォームに依存しない簡略化された図で示されている。このような書き方により、読者はプラットフォームに依存せずにUIのありかたを考えられる。

アプリを制作するときにはまずOS標準で用意されているクラスを利用し、それでは実現できないものについては自作クラスを組み合わせて目的の機能を実現する。だが、制作されたアプリが目的の機能を備えているとしても、それが使いやすいアプリかどうかとなれば話は別だ。使いやすさを意識するということは、実現機能やプログラムの開発・保守の効率などとは違う観点からアプリ制作を考えるということだ。情報をどういう単位に分割しそれらの表示をどのタイミングで切り替えるのか、表示する情報はどのようにレイアウトすべきか、ユーザに快適に操作してもらうためにはどうすればいいのか、などなど。

このようなことを考えるときに、各プラットフォームで用意されているAPIの扱い方ではなく、プラットフォーム間で共通する表現方法に着目することにより、目的を果たすための実装方法をより広い視点から検討することができる。

書かれている内容を多面的に評価して考えを深められる

この本でアプリのあるべき姿を単に抽象的に語るのではなく、実際のアプリを多数取り上げている。自分でそのアプリの動作を確認することができるし、利用者のレビューを調べあげることもできる。アプリによっては既にバージョンアップされて本書での紹介内容とは異なるものになっているものもある。どこが変化しているのかを見てみるのも面白い。

復習しやすい構成

この本がいくら読みやすく参考になるものであったとしても、本の中に出ている数十というデザインパターンを一読しただけで全部頭の中に入れておくのは難しい。読んだときの感動だけが自分の中に残ってしまい、肝心の本の内容が残らないようではもったいない。

その点、この本は巻末でデザインパターンの一覧が用意されており、図と使用上の注意が添えられており簡単に復習できるようになっているのが良い。

eBookで読むことの強み

今回『Mobile Design Pattern Gallery』は主にiPadのiBooksで読み、電車などでの移動中には少しiPhoneのiBooksで読んだ（いずれもEPUB版で）。本の内容が良かったのに加えて、この読み方が快適だったのが印象深かった。

ケチらずにカラーで読める

『Mobile Design Pattern Gallery』は紙の本ではモノクロ版とカラー版の2種類があるようだ。

Mobile Design Pattern Gallery

Mobile Design Pattern Gallery, Color Edition

モノクロ版よりもカラー版の方が価格が高いが、この本は断然カラー版で読んだ方がいい。ひとつの画面上に複数存在しているオブジェクトのうち一部を区別したり選択状況や状態変化を画面表示に反映させる方法の例として示されているスクリーンショットが多いのだが、それらの内容を読み解くためにはカラー版の方が向いている。

eBookはカラー版で、紙のモノクロ版よりも安い。

スクリーンショットの実寸大表示ができる

iBooksのバージョン2.0あたりからだったと思うが、図表部分をダブルタップするとその図表のみを画面いっぱいに単独表示できるようになった。さらに、単独表示された図表はピンチイン／ピンチアウトで拡大縮小できる。

これによって何ができるようになるかというと、本に掲載されているiPhoneアプリのスクリーンショットを実寸大で表示して確認することができるのだ。各オブジェクトの大きさや余白幅などの感覚を掴むのにこれは大変面白い体験だった。

英語の文章は怖くない

本書はもともと図が豊富で、説明の文章は最低限に留められているのだが、ひとつの章に5個弱は意味のわからない単語があった。iBooksでは単語の上で長押しすると現れるメニューにより、英英辞書で単語の意味を調べることができる。これだけで文章の意味を概ね理解することができた。それでも意味のわからないところについては、関連するスクリーンショットを眺めるとほぼ確実にすぐ意味を把握することができた。読む流れが中断されることが少なく、すらすらと読み進めることができたのは良かった。

デザインに自信のないモバイルアプリ開発者は、まずこれを気軽に読めばいいのでは？

この本を読み進めながらその内容を同僚のデザイナーに話してみたら「そうなんですよー」とあっさりと返されることが多かった。つまり、この本はデザイナーにとってはある意味では当たり前のことがたくさん書かれているということらしい*3。たしかに、これまで彼からダメ出しをされたり説明を受けたりした点がいろいろと載っているような……。

プログラムを書くことが中心の人はSDKを使いこなすことの方により多くの力を注いでしまいがちな一方で、それだけをやっていても使い勝手の良いアプリが生まれないことは百も承知なのだ。でも、何から手を付けてどこまでそれを続けるといいのか、ひとりでは見当がつかないことも少なくないように思う。そういうときに本書が手元にあることは心強いものではないだろうか。

*1:本記事執筆時点での定価は$19.99。[http://shop.oreilly.com/product/0636920026419.do:title=http://shop.oreilly.com/product/0636920026419.do]

*2:専用サイトは[http://mobiledesignpatterngallery.com/:title=http://mobiledesignpatterngallery.com/]

*3:ただし、彼曰く、本書はデザイナーも読んでおくべき本とのこと。

白黒反転状態の電子書籍を暗闇で読んでみるテスト

まったく未知の読書体験をしてみよう | fladdict

上の記事で紹介されている読書体験をいつか試そうと思ったまま試さずに2ヶ月以上経ってしまったのだが、先ほどiBooksでEPUB形式のO'ReillyのeBooksを読んでいるときに、ふと思いつきでテーマを「夜間」にしてみたら簡単に試すことができた。ヘッドホンをiPhoneに接続して音楽を聞きながら暗闇で本を読むとさらに没入感が増す。

高校生の頃は寮暮らしをしていたのだけれど、小説の続きが気になったときには消灯後に布団の中にもぐって懐中電灯で照らしながら続きを読んだ*1ものだった。当然だけど、すごく暑かった。……と当時のことを考えて少し懐かしく感じたと同時に、10年経ってもあまり変化していない自分の生活ぶりに苦笑。

何はともあれ、便利な時代になったなぁ。

*1:そうしないと見まわりに来た寮教諭にバレる。

Xcodeに標準でついてくる帯域制限アプリ「Network Link Conditioner」

Xcodeに標準でついてくるNetwork Link Conditionerという帯域制限アプリが次の記事で紹介されていたので試してみた。
標準で付いてくる開発用ネットワーク帯域制限アプリ | Cocoaの日々情報局

導入方法

/Developer/Applications/Utilities/Network Link Conditioner/Network Link Conditioner.prefPane
を実行するとシステム環境設定の「その他」領域に「Network Link Conditioner」が追加され、すぐに使用することができる。

「Network Link Conditioner」と「SpeedLimit」

システム環境設定に追加する形式の帯域制限アプリとしては、Network Link ConditionerのほかにもSpeedLimitがある。SpeedLimitでは接続先ホストによる設定が可能なのに対し、Network Link ConditionerではパケットロスやDNS遅延などについての設定ができるようだ。通信速度の調整が主な目的の場合はNetwork Link Conditionerの方が使い勝手が良いと感じたので、基本的にNetwork Link Conditionerを使用し、必要に応じてSpeedLimitを代用するという使い分けになりそう。

参考

通信速度が非常に遅い時のAppの動作を確認する方法 - 甘いものが好きです

breakpointで停止すると必ずアセンブリコードが表示されてしまう状態を解決する方法

Xcodeをv4.3.1に更新した後あたりで気がついたのだが、デバッグ中にbreakpointで停止すると、該当箇所のソースコードではなくアセンブリコードが必ず表示されるようになってしまっていた。一応breakpointを設定したあたりで停止しているようなのだが、ステップ実行をしているときに変数の値を確認できない等の不都合に悩まされていた。

原因を調べてみると、まさに次のページで説明されているとおりだった。
Cocoaの日々: Xcode4.1 デバッグ時のアセンブリ表示からの脱出
Xcodeのメニューを「Product → Debug Workflow → Show Disassembly When Debugging」とたどり、この「Show Disassembly When Debugging」をオフにすると、ブレーク時に常にアセンブリコードが表示される問題は解決された。

Xcodeをv4.3からv4.3.1に更新

Mac App StoreでiOS 5.1に対応したXcode v4.3.1が公開されたので、さっそくインストールしてみた。

アップデート手順

Mac App Storeの「アップデート」タブからXcodeのアップデートを開始。アップデート完了後、Xcodeを起動すると初回起動時には「Xcode Component Installation」というウィンドウが表示され、「Mobile Device Framework」のインストールを求められる。

「Install」ボタンを押下すればこのFrameworkのインストールが実施される*1。Frameworkのインストールが完了すると「Installation complete」と表示されるので、「Restart Xcode」ボタンを押下してXcodeを再起動する。

*1:iTunesが起動中であれば、Mobile Device Frameworkインストール中にiTunesを終了するように指示される。

エラー「Couldn't register [App Identifier]」への対処

実機やシミュレータでiOS Appのデバッグをしようとすると、Appの起動前に次のようなエラーメッセージが出てAppが実行できないことがある。

Couldn't register App Identifier with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.

これは、前回デバッグしたときにXcodeが強制終了された等の原因により、実機またはMac（シミュレータでAppを実行した場合）に実行中ステータスが残っていることが原因。
実機でこの問題が発生した場合には、実機を再起動することにより問題が解決される。シミュレータでAppを実行していた場合の解決方法としては、次のページが参考になる。

iPhone - strange error when testing on simulator - Stack Overflow

参考

• iPhone - strange error when testing on simulator - Stack Overflow
• iPhoneでアプリケーションインストール中にエラーとなった場合の対処: iPhoneアプリ開発備忘録