日本語コメントの変換

詳しくは書けない例の件で、既に作ったパッチの日本語コメントはどうなるの?という問題があります。これまではShift-JIS、これからはUnicode/UTF-8なので、そのままでは文字化けてしまいます。

個人的には、2061:MaxオデッセイやThe Jitter Bookなどのサンプル・パッチが1,000個近くあって、それぞれに数個程度は日本語コメントを付けていますからね。これらを手作業で変換したり、再入力したりするなんて考えられない。

トホホな気分で変換プログラムを作り始めていたところ、自動変換機能が備わる予定だったことが判明。まだ若干の問題はありますが、最終的には何も考えなくても自動的に変換されることになりそうです。素晴らしい!

J-comment-converted.png

によって、画像にスクランブルをかけています。)

ただし、2061のブラウザは独自処理なので、作り直す必要があります(涙)。気が重いな〜

それから、Windowsは少々事情が違うみたいですが、私はPCクンの電源の入れ方も知らない人なので、どのような状況かよく分かりません。Windowsのフォントやエンコーディングに詳しい人は、ベータ・テスタに志願されるといいんじゃないでしょうか?(と他人任せ)。

秘密の花園

いや、バーネットの小説じゃなくって、iPhone SDKのことです(笑)。「Appleがあなたに知って欲しくないと思っていたAPIたち」てな感じで、「iPhone Open Application Development」の著者Jonathan Zdziarski氏が書いた記事”The iPhone SDK: APIs Apple Didn’t Want You to Know About“が面白い。読み応えタップリ、試し甲斐アリアリです。

iPhone-APIs-Apple-Didnt-Want.jpg

公式SDK発表後は、いろんな思惑があるのかオモテには出ないところで様々な動きが展開しています。しかも、断片的な情報が多いから、追いかけるのが大変。この記事みたいなのが増えるといいんですけどね。

砂場で遊ぼう

イタズラ心でXcodeの検索ボックスに「sandbox」と入力してみたら、ゾロゾロ出てきました。これらはLeopardに加わったセキュリティ機能で、iPhoneにも使われているハズね。

ただ不覚にして、こんなベタな言葉が使われているとは知らなかった。sandbox_init()とかsandbox-exec()とかって、可笑しいよね。あと、Code Signingってのもステキ。コードは歌うよ〜♪と勘違いした(笑)。

Xcode-sandbox.jpg

後方互換性は上々

詳しくは書けない例の件で、恐る恐るaka.objectsを試してみたところ、すべてバッチリ動作しました。徹底的に調べた訳じゃないものの、ヘルプ・パッチの範囲では問題ない感じ。lcdが少々バグってるらしく、表示がおかしな箇所があったけど、それはそのうちフィックスされるでしょう。

aka.wiiremote-M5-puzzled.png

詳しくは載せられないので、この画像を作成したパッチはこちら

と言う訳で、後方互換性(上位互換性)は、なかなかのもののようです。エクスターナル・オブジェトを制作している人は、ひと安心ね(これまた、保証できないけどね)。aka.iphone.appsは結構手直しが必要だったり、サポートされていない機能があったりして、ちょっとブルーだったのですが、こちらは大船に乗ったキブンです。

【追記】でも、UI系のオブジェクトは問題が生じる場合があるみたいです。

UnicodeはUTF-8で

詳しくは書けない例の件で、Unicodeサポートはほぼ問題がないレベルになりそうです。今のところ表には出せないステイタス・レポートを、孤独に書きまくっています(笑)。まぁ、日本語サポートしてよと長年言い続けた手前、ボランティアとしてがんばっている次第。

それで、Unicodeと言えば普通は(私だけ?)UTF-16を連想するんだけど、少なくとも最初のリリースではUTF-8のみになりそうです。「赤」なら0x8D64じゃなくって、0xE8 0xB5 0xA4ってことね。

Unicode-UTF-8.jpg

もっとも、テキスト入力とかコピペとかなら、文字コードを意識する必要はありません。サクっと入ります。しかし、バイナリー入出力とかWeb系の用途なら、文字コード(エンコーディング)が重要なので、事前情報としてチョコっと入れておきます(でも、保証は何もありませんよ〜)。日本語(インターナショナル?)アプリを作ってる人は、ご留意あそばせ。

あと、プレーンな文字ハンドリングらしく、「get愛」みたいなメッセージも何気なく動きます。ちょっと感動。

GDataのObjective-Cライブラリが公開

iPhoneにも対応したGoogle Data API群のObjective-Cライブラリが公開されました。これまではAjaxとして利用していた以下の機能が、ネイティブにも利用できるワケですね。

  • Google Base
  • Blogger
  • Calendar
  • Code Search
  • Contacts
  • Documents List
  • Notebook
  • Picasa Web Albums
  • Spreadsheets
  • YouTube

Googleのすべてのサービスからすれば一部に過ぎないものの、それでもお腹一杯状態です。WebでできることはAjaxで、ですが、Objective-Cで目にも留まらぬ超高速処理ができれば、それは価値がありますね。ネットワークとiPhoneハードウェアとの統合も可能性が大きい。

Google-logo.gif

Googleと言えばAndroidですが、iPhoneと競合している雰囲気が希薄なのはナゼなんでしょうね? いや、水面下では激しい火花を散らしているのかもしれませんが…

iPhone Developer Programの資料

ウワサではン千人ともン万人とも言われていますが、有償のiPhone Developer Programに申し込んだ人のほとんどに、もうちょっと待ってねメールが来たようです。それが余りにも多いものだから、誰も承諾されていないのではないかと話題になっていました。私もしっかりゴメンナサイされちゃってます(US外だから当たり前だけど、US特派員もRejectされちゃったのよ)。

しかし、幸運にも承諾された人がいて、秘密のベールに包まれていたiPhone Developer Programの資料を公開しています。サイトのスクリーン・キャプチャやPDF書類が数ファイルありますね。

iphone-developer-program-site_m.jpg

もちろん、これ、NDA違反でしょうから、そのうち消滅する可能性が大です。

【追記】翌朝(3/20)にはPDF等が削除されていました。私もダウンロードしていませんから、コピーをくれ〜なんて尋ねないでくださいよ。

それから、TUAWの記事によれば、プログラムの承認はランダムに行なわれているみたいですね。ランダムに(間違って?)海外にも承認を出してくれればいいのにね。

Safari 3.1でデータベース保存

昨日(たぶん)Safariが3.1にアップデートされましたね。0.1アップだから大したことないと思いきや、これが大違い。詳しくはリリース・ノートを見ていただくとして、注目はコレ。

Adds support for offline storage for Web applications in SQL databases

Safariのセキュリティ環境設定にも、しっかりデータベースの容量設定が加わっています。

Safari-3.1-database.jpg

フツーに考えると、これはWebアプリのローカル実行のためで、WebKitとして実現されているハズ。となると、そのうちiPhoneにも搭載されるハズで、Webでできることをネイティブ・アプリで書いても意味ナシってのが現実になります。Dashcode 2.0で予見されたことですね。iPhoneにもSQLiteが入ってますから、問題ナシです。ってか、データベース抜きには最近のアプリは成立しないよね。

逆に言えば、これでWeb/Ajaxプログラマの領域がドド〜ンと広がるワケで、関連の方々はぜひ大活躍してくださいませ。私はピーとかガーとかだけなので、あまりデータベースには縁がないのです(笑)。

StaticからDynamicへ

iPhone Software Roadmapの最終回(のハズ)は、いきなり脱線なんだけど、最初にゲーム機としてのiPhoneの可能性について書いておくね。プレゼンテーションでは、iPhoneが魅力的なゲーム・プラットフォームであること=目下敵なしのNintendo DS+Wiiの両方の特徴を同時に備えていることがが如実に示されていたよね。ゲーム機としてはUS$399は高いから、メモリ1GBで通話オプションの安価なiPhone liteを半額で出せばいいんじゃない? それ、私なら50台買います(笑)。

iphone-touch-fighter.jpg
iPhone Software Roadmapのムービー

さて、本題に入って、ちょっと思考実験してみる。それは、iTunes StoreよりApp Storeのほうが遥かに条件が良さそうってこともあって、音楽でも映像でもいいんだけど、何らかの表現物をアプリケーションとして流通させることね。ゲームやツールが典型的なアプリケーションだけど、それだけじゃない。

例えば、もっとも単純に、アプリの中にはAACファイルと再生ルーチン+αしか入っていないっていうヤクザな方法が考えられる。これをiTunes Storeのシングル1曲150円ではなく、App Storeで150円のアプリケーションとして販売する。さて、どっちが儲かるんでしょう? これを禁止する条項があるんだろうか? Limitationsに挙げられていたBandwidth hog(帯域喰らい)じゃないとして、Unforeseen(不測の事態)にされちゃ適わないけどね。

もうちょっとマシな方法としては、CD-ROM時代に流行った(?)ように、マルチ・トラック・ソースを入れておいて、ミキシング&エディットができたり、ループ&スクラッチできたりするようなアプリケーションも考えられる。インタラクティブ・ミュージックなんて嘯いたりしながらね。当然、アルゴリズミック・コンポジションやジェネレイティブ・ミュージックなどの試みも再挑戦してくるだろうし、楽器&エフェクター系のアプリケーションも山ほど出てくるハズ。

10年以上前からのパイオニア、Todd RungrenPeter Gabrielは、既に血眼で作業しているよ、きっと。いつも意外なところを突いて来るBrian Eno(& intermorphic?)はどうするんだろう? 最近の(でもないか?)OvalやAutechreあたりの連中はもう飽きちゃってるのかな? 有名・無名を問わず、この手の可能性を模索している人は一杯(?)いるワケだし、音楽だけでなく、写真、映像、言語、身体表現、その他いろんなジャンルが考えられる。志半ばながら、aka.iphone.appsでやっていることは、そーゆーこと(の一部)です。

これらが示すのは、要するにメディアはスタティック(静的)からダイナミック(動的)へと移行するってことね。いつも乱暴な言い方をしているように、デジタル・コンテンツには価値がないとして、アプリケーションには一類の望みを託したいところ。レンダリングされたデータは屍でも、アプリケーションはゾンビ並みには動けるからね。もちろん、アプリケーションもデジタル・コンテツの一形態であり、レンダリング(コンパイル)されたデータであることには違いないんだけど、ほら、違いは分かるでしょう?

iTunes Storeが革命的と言われても全然ピンと来ないのは、それは流通が変わっただけで、作り手と聴き手の状況としてはあまり変わっていないからだと思う。作り手は相変わらず、録音して編集して配布するだけだし、聴き手は選曲して購入して再生するだけだよね。便利になりました!嬉しい!ってくらいで、屍のビット列を右から左に転送しても、ちっともエキサイティングじゃない。

つまり、このサイトのサブ・タイトルが示しているように「音楽と映像をダイナミックに創造する! 」ことに未来がある。…と思うんだよね。ダメかな? そんなの要らない、面倒っぽいって思う人が、まだまだ多そうなのがツライとこなんだけどね(笑)。余談ながら、「最高の開発環境を徹底解説」している対象が、最近はMaxじゃないけど(でも、裏でがんばってます〜)、本質的には同じことです。

と、まぁ、だんだん説明するのが面倒になって来たので、半分も書かない腰砕け状態で終わらせます(笑)。回を追うごとに長文化していて、なんだかカッコ悪い(素直に反省)。そう言えば、最近の音楽配信を踏まえた論評って、まるで新しい観点がないって怒ってた知人がいたけど、それは違うと思うな。文章として書かれたものは既に終わっている、ってことでしょ。このサイトだって同じ。既にある情報を鵜呑みにするだけではダメダメね。

というわけで、iPhone Software Roadmapを巡る妄想妄言は、これにてオシマイ。2月と思っていたことが実際には6月に延びたけど、それ以外は大賞賛すべき発表でした。