Previous month:
April 2010
Next month:
June 2010

iPadアプリ第二弾予告:書き心地重視の「手書きノート」アプリ

Drawing-3   iPadアプリの第二弾は、Adobe Idea に真っ向から挑戦する「手書きノート」アプリ。日本でのiPadの発売に会わせてリリースする予定だったのだが、ささいな点でアップルの審査に引っかかり、再審査中。数日中にはiTunesストアに並ぶと思うので(もちろん無料)、乞うご期待。

 ちなみに、用途はちょっとしたメモ帳代わり。思いついたことを書き留めたり、ミーティングや授業のノート取りに使ったり、ということをメインの使用シーンと想定して設計している。簡単なイラストとか、マインドマップとかを書くのにも向いていると思う。

 当然、書いたメモをPNGやPDFファイルとしてメールで送ることもできるし、それをIllustratorにベクターデータとして渡してさらに加工することも可能だ。

 特徴は使いやすさと、手書き感覚の気持ち良さ。Adobe Ideaは機能的には良く出来ていると思うんだが、使い勝手が悪いのと、曲線のスムージングの具合が好きになれない。そこで、特に「使い勝手」と「描き心地」に力を入れて開発したのがこのアプリだ。リリースされた際には、ぜひともAdobe Idea と使い心地・書き心地を比較していただきたい。

 ちなみに、先日あるところで自己紹介をする機会があったので、このソフトを使って私の経歴を一枚の絵にしてみた。フォーム化された履歴書やなんかよりずっと楽しいと思うんだがいかがだろう。


日本でのiPadローンチ、一夜明けて

 普通のことは色々なことが書いているので、とりあえず「私が」感じたこと思ったことをつらつらと書いてみる。

1. 孫さんすごい

 iPadのローンチは、どの国でもあくまで「Appleの」ローンチ・イベントであったはずなのに、それを「Softbankの」ローンチ・イベントにしてしまった手腕はすごい。本来ならメディアは銀座のアップルストアに並ぶ人の行列を映すべきなのに、一番注目されたのは表参道のSoftbankに並ぶ人の行列だったということは注目に値する。最近のSoftbankショップは、Look&FeelがまるでAppleストアであることを考えれば、昨今のAppleのブランド力の急上昇に相乗りする形でSoftbankのブランド力を上げる、というマーケティング戦略がとてもうまく行っていると言える。「SIMロックはかけない」はずだったiPadに、日本でだけSIMロックをかけさせるなど、その交渉力は天下一品だ。日本の外務省にも孫さんぐらいの交渉力の人がいれば、米国の言いなりになどにならずにすむのに...

2. CloudReadersの評判が良いのは良いが、サーバーが...

 CloudReadersのバックエンドである「クラウド本棚」はGoogle App Engineで構築してあるが、1ヶ月以上運営してきて、「これぐらいのダウンロード数ならこのくらいのトラフィック」という感触はあったので、日本でのローンチにあわせて、3倍の余裕を持たせて用意しておいたのだが、予想をはるかにこえるダウンロードがあり、App Engine が Over Quota に。すぐに修正しようとしたところ、AppEngineのAdmin 画面のUIがおかしく変更ができないので、そのまま今日になってしまった。困ったものだ。

 ◇ ◇ ◇ 

 もっと書くことはあるのだが、飛行機の最終搭乗のお知らせが入ったので、今日はここまで。


HTML5 Widget入門:あなたにも作れるiPad用Widget

 今朝の「iPadでHTML5 Widgetを走らせて遊ぼう」に対して、「もう少しWidgetについて知りたい」との声が聞こえてきたので、「Widget入門編」を書いてみようかと思う。

Widgetとは何か?

 先のエントリーで書いたが、ひとことで言えば「パッケージ化されたウェブアプリケーションである」。通常のウェブアプリは、特定のURLにアクセスすることにより走らせるが、Widgetの場合は、.wgt のエクステンションを持つWidgetファイルをダウンロード+インストールした上で、それを起動する。

 Widgetファイルの中身は、HTML+CSS+JS+メディア・ファイルで構成されており、それをZIP圧縮して、エクステンションを.wgtに変更しただけのものである。

 なぜそんなことをするかと言えば、(1)オフラインで動かしたい、(2)通常のデスクトップアプリの感覚で起動したい、(3)パッケージの形で流通・販売したい、などが理由であり、基本概念はAdobeのAIRと同じである。

なぜWidgetが注目されはじめたのか?

 この業界で、Widgetという言葉を良く聞く様になったのは、ここ2〜3年。ちょうどiPhoneの成功とともに各社がスマートフォンに力を入れはじめた時期と一致している。これは偶然ではなく、必然である。iPhoneの成功をうらやむライバル・メーカーや、Appleに「おいしいところ」を全部持って行かれて自分が「ただの土管」になってしまうことに危機感を抱いている通信会社にとって、iPhoneでしか動かないObjective Cで書かれた何万ものiPhoneアプリの存在、そしてそれが作り出すクローズなエコシステムは脅威である。だからと言って、いまさら「自分独自のプラットフォーム」を発表したからと言って、Appleと互角に戦えないことは目に見えている。

 そこで浮上してきたのが、標準化が進んでおり、Apple自身すらが率先して協力しているウェブの技術(つまりHTML+CSS+JS)を使ってスマートフォン・アプリを作る仕組みをオープンな形で作って、より大きな形でのエコシステムを作ろう、というのがWidgetの発想である。そうは言っても、最初はなかなか各社の足並みが揃わず、いくつかの方言が出来つつあったのだが、ようやく「それぞれのWidgetの仕組みから共通項を抜き出して、まずはそこからしっかりと標準化しよう」という動きが出て来た結果が「W3C Widget」である。

iPadアプリをWidgetの仕組みを使って作る利点は?

 ひとそれぞれだと思うが、iPhone OS上のアプリを作ったことのない人にとっては、Objetive Cを覚えなくて良いというのは大きなプラスだとろう。Macではなくて、Windowsマシンで開発できてしまう、というのも人によっては大きなプラスである。しかし、何と言っても「アップルの審査なしに自由に流通できる」というのが一番の利点だろう。「思いつきでちゃちゃっと作って、その日にブログで公開」みたいな手軽なことをするにはWidgetは最適である。

 そして、もう少し中長期的な視点で言えば、Widgetの形で開発しておけば、将来iPad以外のタブレット端末が普及して来た時に、再利用しやすい、という利点がある。もちろん、Widgetランタイムごとに若干の違いだとか、ブラウザー間の互換性の問題などが100%なくなることはないが、Objective CでiPhone OS向けに書いたアプリと比べたら、その移植性は格段に高くなる。

Hello Worldを作ってみる

 どんなプラットフォームでも最初に作るのはHello Worldと決まっている。Widgetの場合もそれだけであれば、いたって簡単。たった二つのファイルを用意するだけで良い。

index.html

<!DOCTYPE html>

<html>  

  <head>  

    <meta https-equiv="Content-Type" content="text/html; charset=utf-8" />  

    <meta name="viewport" content="width=device-width,user-scalable=no,initial-scale=1.0">  

  </head>  

  <body>  

      <h1>Hello World</h1>

  </body>  

</html>  

config.xml

<?xml version="1.0" encoding="UTF-8"?>

<widget xmlns="https://www.w3.org/ns/widgets"

        id="https://example.org/exampleWidget" version="2.0 Beta"

        height="120"  width="320"

        viewmodes="application">

  <name>Hello Application</name>

  <description>My First Application</description>

  <author href="https://satoshi.blogs.com">Satoshi Nakajima</author>

</widget>

 index.htmlはアプリケーションのルートファイル。"Hello World"をという文字列を"h1"タグを使って表示しているだけの単純なもの。二行目のmetaタグはiPadやiPhoneでちゃんと表示してもらうためのおまじない。

 

 config.xmlはアプリケーションの名前や実行環境を指定する設定ファイル。height/widthはパソコンのデスクトップ上での起動時のWindowの大きさを指定しているが、iPad上で起動した場合は無視される(これはCloudReadersの実装がそうなっている、というだけのこと)。viewmodesは独立したアプリケーションとして動くべきか(application)、ブラウザーの小判ザメとして動くか(widget)を指定しているが、iPadの場合は関係ない。後は、アプリの名前とか開発者の名前とか、である。

 

 この二つのファイルの用意ができたら、その二つを同じフォルダーに置いてからZIP圧縮し、作ったZIPファイルのエクステンションを.wgtにすれば完成である。拍子抜けするほど簡単である。


 テストも至って簡単である。まずは作った.wgtファイルをパソコン上のOperaにDrag&Dropする(最新版のOperaをおすすめする。私がテストしたのは Opera 10.53)。すると、Widget Installer というアプリが立ち上がり、そのWidgetを登録したいかどうかたずねてくるので、"Install" ボタンをクリックする。


WidgetInstaller  


 そのまま起動すると、上で作ったHelloWorld Widgetが起動され、こんな感じになる。


HelloWorld
 

 これで一応、Widgetとしては動いていることが確認できたので、iPadにインストールする(手順は、iPadでHTML5 Widgetを走らせて遊ぼうを参照)。インストールしたHello WorldをCloudReadersから起動すると、こんな表示になる。


HelloWorld_on_iPad
 

 

 ちなみに、「Widget化」したからと言って、ブラウザー間の互換性の問題は魔法の様になくなったりしないのでそこは要注意である。WebKitにしか実装されていないCSS3の3D Transitionとかを使えば、当然Opera上ではちゃんと表示されない。ただし、一番の目的が「HTML+JavaScript+CSSでiPadアプリを作る」ことな場合はそれほど重要な話ではないが。


【謝辞】ちなみに、このエントリーを書く際には、昨日のOperaのダニエル・デイビスさんの解説がとても参考になったので、ここに感謝の意を表しておく。



iPad上でHTML5 Widgetを走らせて遊ぼう

 昨日の「HTML5: W3C Widget とその応用を考える会」は参加者も多く、私自身とても良い勉強になったが、そこでも予告した通り、iPad発売を記念してWidgetのサンプルをいくつか用意したので、ぜひともお試しいただきたい。

 手順は以下の通り。

ステップ1. iPadにCloudReadersをインストールする(iTunes ストアへのリンク

ステップ2. 以下のWidgetをダウンロードする

ステップ3. iPadをPC/Macに繋げ、iTunesを立ち上げて左サイドバーでiPadを選択

ステップ4. タブからAppsを選択

ステップ5. スクロールダウンして、File Sharing の Apps からCloudReaders を選択

ステップ6. ステップ2でダウンロードしたWidgetをDocumentsにDrag&Dropする

ステップ7. CloudReadersを立ち上げてWidgetをリストから選択する

 Widgetの仕様はこちらに書いてあるが、簡単に言えばZIPで固めたウェブアプリケーションである。オフラインで走らせることも可能だし、こんな形でパッケージとして流通させることも可能である。最近、私は「iPad用のマルチメディア出版は、(Objective C/C++/JavaやFlashで作るのではなく)HTML5で作るべき」という主張をしているが、その際のパッケージング方式としてデファクト・スタンダードになりつつあるのが、このWidgetである。

 興味があるエンジニアの方は、上でダウンロードしたWidgetのエクステンションを.zipに変換して解凍すればソースコードを見ることもできる(ちなみに、その中身はオープンソースなので自由に利用していただいて結構だが、作ったWidgetへのリンクをこのエントリーのコメント欄に書いていただけるとありがたい)。

 ちなみに、CloudReadersのWidgetサポートはまだベータ段階なので、Opera用に作られたWidgetはまだ動かないものが多いのでそこはご容赦いただきたい。ルートファイルがindex.htmlでなければならない点、クロスドメイン・アクセスはサポートしていない点、などの制限もあるが、とりあえずWidgetとは何かを理解するために、簡単なものを試してみるには十分な環境だ。

 「iPad向けにアプリケーションを作ってみたいけど、Objective Cを勉強している時間はない」人には、「JavaScript+HTML+CSSでiPadアプリを作ること」が可能になる点が魅力だと思うんだがいかがだろう。特にiPadのCSS3アニメーションの実装はすばらしく、かなり高度なことが出来るのでぜひともお試しいただきたい。


電子出版に関する一考察:コンテンツのガラパゴス化の危機

 今日は日経BPのセミナー(参照)で、iPadと電子出版の未来について講演をしてきた。私の講演の内容に関しては、一両日中にネットに上がると思うのでここには書かないが、この講演およびその準備段階を通して学んだとても大切なことを一つ書こうと思う。それは日本の出版社に迫る「コンテンツのガラパゴス化の危機」である。

 午後の部でヤッパの伊藤氏の講演を聞いていて少し疑問に思ったので、フォーマットのオープン化に関する質問をした私だが、彼の「まだコンテンツの数が少ないのでオープン化を考慮する必要はない」という返答でヤッパの狙いが明らかになった。セルシスと同じく「クローズドなフォーマットによるコンテンツの抱え込み」である。

 ここまでフォーマットのオープン化(すなわち誰でもビューアーをライセンス・フリーで作れること)の大切さが叫ばれている今、時代に全く逆行するビジネスモデルだが、漠然とした危機感を抱いてはいるがデジタルの世界に詳しくない出版業界の人たちは、ある意味で「良いお客さん」なのだろう。「DRMが必要=クローズドなフォーマットでなければならない」という良くある誤解もプラスになる(実際には、ビューアー部分はオープンなままでパッケージングの部分でDRMをかけることは十分に可能)。

 しかし、クローズドなセルシス・フォーマットでモバイル・コンテンツを大量に作ってしまった日本の出版社が、セルシス・ビューアーが載っていないデバイスにはコンテンツを提供できない、いつまでたってもセルシス抜きではビジネスができない、ビューアーを載せるのにやたらと時間とコストがかかる、という状況に陥り、コスト面で割が合わずにせっかく海外に進出するチャンスをみすみす逃して「コンテンツのガラパゴス化」を招いてしまっていることは、この業界では良く知られたこと。海外から見ているとなんともむずがゆい。

 そんなところでいつまでももたもたしているから、BitTorrentoに少年ジャンプの日本語版・英語版・フランス語版がリアルタイムで毎週流れる、なんてことが起こってしまっているのだ(私の知り合いにも何人か定期購読者がいる)。このままだと、BitTorrentoで無料で少年ジャンプを読んでいる人たちの数がちゃんとお金を出して少年ジャンプを読む人の数を上回る日も遠くないと思う(すでに超しているのかも知れない)。

 特にiPadぐらいの解像度を持つモバイルデバイス向けにマンガを提供する際は、妙な(セルシスがやっている)「コマ割り」や(ヤッパがすすめる)「マルチメディア化」をせずに、作家が書いたままのコンテンツを全画面表示させた形のコンテンツをまずは普及させる、ということが急務。

 その際に最も大切なことは、コンテンツのフォーマットをオープンなものにしておくこと。フォーマット済みのものを配布するならば、PDFかZIPで固めた画像ファイル(JPEG)で十分だし、テキスト中心でレイアウトが重要でないならばePubがある。「セルシス・ビューアーでしか見れない」「ヤッパ・ビューアーでしか見れない」コンテンツを作ったら、将来何年間に渡って後悔することになる。オープンなものにしておけば、誰でもライセンス・フリーでビューアーが作れるので、ビジネスの自由度がぐっと高まる。

 「今すぐにどうしてもマルチメディア化した書籍をiPad向けに配信したい」というのであれば、答えは一つしかない。HTML5である。今日のセミナーでも少しデモをしたが、iPadに実装されているHTML5+CSS3は、十分にFlashに匹敵するレベルに達している(特に、消費電力に関してはFlashよりも遥かに有利)。

 一つだけ覚えてほしいのは、HTML5はウェブサイトの表示のためだけの技術ではないということ。Appleの「アプリケーションはJavaScriptかObjectiveCで作らなければいけない」という規約を守りつつ、将来はAndroidタブレットやWindowsタブレットでもちゃんと動くマルチメディア・コンテンツを作るとしたら、最適解がHTML5であることに疑問の余地はない。

 HTML5で作っておけば、オープンな仕様なので、誰でもロイヤリティ無しでビューアーを作ることが可能だし、その実装もWebKitというすばらしいオープンソースがあるのでとても簡単である。まだまだオーサリング・ツールなどが完備されていないので、今の段階ではかなり「手作り」の部分もあるが、どうせコストをかけてコンテンツを作るのであれば、特定のビューアー向けのコンテンツではなく、オープンなHTML5の上で作るべきだ。

 ちなみに、CloudReadersには既にHTML5 Widgetを実行する仕組みが入れてある(当然、それも無料)。28日までにはいくつかWidgetをここで公開する予定なので、iPadを入手された際にはぜひとも試していただきたい。セルシスやヤッパが提供するクローズドなビューアーが不要なのはもちろんのこと、なぜアップルがFlashは不要と言っているかがご理解いただけると思う。


iPad用スタイラスを自作する方法

 iPad向けのお絵描きソフトを共同開発している友人(Pete)と私が会う時は、お互いにiPadを持ち寄って、(自分たちの作ったアプリで)メモを取りながら色々と相談をしているのだが、彼がその時に必ず持って来るのがスタイラスペン。

 確かに指より細いので書きやすそうだが、その価格が12ドルと聞いて「それは暴利だ!」とつい叫んでしまった私である。Peteは動揺もせずに「このスポンジが特殊なんだよ」と自慢げに見せてくれたのが、そのスタイラスの先っぽについた黒いスポンジ。

 なんだか見覚えのあるスポンジだったので、「このスポンジなら秋葉原で入手できる」と言った私に、「それなら今度日本に行った時に買って来て証明してみせろ」というPete。

 そこで早速、今回の出張を利用して秋葉原に行って来た。例の「部品市場」の二階のどう考えても消防法違反をしていそうな店の一軒に入り、「名前は知らないんだけど、例のIC用のスポンジある?静電気防止するやつ」と聞くと出してくれたのが「ICフォーム」。導電性のスポンジだ。

 手頃な大きさのもの(でもスタイラスが100本以上作れる)を460円で買い、その場でiPadでテスト。ちゃんと絵を描いたり、キーボードを操作できる感度。予想した通りだ。あとは、ボールペンの後ろにこのスポンジをつめればスタイラスの出来上がり。これでPeteに良い「おみやげ」が出来た。

  ということで、iPad用のスタイラスを自作したいと考えている人にはこの「ICフォーム」がおすすめ(秋葉原まで行かなくともAmazonで売っている)。何と言っても安くて加工がしやすく、iPadのガラスにも傷がつかないのが良い。


iPadに最適化したPDFファイルの作り方

 iPad向けにPDF/マンガリーダーCloudReadersを発表してから、いままで直に付き合いがなかった出版業界の人たちからちょくちょくコンタクトをいただくようになった。その中で良くある質問の一つが、「iPad向けに最適化したPDFファイルの作り方」。そこで今日は、そのあたりのノウハウをまとめて書いてみる。

 まもなく日本でも発売されようとしているiPadは色々な意味で画期的なデバイスだが、あくまで位置づけはモバイル・コンピューターであり、パソコンではない。画面も大きく、CPUも高速になったとは言え、搭載するメモリ(RAM)の量はiPhone 3GSと同じだ。

 そのため、メモリがふんだんにあるパソコン用に作ったPDFファイルを読もうとすると、メモリ不足でアプリが落ちたり、極端に遅くなったりしてしまう。アプリを作る側もいろいろと対応はしてはいるが(参照)、やはり快適にiPad上でPDFファルを読もうとするのであれば、それなりの最適化は必要である。

1. 一度プリントアウトしたものをスキャンしてPDFファイルを作るのではなく、オリジナルのドキュメント(=文書)から直接PDFファイルを生成する。

 これは当然、「オリジナルのドキュメントにアクセス可能」なことを前提にした話だが、一度プリントアウトしてからスキャンしたものと、オリジナルのドキュメントから直接PDF化した場合では、ファイルの大きさも違うし、画面に表示した時にきれいさも大きく違う。どうしてもスキャンする場合は、150dpi 程度の解像度にとどめておく(200dpiとか300dpiにしたところで、iPad上できれいに見えるわけでもなく、ただ無駄にメモリを消費する→表示が遅くなる)。

2. 画像を含んだドキュメントをPDF化する際には、画像をダウンサンプリングする。

 Adobe InDesignでPDFファイルを作る際、特になにも指定しないとInDesignはドキュメント中に貼付けられた画像は、たとえ縮小して貼付けたとしてもオリジナルの解像度のままでPDFファイルにしまうように設計されている。最近のデジカメで撮影した画像は、数メガピクセルの大きさなので、そんな画像を含んだPDFファイルをiPad上で見ようとするとメモリ不足になってしまう。これを防止するためには、ダウンサンプリングというテクニックを使って、解像度を落として(ただし、iPadに表示するには十分な程度に)PDF化する必要がある。詳しくは、Adobeの解説ページの「PDFファイルサイズの低減」を参照していただきたい。

3. すでにPDF化されたものしか無い場合(オリジナルのドキュメントにアクセスできない場合)、Acrobat を使ってダウンサンプリングする(ドキュメント→ファイルサイズを縮小、もしくは、詳細→PDFの最適化)。[追記: OS-XのPreview→SaveAsのQuartz Filterで圧縮も可能。ただ、PDFファイルによっては写真の色がただしく変換されないケースがあるので要注意]

4. それでもダメな場合は、各ページをJPEG化し、それをZIP圧縮してiPadで読む。

 これは最後の手段だが、CloudReadersの場合だと、これがもっともサクサク読む方法でもある。変換の方法は色々とあるが、いずれにせよ各JPEGファイルの大きさを1400x1000以下に押さえておくことをおすすめする。ちなみに、MACを持っている人の場合、以下のステップでこの変換が可能。

(1)PDFファイルをPreviewで開き、ファイル→プリントを選択する

(2)ここでPDFメニューから "Save to iPhoto(iPhotoにセーブ)" を選ぶ

(3)iPhotoを立ち上げて、(2)でセーブされた各ページの画像を選択した上で、ファイル->エクスポートを選ぶ。表示されたダイアログボックスで、JPEG/高解像度(もしくは、JPEG/カスタム/1400)を選んでエクスポートする(フル解像度のままだと大きすぎる)。

(4)エクスポートされたファイルをファインダーを使って圧縮する。

 iPad発売まであと6日。iPhoneの登場以来、久しぶりに画期的なデバイスが世の中に出る。それも同じアっプルから。


「金メダリストは『練習が楽しくてしかたがない』からこそ強くなれた」説

 技術評論社の WEB+DB PRESS 向けに連載コラムを書きはじめたのだが、その最初のコラムがウェブで公開されたので、リンクを張っておく。

 第一回 一生の仕事を選ぶということ

 担当の人の「この業界で働く若手のエンジニア向けのメッセージ」を書いてほしいとのリクエストに答えるつもりで書いたのだが、「説教臭くなくて、ちゃんと伝わる」文章を書くのが難しくて結構苦労したので、ぜひとも読んでいただきたい。

 この話の核となる部分は、私の「マラソンで金メダルを取る人たちって『過酷な練習に耐える精神力がある』から頂点に立てるんじゃなくて、『他の人たちにとっては苦痛でしかない練習が実は楽しくて仕方が無い』から頂点に立てるんじゃないか」というセオリーにもとづいている。高橋尚子が現役のころの話を聞いていて、つくづく「本当にこの人は走ることが好きなんだなあ。だからこそ誰よりもたくさんの練習をすることができて、その結果、早く走れる様になったんだな」と感じて作ったセオリーである。

 プログラマー歴30年を超える私も、なかなか取れないバグに悩んだり、回避しようのないシステム側の不具合に苦しまされたり、納期に迫られて眠れない夜を過ごしたり、などという(普通に考えたら)過酷な状況に置かれることはしょっちゅうあるが、それで「プログラムを書くのを辞めよう」なんて思ったこともないし、今後もバリバリ書き続けようと思う。

 昨日も、iPad向けの二つ目のアプリをアップルに提出したばかりだし、日本に向かう飛行機の中でも次のアプリの準備を進めて時間を過ごした。iPhoneアプリの開発のために全く新しい開発環境を学ぶのも楽しくてしかたがなかったし、Google App Engineで遊ぶためのPythonの勉強も自分で喜んでした。

 はたから見れば、「あの人は夜も週末も働いているし、すごく努力している」ように見えるかも知れないが、私自身にとってみれば「新しい開発環境や言語を勉強する」ことは旅行やゲームをすることや映画を見たり本を読んだりすることなんかよりも何倍も楽しいわけで、それを「努力」とか「苦労」とか呼ぶことが適切とは思えない。

 どの業界にも「仕事が辛くて金曜日が待ち遠しくて仕方がない」みたいな働き方をしている人がたくさんいる。簡単に転職などできないことも分かるが、「仕事が楽しくて、週末休んでいても常に仕事のことを考えてしまう」職に就けた人と比べた人生の充実度の違いは大きい。

 そんな意味でも、「自分がどんな職に就くべきか」はもっともっと真剣に考えるべきテーマだと思うんだがいかがだろう。


iPadアプリ作成日誌: PDF関連APIのバグについて

 以前にもここで少し触れたiPhone OSのPDF関連APIのバグについての詳しい情報が知りたいという連絡がTwitter経由で入ったが、140文字制限でするのもなんなので、具体的にバグレポートを書いてみる。

 iPhone OS 上でPDFファイルを表示する場合、まずは CGPDFDocumentCreateWithURL でドキュメントを開く必要がある。CloudReadersの場合はこんな感じだ。

        NSURL* url = [NSURL fileURLWithPath:path];

        CGPDFDocumentRef doc = CGPDFDocumentCreateWithURL((CFURLRef)url); 

count = CGPDFDocumentGetNumberOfPages(doc);

 特定のページを表示(=描画)する際には、CGPDFDocumentGetPage でページハンドルを取得し、CGContextDrawPDFPage で描画する。

        CGPDFPageRef page = CGPDFDocumentGetPage(doc, i);
        CGContextDrawPDFPage(context, page);

 くせ者はこの CPDFDocumentGetPage。すべてベクター(文字も含む)で書かれたPDFドキュメントの場合、何の問題もないのだが、スキャナーで作ったPDFの場合、大量のメモリーを消費するのだ(手持ちのサンプルだと1ページあたり26MB!)。

 それも一時的なものであれば良いのだが、なぜか次のページを描画してもそのメモリは解放されず、そのまま数ページ進むとメモリ不足でアプリが落ちてしまう。

 以前、Appleのフォーラムで何人かの人がこの問題を指摘したところ、そのメモリーは CGPDFDocumentRelease を呼べば解放されるので、メモリーリークではなく「高速化のための単なるキャッシュ」という返事がAppleの担当者から返って来た。その人に言わせると、「メモリを節約したいのであれば、「1ページ描画するごとにドキュメントを開いて閉じれば良い」ということ。

 私から見れば、これはメモリがふんだんにあるOSXのコードをそのままiPhone OSに持って行ったために生じた不具合である。3〜4ページ描画しただけでアプリが落ちてしまうのだから、十分にバグと呼べると思う。

 これが原因で、iPhone/iPad向けのPDFリーダーは、画像ばかりのPDFファイルを開くとメモリ不足で落ちたり、妙に遅くなったりするのだ。CloudReadersの場合、まずはスピード優先で走り、メモリ不足が生じた時点で「Safe Mode」に移行するという綱渡り的なコーディングでしのいでいる。1.04から落ちにくくなったのはそのため。



iPadアプリ作成日記: 「iPadアプリ作ってて良かったなあ」と思える瞬間

 「iPadアプリ作ってて良かったなあ」と思える瞬間は下に貼付けたコメントみたいなものをもらった時。こんなコメントをしょっちゅうもらえるなら、有料アプリを作って中途半端な小遣い稼ぎをするよりもずっと楽しい。

This is the best app in the world. Honestly. - ★★★★★

by jaybay216 - Version 1.05 - 07 May 2010

This application literally makes my iPad worth every penny I paid for it. This is the best app I have ever seen in my life. It works astonishingly, and its free. I would suggest that the creator starts charging for this app because I would honestly pay $20 if I had to. Thew newest update (1.05) makes the app even better by centering the pages, something that is essential to an immersive comic experience. The app handles pdfs, and all comic formats AMAZINGLY! Thanks so much!

 ちなみに、今マイクロソフト時代の友人と共同開発中のiPadアプリも無料で提供する予定。Adobe Ideaを見た時から、「俺ならもっと良いものが作れる」と妄想を膨らませて来たのだが、それを形にするつもり。ちょっと気合いを入れてコーディングしているので、乞うご期待!