カテゴリー : 開発

iPad Retina用画像リソースファイル名


iPad Retinaへの対応調査を進めているんだけど。

いま、うちのアプリで、iPhoneとiPadのUniversalで、使用する画像リソースがそれぞれ違う場合、次のように画像ファイルをネーミングしている。

  • image.png
  • image@2x.png
  • image~ipad.png

上から順に、iPhone、iPhone Retina、iPad用のファイルね。

では、これをiPad Retinaで動かすと、どの画像リソースが使われるでしょう?

シミュレータで動かした結果、答えはimage@2x.png。なんですとー!?お、おれは、きっとimage~ipad.pngが使われると勝手に期待していたのに。

ということで、image@2x~ipad.pngの画像ファイルを作成して追加するか、プログラムの方に手を加えてiPad Retinaでもimage~ipad.pngを使わせるか、っていう対応を迫られ中。

iPad Retinaのキーボードがでかい


キーボードがでかい!

 

 

iPad Retinaシミュレータがほんとに来た!


iPad 3rd generationが発表されて、予想通りXcodeもバージョンアップされて4.3.1が登場。

個人的にものすごく注目していた、iPad Retinaシミュレータだけど、

予想通りだった。

なんのひねりもなく、

でかいよ!

ちなみにRetinaじゃないiPadは、これ。

もはやかわいく見える。

横画面だと、まぁまぁ見える。

下が少し切れるけどね。こうやってみると、iPad 3rdは、iMac 27インチをあの大きさにギュッと縮めたものに直感的に近いな。

これからは、このでかさとつきあうのか。はー。

そういえば、iPad Retinaにすると、なぜか枠が消えるのね。そうなると、ホームボタンも消えてしまう。メニューから選べばホームに戻れるけど。これ、不便だよ。

正しいバグレポートの書き方:詳細編


先日の記事では、正しいバグレポートを書くには3つの情報を含めてほしい、ってことを書いた。実はこれって、バグレポートに限らず、すべてのコミュニケーションで気をつける事だよね。コミュニケーションは、自分が言いたい事を言うだけではだめで、相手が何を知らないかを推測しながらでないと成り立たない。メールみたいな、顔を突き合わせるわけではないコミュニケーションではなおさら。

これとは別に、バグレポートならではの情報ってのもある。詳細なバグレポートを書くには、この情報も必要だ。これもまとめてみた。ただ、一般ユーザにここまで求めるのは酷なので、無理にやらなくてもいいですよ。開発プロセスでテストを行うときは、テスターの人にはこういった情報を要求しているので参考までに。

デバイスの名前、iOSとアプリのバージョン
問題が発生したデバイスはの、正確な名前は?「iPhone!」それは正確じゃない。iPhoneたくさんの機種が出ているんで。iPhoneのどの機種?「白いiPhone!」それもあんまり正確じゃない。でも実は、この情報でiPhone 4以降ということは絞り込めたりする。ちゃんと、iPhone 3GSとか、iPhone 4とか、iPad 2とか、iPod touch 3rd generationとかって教えて。ただデバイスに名前書いてないから、分からない人は分からないよね。こういうときAppleの美意識は不便だ。

あと、iOSのバージョン、およびアプリのバージョンも教えて。できれば、アプリの名前も。意外に多いのが、アプリの名前が書かれていないバグレポート。アプリ毎にアドレスを用意できるような大きい会社ならいいけど、サポートのメールアドレスが1つしかない場合、何のアプリの問題なのか分からない。頭をフルスロットルで回転させて、文脈から想像する事になる。リアル推理小説だ。

正しい用語を使う
iPhoneの部品やiOSのユーザインタフェースは、名前がきちんと決められている。この定義された名前をきちんと使ってほしい。たとえば、よくアプリケーションの上部にあって、戻るボタンなんかが配置されていて、タイトルが書いてあるバーの名前は?答えは、ナビゲーションバー。よくある間違えは、ツールバー。

中途半端に間違った名前を使うよりは、「上の方にあるバー」とか、「右上にある三角のボタン」とか言ってもらった方が、実は問題が少ない。ベタだけど誤解が発生しないものの方がいい。重要なのは意図を正確に伝える事で、スマートに見せかける事ではない。

再現手順の確立
これが、いちばん重要な情報。問題が発生したとき、その問題をどうやればもう一度起こす事ができるのか、その手順が知りたい。これはもう、のどから手がでるほど知りたい。

もし再現手順が確立できれば、その問題はかなりの確率で修正する事ができる。逆にどうやって発生したのか分からない問題は、非常にてこずることになる。バグ修正作業の大きな時間を取られるのは、再現手順を調べる事だったりする。

再現率
再現手順と並んで重要なのが、再現率。どの程度の頻度でその問題が発生した?毎回?たまに?それとも、1回だけ?もちろん、再現率が高い問題の方が、修正しやすい。テスターの人にお願いするときは、100回の試行中に何回発生したか、という風に報告してもらう。

クラッシュレポート
アプリはクラッシュしたときに、どこでクラッシュしたのかを吐き出してくれる。これがクラッシュレポート。実はクラッシュレポートは、アプリの中に蓄積されている。これがあるタイミングでAppleに送信されて、開発者が参照する事ができる。クラッシュレポートが集まってくれば、問題は修正しやすい。

いつ送信されるかというと、iPhoneをiTunesと同期するときに、「お使いのiPhoneには、アップルが製品を改善するうえで役立つ診断情報が保存されています」とかいうアラートが出るときがあるでしょ。あのとき。あそこで「アップルに送信」を押すと、クラッシュレポートが送られるはず。これが役に立つので、送ってくれれば嬉しいです。

正しいバクレポートの書き方


HMDTでは、主にコンシューマ向けのアプリを多く作ってます。いろんな人に使ってもらえるんで、これは純粋に楽しいです。でも開発作業って楽しい事だけじゃなくて、バグ対応っていう辛い事にも向き合わなくちゃいけないんですよ。

大前提として、一般向けにリリースしたアプリにバグがあってはいけません。バグ込みでリリースする気持ちはないです。でも、これまた避ける事のできない真理として、完全にバグのないソフトウェアを作るのはほぼ不可能です。

現実には、ユーザからバグを報告してもらい、それに対応して新しいバージョンをリリースすることを繰り返す事になります。HMDTでもたくさんのバグ報告をもらうんですけど、それはどれもありがたいんですけど、なかなか有益なバグレポートってのは難しいんだなあ、って思うんですよ。レポートはもらうんですけど、ごめん、これだとこっちも対応できないんだよ、っていうものが多いんですよ。なので、いったいどういうバグレポートが有効なのか、どういう情報が必要とされているのか、ってのをまとめてみました。

ちなみに、バグレポートって、どうしても感情的なものが多いです。気持ちは分かります。そりゃ、私だってゲームしている最中にクラッシュされたら、怒りのメールを送りたくなりますよ。そこは思いの丈をぶつけてください。でも、バグを修正して品質を改善するために、どうしても欲しい情報があるんで、それだけ教えてください。

そんな難しい話じゃないです。バグレポートの基本は、次の3つの情報を記載する事です。

1. どんな操作をして、
2. どんな結果を期待していたのに、
3. どんな結末になった。

この3つです。この3つがあれば、バグ潰しの旅にでかけることができます。逆にこれがないと、どうにもこうにも手を出す事ができません。

例を出しましょう。

良くない例:
「クラッシュした。」

クラッシュしましたか、ごめんなさい。ほんと申し訳ないです。そのバグ直したいんですけど、これだけじゃ手も足も出ないんですよ。これは、「3. どんな結末になった」だけが書いてある例です。「1. どんな操作をして」と「2. どんな結果を期待していたのに」も書いてくれると助かります。

良くない例:
「Webブラウザで、指定したWebページが開かなかった。」

開かなかったですか、ごめんなさい。それは問題ですよね。でも、どうやってWebページを開こうと思ったのか、教えていただけませんか。テキストフィールドにURLを入力しましたか?ブックマークから開こうとしましたか?それとも、文中のリンクをタップしましたか?「1. どんな操作をした」のか教えてください。

「どんな操作をしたかなんて、自明じゃん」と、思うかもしれません。でも、そのユーザにとってWebページを開く方法は一つしかなくても、アプリ全体では複数の方法が用意されているものなんです。なので、それをあえて書いてください。

良くない例:
「ツールバーの停止ボタンを押して、ムービーの再生を止めようとした。」

停止ボタンを押しましたか、ごめんなさい。それで、えーっと、どうなりましたか。「3. どんな結末に」なりましたか。ボタンを押したら、クラッシュしましたか?ボタンを押したら、ムービーの表示が乱れましたか?ボタンを押したら、鳩が出てきて飛んでいきましたか?それとも、ボタンを押しても、何も起こりませんでしたか?「何も起きなかった」というのも、立派な結末です。ぜひ、教えてください。

こういうレポート、冗談みたいでしょう。でも、とても多いです。ほんと多いです。こういったものを受け取ると自分が能無しの犯罪人のような気分になって、山奥に隠れ住みたくなります。

ソフトウェアの品質ってのは、ユーザとプログラマの間でやり取りをしながら高めていくのが理想です。そのためには、ポイントを押さえたレポートが欲しいです。ということで、ちょっとだけ気にしてもらえると嬉しいです。しかし、バグの話になると、どうしても下手に出る気分になるね。

Yellow SubmarineとiPad電子教科書(追記あり)


HMDTでは、定期的にエンジニアの人たちで、内部で技術プレゼンをやっている。内容は、日々の仕事を通して得られた、他の人の参考になりそうなプログラミング情報を共有する事。なかなか面白いです。

で、先日の発表で出てきたネタをご紹介。去年の12月に、iBookstoreから「The Beatles Yellow Submarine」という絵本がリリースされた。もちろん、ビートルズのYellow Submarineだ。その技術的な調査と将来の展望について。

このYellow Submarineは、マルチメディアでインタラクティブな絵本になっている。以下の機能があることが確認された。

・複数のフォントおよびサイズの混在したテキスト表示
・自由なテキストレイアウト。曲線にそったものもあり
・オーディオの再生
・テキスト、図版、ムービーの重ね合わせ
・ムービーのインラインおよびフルスクリーンでの再生
・テキストの読み上げ。読み上げ中にテキストをハイライト表示
・図版のアニメーション
・図版のドラッグでの移動

などなど。いかにもiPadらしさを活用した絵本だ。ダウンロードして触ってもらうのがいちばん分かりやすい。

ただ、これだけならApp Storeにたくさん登場している絵本アプリでも実現している。というか、そっちの方がもっとリッチなものがある。Yellow Submarineが興味深いのは、これらをどうやって実現しているかだ。

Yellow Submarineはアプリではなく、iBooksで表示するドキュメントの体裁を取っている。そのフォーマットは、EPUBだ。つまり、HTML、CSS、JavaScriptで、レイアウトやアニメーションを行っているのだ。HTMLはFixedレイアウト。テキストの読み上げタイミングの制御には、SMILが使われていた。EPUBに含まれる標準技術で、これだけの絵本を作れるという実証になっている訳だ。

ただし、HTMLやJavaScriptファイルは、暗号化されていた。おそらくFairPlayで。だから内容は確認できなかったし、他のEPUBビューワでの再生もできないだろう。

で、こっからは予測になるけど、Appleから1月19日にイベントが行われる事が告知されている。噂によると、電子教科書関連の発表になるらしい。となると、その機能やアピアランスは、このYellow Submarineで実現されているものに近くなるんじゃないだろうか。つまり、自由なテキストレイアウト、図版やムービーの重ね合わせ、インタラクティブ、テキストの読み上げとハイライト。フォーマットはEPUB。FairPlayで暗号化。配信にはiBookstoreを使う。と、いった感じで。

でも、こんなリッチな教科書をどうやって作ろうか。ここで思いをめぐらせると、Appleが作っていたHTML、CSS、JavaScriptオーサリングツールとして、Dashcodeがあったじゃないか。DashcodeはDashboardウィジェットをWYSIWYGで開発できるツール。とてもよくできていたんだけど、Dashboardがまったく流行らなかったので、表舞台に立つ事はなかった。Dashcodeの特徴は、HTMLを編集するんだけど、完全にFixedレイアウトでデザインすること。これって今回のYellow Submarine向きじゃない。

ということで、イベントではiPad教科書用のオーサリングツールも同時に発表されるだろう、と予想。これが出たら、電子書籍の起爆剤になるだろう。それに、Flashがなくなったことによるインタラクティブアニメーションツールの不在という問題も解決する事になる。

ま、これは予想というよりも願望に近いな。

 

17日15時追記:推論からこの記事を書いたんだけど、他のサイトからこんな記事も。GarageBand for e-booksって言い方はテクノロジーベースで考えると不適切だと思うけど。でも、ツールが出るかもしれないって話が噂サイトからも出てくると、それは盛り上がるね。

iPad 3が脅威なワケ


iPad 3の噂がまたいろいろ出てきた。話の焦点は、iPadでもRetinaディスプレイを搭載するとこのこと。まぁ、噂屋はその程度しか思いつかないんだろうけど。

しかし!iPadのRetinaディスプレイ搭載は、大きな脅威となる。アプリの開発者にとって。なぜか。

iOSアプリの開発ってのは、シミュレータを使って行われるんだよね。たとえば、iPhoneシミュレータを27インチiMacで動作させるとこんな感じ。

この中でアプリをテストする。かわいいね。

iPhone 4が登場したときは、シミュレータもRetina対応になった。Retinaディスプレイだと、ピクセル数が縦横それぞれ2倍になったので、シミュレータもこんな感じになった。

大きくなったぜ。アイコンもでかいし。シミュレータのウインドウの立て幅は1,048ピクセル。iMacならいいけど、15インチMacBookだとはみでる。開発機材を選ぶんだよね。

で。iPadシミュレータは、現状こうなっている。

これがRetinaディスプレイになるということは、予想図はこうなる。

イヤァァァァ!ぜんぜん入んない。こんなん、どうやって開発しろと。もちろん50%縮小モードで表示とかできるんだけど、それだとちゃんと高精度で動いているかどうか分かんないし。40インチiMacが必要だ。または、iMac with Retinaディスプレイが。

つーか、モバイル機器のディスプレイ解像度がデスクトップを上回るなんて、どんな時代よ。

ドキュメント中心のFiderのために


ドキュメント中心のFinderのために、TSADocumentManagerViewControllerというクラス名を忘れないようにここに書いておく。

ドキュメント中心のFinder


iOSはその設計思想として、ファイルの存在をできるだけユーザに意識させないものとして作られたと思う。いちばん分かりやすいのが、Finderに相当するものがない、ってことだよね。OS Xにおいては、一番最初にユーザの目に触れて、ファイルを管理するためのアプリであるFinder。これがiOSではSpringBoardにとってかわり、アプリの起動しかできなくなった。ユーザは裏にあるファイルを、意識する事も操作する事も出来ない。まぁ、最初はこれで良かったと思うよ。

でも、iOSに対するユーザの要求は爆発的に増加した。アプリに対して、単なるビューワ機能だけでなく、編集機能も求められた。そうなると、どうしてもファイルシステムを見せざるを得んのだわ。

たとえば、Keynoteあるでしょ、iOS版の。あれ、起動すると最初にドキュメントの選択画面が出てくるじゃない。これってつまりはオープンダイアログだよね。Keynoteは作業結果をドキュメントとして保存するから、どうしたってそれを開く画面が必要になる。これって、結局ファイルシステムじゃない?

いや、反論してみよう。Keynoteのオープンダイアログに表示されるのは、Keynoteで開くドキュメントだけだ。それにファイルシステムそのものを表示している訳じゃない。この画面に表示されているドキュメントと、実際にファイルシステム内部に存在しているファイルは、1対1対応する必要はない(対応しているものもあるけど)。それにiCloud対応しているから、ファイルがどこにあるかをユーザが意識する必要はない。そういった意味では、ファイル中心というよりはドキュメント中心って呼ぶのがしっくりくるかもしれない。

じゃあ、ひるがえって自分で開発するアプリのことを考えてみる。そうすると、Keynoteみたいなオープンダイアログを自前で作らなきゃいけないことになる。うわ、めんどくせ。それこそ、OSでFinderみたいなものを用意してよ。

それに、アプリ毎にドキュメントを管理するんじゃなくて、用途毎にドキュメントを管理したい、って欲求もあるでしょ。たとえば、ある案件に対するKeynoteドキュメント、Numbersドキュメント、Pagesドキュメントをひとつにまとめたい、思うのは当然だよね。でも、いまのiOSじゃそういった要求に対応できない。プログラミングの観点からすると、iOS 5でiCloudが導入された事により、ドキュメントベースのアプリケーションにスイッチするための枠組みは出来上がっている。そういったアプリが作成したドキュメントをまとめておけるはず。

こうやって考えていくと、次のバージョンのiOSではFinderに相当する何か、が必要になるはず。それはドキュメント中心の概念を表したものになるはずだ。

UIColorに便利なDeveloper Color Picker


社員の人から教えてもらった話。

PanicがDeveloper Color PickerっていうcolorPickerファイルを配布している。~/Library/ColorPickersの下にインストールすると、標準のカラーピッカーにタブが追加される。「Developer」という名称が付いているように、開発者向けのピッカー。開発者向け?

何をやってくれるかというと、選択した色のためのUIColorやNSColorのインスタンスを作成するためのソースコードをクリップボードにコピーしてくれる。こんな感じで。

[UIColor colorWithWhite:0.855 alpha:1.000]

コードのテンプレートも、色々な種類が用意されている。

いままでは標準のカラーピッカーで色を見つけて、それを255で割って、それでソースコード書いていたけど、これを使うと楽になりそう。