TidBITS: Apple News for the Rest of Us  TidBITS#1037/26-Jul-2010

今週の大ニュースは新しい Take Control アカウント管理システムのお披露目を記念する Take Control 電子ブック 50% 割引セールだ。この新システムの発足に際してはいろいろ技術的な問題に苦しめられたが、その間にも私たちは時間を見つけて iOS 用の注目すべきリリース、Skype 2.0.1 と iBooks 1.1.2 について調べてみた。また、今週号では Apple が MacPaint と QuickDraw のソースコードを Computer History Museum に寄贈したことについて Glenn Fleishman が報告し、Chris Pepper は Bluetooth キーボードを iOS 機器と一緒に使用すると思わぬ結果をまねくことがあると警告した記事を寄稿する。さらに、パンチの効いたユーモアが得意の Jeff Carlson が、Apple の記録的な Q3 2010 決算報告をクイズ形式で紹介する。今週号の締めくくりは Matt Neuburg と Adam による二つの記事で、まずは iOS が書類のマッピングをどのように処理しているかを概観してから、インターネットベースのファイルを iOS 機器のユーザーたちに配布したいと考えている人々にとってこの iOS の処理方法がどれだけ頭痛の種となっているかを語る。最後にもう一つ、PDF Shrink の DealBITS 割引をお忘れなく! 今週注目すべき他のソフトウェアリリースとしては、1Password 3.3、Wiki Server Update 1.0、Firefox 3.6.8、それに iTunes 9.2.1 がある。

記事:

----------------- 本号の TidBITS のスポンサーは: ------------------

---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----


Take Control 半額セール: アカウント管理を祝して 50% 割引

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

私たちは新しい Take Control アカウント管理システムを作り上げ、これまで一度でも Take Control 電子ブックを注文したことのある人すべてが私たちのサイトで自分の購入済みの本にアクセスできるようにした。自慢の機能が一つある。それは、あなたが iPad、iPhone、あるいは iPod touch を使って、私たちのサイト上で直接あなたの電子ブックを読めるようになったことだ。また、購入済みの PDF を再ダウンロードしたり、無料アップデートを受けたり、EPUB 版や Mobipocket 版をダウンロードしたり、といったこともできる。

この新システムの発足を祝って、私たちの販売するすべての電子ブックを対象に 50 パーセント引きセールを開催している。これから初めて Take Control 本を試してみようというあなたにも、これは絶好の機会となるだろう。初めての方には、私たちのシステムがあなたのために自動的に新しいアカウントを作成して、あなたの本を自動的にそこに登録する。また、これまで何冊も Take Control 本を購入して下さったあなたにも、もちろんこのアカウント管理システムがどの本が割引価格でアップグレードできるかといった情報もすべてお知らせできるけれど、今回の半額セールは何冊もの電子ブックを一挙にカートに乗せるだけでアップデートできる最も安価で最も手軽な方法となるだろう。

期間限定のこの半額セールを利用するには、まずこのクーポン折り込みのリンクを使って私たちのサイトのカタログページを訪れて頂きたい。それからお望みのタイトルを選んで、Buy Selected Ebooks ボタンをクリックする。すると、カートの最初のスクリーンに、クーポンコードと値引きが表示されるはずだ。この半額セールは 2010 年 8 月 3 日までとなっている。

特にお薦めなのが iPad 関係の電子ブックだ。主だったものを挙げれば:

(Tonya の "Take Control of iPad Basics" もお忘れなく。これは無料だ!)

でも、Mac と Mac OS X についての電子ブックも充実している。近刊のタイトルをいくつか挙げれば:

それから、個別のアプリケーションを扱った電子ブックとしては:

電子ブックのフルリストを見たり、セール価格を調べたりするには、上記のリンクを使ってカテゴリー分けされた Take Control カタログページを開いてもよいし、あるいは(やはりクーポン折り込みの)こちらのリンクを使って アルファベット順にすべての電子ブックを一覧できるページ を開いてもよい。

皆さんのご支援に感謝します! 今回の Take Control アカウント管理システムのような便利なサービスを新たに作り出すことができたのも、変わらぬお力を皆さんから頂いているからこそなのです。

コメントリンク11465 この記事について | Tweet リンク11465


Skype 2.0.1、バックグラウンド通話を iOS にもたらす

  文: Glenn Fleishman <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

iOS 用の最新版の Skype は、長らく期待されてきた機能をいくつか実現させている。その一つが iOS 4 の下でのバックグラウンド通話継続だ。つまり、通話中に Skype アプリから他へ切り替えても通話を続けられるのだ。従来と同じく、バージョン 2.0.1 も無料だ。

image

また、今回の改訂では通話の音質も改善され、Skype アプリがアクティブな前面プログラムでなかった場合にもかかってきた通話があれば通知できるようになった。この後者の機能と、バックグラウンド通話継続とにより、この Skype iPhone アプリは iPhone 標準の電話機能に対して本格的に競合するものとなり得るかもしれない。

image

Skype のブログ記事 によれば、同社は 3G 上で Skype から Skype への通話に個別の料金を課すという計画を断念したという。内部ネットワーク上のモバイル VoIP 通話に価格を設定するという、同社のサービスでそれまで先例の一切なかった計画を初めて発表した際には 、ユーザーが既に 3G データ料金を支払っているというのに、いったいなぜ同社がさらなる料金を徴収する必要があるのか、説明はまったくなされていなかった。

コメントリンク11447 この記事について | Tweet リンク11447


iBooks 1.1.2 で画像のズームに対応、PDF でのリンク不具合も修正

  文: Adam C. Engst <[email protected]>
  訳: 柳下 知昭 <tyagishi@gmail.com>

iOS 4.0.1 と 3.2.1 のすぐ後に、アップルは、 iBooks 1.1.1 をリリースした。それは、iOS デバイス向けで無料の EPUB と PDF リーダーに対するマイナーではあるが歓迎されるアップデートである。我々の視点からの最も重要な変更は、iPad が縦向きの場合にiBooks 1.1.1 がPDF リンクを正しく扱えるようになったことであり、バージョン 1.1 では、そうではなかった。(1.1.1 リリースの直後に、アップルは、1.1.2 を、iBooks 自体のアップデートに関する問題を修正するためとしてリリースした。)

iBooks 1.1.1 のその他の改良は、EPUB フォーマットの書籍に含まれる画像についてもダブルタップすることで、ズームできるようになったことと(その後、ピンチすることで、さらにズームすることもできる。この操作は、以前から PDF ではそのようになっていた)音声やビデオを含んでいるような ebooks フォーマットへ対応したこと、(我々は、この対応は、EPUB フォーマットの ebooks のみでしか機能しないのではないかと疑っているが、いまだテストするものを入手できていない)そして、特定の言語向けでない EPUB フォーマットの書籍中の英単語について定義を調べられるようになったことである。

PDF リンクの不具合について、アップルは、iBooks 1.1.1 では、いくつかの書籍のダウンロード失敗を生じさせる不具合を修正し、PDF を読むときのパフォーマンスを改善し、"安定性とパフォーマンスを改善した。"と言っている。正直にいうと、同意できない - どちらかというと PDF パフォーマンスは、悪くなっているように見える、ページの描画については、はじめはぼやけていて、1 秒程してから、クッキリしてくる。それは、Kindle でのページ点滅と同じくらい当惑させられる。

悲しいことに、iBooks にはいくつかの紛れもない欠点が残されている。最も顕著なのは、iBooks にはいまだに、戻るためのボタンやジェスチャーが無いことだ。もし、あなたが、EPUB か PDF の書籍中の別ページへのリンクをタップしたとすると、タップしたリンクのあるページへ素早く戻る手段はない。(リンクをタップするまえにブックマークをしていればよいが、それは、非常に不恰好な解決策である)もし、あなたが、PDF のページを拡大したとすると(iPhone や iPod touch では必要であろう)、iBooks は、別ページに移動すると拡大率を忘れてしまう。私の話は壊れたレコードのように聞こえると分っているが、GoodReader は、これらの両方の点について iBooks よりもすぐれた動作をしつづけている。

iOS のすべてのアプリケーションと同様に、この iBooks 1.1.2 へのアップデートは、iTunes のサイドバーで Apps を選択し、ウィンドウ右下にある"X 個のアップデートが利用可能"をクリックすることで行うことができる。もしくは、iOS デバイス上で App Store アプリを起動して、ツールバーのアップデートをタップすればよい。

コメントリンク11443 この記事について | Tweet リンク11443


DealBITS 値引き: PDF Shrink 4.5 が 20% 安くなる

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

先週の DealBITS 抽選で当選し、 PDF Shrink 4.5($35 相当)を受け取ることになったのは、telusplanet.net の David Gue と gmail.com の Nick Robson だ。おめでとう! 残念ながら当選しなかった皆さんもがっかりすることはない。 Apago では、2010 年 8 月 13 日までの期間中、すべての TidBITS 読者を対象に PDF Shrink 4.5 を 20 パーセント割引で提供しているからだ。割引価格で購入するには、Apago のストアから注文する。PDF Shrink をカートに入れれば、割引が表示されるはずだ。今回の DealBITS 抽選に応募して下さった 732 名の皆さんに感謝したい。また今後の DealBITS 抽選もお楽しみに!

コメントリンク11464 この記事について | Tweet リンク11464


Apple が MacPaint と QuickDraw のソースコードを博物館に寄贈

  文: Glenn Fleishman <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

歓喜の気持ちを呼び起こしてくれるようなソフトウェアはそう多くない。でも、QuickDraw と MacPaint は、間違いなくそういうソフトウェアの最上位近くに来るものだろう。Bill Atkinson の開発した QuickDraw は、あなたが Mac を使う際あなたに見えるものを定義した。MacPaint は、パーソナルコンピュータの上であなたが画像を作り出すことのできる、初めてのメインストリームのプログラムであった。

会社の初期の時代から長年 Apple で働き、Mac を生み出し開発する仕事に深く関与してきた Andy Hertzfeld の努力の結果として、Apple は QuickDraw と MacPaint のソースコードを Computer History Museum に寄贈 することにした。著作権は引き続き Apple に属するが、会社として Macintosh の心臓部の根幹を見せてくれるという決断は大変に気前の良いことと言えよう。[訳者注: マイコミジャーナル に、Computer History Museum を紹介した記事があります。]

QuickDraw と MacPaint はいずれも Atkinson の手によって Mac の先駆者である Lisa のために開発されたものだった。けれどもそれらが本当に成就したのは Mac の上であった。

QuickDraw はグラフィックのプリミティブおよびウィンドウ処理ルーティンのセットであり、Apple の開発者たちに、またサードパーティのソフトウェア会社にも、スクリーン上で情報を表示しアップデートするための高度に最適化された方法を提供するものだ。つまり、誰も同じアプローチを二度開発する必要がない。その代わりに、可能な限り高速で動作するように作られ常時改善され続けるこのルーティンのセットを、開発者たちはただ引き出して利用すればよいのだ。(グラフィックのプリミティブには、四角や円や多角形などの図形を作ったり、あるいは線で囲まれた領域に陰影を付けたり、といったことが含まれている。)

これは、当時、あるいはその後何年間も、他に存在していたグラフィックシステムの大多数のものと好対照をなしていた。その数年後に私は Windows 1.0 を使ってみたが、そこでは個々のソフトウェアが、それぞれ勝手にユーザーと交流する独自の方法を発明しているように見えた。ただし Microsoft は自社のソフトウェアシリーズでは一貫性を持っているようだったが。

Atkinson は、クリッピングの速度を二桁のレベルで高速化させる方法を見出した。クリッピングは、互いに重なったウィンドウを描かねばならない場合に発生するものだ。Atkinson は 2004 年に Computer History Museum での対談 (ここには彼も Hertzfeld も出席している)で、彼のテクニックのいくつかを紹介している。

クリッピングを高速化することにより、スクリーン上にたくさんのウィンドウがある上で好きなウィンドウをドラッグして動き回らせても、オペレーティングシステムが異常に遅くなることがない。Hertzfeld は QuickDraw を Mac OS に結び付けて開発者が使えるようにするためのグルー(文字通り QuickGlue と呼ばれている)を書いた。

MacPaint の重要性も見逃すべきでない。これは一般大衆が利用できる有能なデジタル描画プログラムとして初めてのものであり、ちゃんとした仕事を仕上げるためにも使えるものであった。QuickDraw コンポーネントに依存して、それらを拡張することにより、Atkinson は描画のための豊かなるメタファーとアプローチのセットを開発した。そしてそれは今日のソフトウェアにおいても依然として主要なパラダイムを規定し続けている。

下の図を見て頂きたい。一番左は LisaSketch のツールバー、そのすぐ右が MacPaint のものだ。そして、右の二つは最新版の GraphicConverter (6.7) と Adobe Photoshop (CS5) のツールバーだ。

Image

MacPaint は、Mac に組み込まれて付いていた数少ないプログラムの一つでもあった。多くの人たちにとって、これ こそ が Mac だった。それまで誰も、こんなものは見たことがなかった。マウスをクリックしてドラッグするだけで、お絵描きができる! それに、マウスを使ったことのある人の数も少なかった。だから MacPaint は、ハードウェアを通じて手の動きを翻訳することのパワーを、ユーザーたちに紹介する働きもしたのだった。

MacPaint は、Mac Pascal と 68000 アセンブリ言語を使って書かれていた。(およそ 60 パーセントが Pascal だった。)QuickDraw は 100 パーセントがアセンブラだ。アセンブリ言語はマシン言語の一段上のものだ。マシン言語は CPU がコマンドのために使う数字の形で直接プログラムコードを表現したものだ。プログラマーたちは今日でも最適化のためにこのレイヤーまで降りて行くことが時々ある。アセンブラは、その上で少しだけ抽象化の施されたレイヤーであって、シンボルやオペレータが使われ、それらがそれぞれ一連のマシンコードに変換される。

Hertzfeld は、自身の Apple での経験に関する一連の記事をFolklore.org に書いている。このサイトの記事をもとに彼が書いた本を、私は記事“革新は絶え間なく続く”(2005 年 1 月 24 日) でレビューしている。

コメントリンク11446 この記事について | Tweet リンク11446


iOS 機器、Bluetooth キーボードの使用にご用心

  文: Chris Pepper <[email protected]>
  訳: 大石哲伸<tedz2000@gmail.com>

iPad が iPhone から改良された点で最も歓迎されているものが Bluetooth キーボードのサポートであり、Apple Wireless Keyboard と Apple 製でないキーボードの両方をサポートしている。ありがたい事に iOS 4にて、このサポートが iPhone (3GS と 4) と第三世代 iPod touch で利用できる事になった。

ありがたくない事は、知らない間に細かなやり取りが Bluetooth キーボードと iOS(Bluetooth キーボード互換バージョン)の間で発生するために、いらいらさせられる事を始めとして、ついには破壊的出来事が起こる点だ。短く云えば、Bluetooth キーボードを旅行用に詰め込む前に電源を切りなさい、と言う事だ。電池を取り出しておいた方がよいかもしれない。

どうして、そんな注意が必要なのか?まず、Bluetooth キーボードはペアリングしている iOS 機器を起動できる。そのため、バッグに入れたキーボードのキーが他のものにぶつかって iOS 機器(もしくはキーボード自身)が何度も起動され電池の電力が消費される。もっと悪い事に、再生/一時停止キーがキーボード上で押されればペアリングされた機器でオーディオ再生が始まってしまう。-この事はパスコードでロックされている場合でも起こるのだ。

Apple Wireless Keyboard の電源ボタンは横から押されてオンになってしまう可能性があるので、電源をオフにするよりは電池を抜いておいた方が良い。

2番目に、もし、パスコードロックを設定(設定 > 一般 > パスコードロック)している場合(これは、その機器に重要なデータが入っている場合に推奨される)、パスコードロックの待ち時間は順次増えていくようになっている。つまり、間違ったコードが(この場合、意図していない操作によって)入力されるたびに、その次に入力可能になるまでの時間が延びていく。もみくちゃにされているキーボードから何度目かのロック解除の試みによって、その iOS 機器には1時間あるいはそれ以上の時間ログインできなくなってしまう。Macworld の Dan Frakes は苦い体験からこのことを知る羽目になった。

3番目に、もし、"データを消去"と言う項目がパスコードロック設定画面で有効にされていた場合(パスコードを使用している人にはすべて推奨)、iPad、iOS 4 機器は10回のログイン失敗に対してフラッシュメモリーの内容をスクランブル(意味のある内容を読み取れないような内容に変更)する。Bluetooth キーボードをサポートするすべての iOS 機器にはハードウエアによる暗号化機能があり、"crypto-shredding"を使用できる。この機能により、ハードウエアキーを捨てて、復号化を不可能にし、アクセスできないようにするまでが、ものの数秒で実行される。( iPhone 3G と第2世代 iPod touch は iOS 4 を走らせることができるが、どちらも外部キーボードをサポートしない)

もしあなたの機器で暗号保護されていた記憶装置へのアクセスができなくなった場合、失った情報を取り戻すのは簡単な事である。 iTunes へ再度接続しなおしバックアップをリストアするだけである。しかし、事はあなたが iOS 機器だけを持って旅行へ出かけていた場合には面倒になる。また、Pages で文書を作っていて写真をカメラから転送し、その後カメラから消していた場合、あるいは、その他の取り返しのつかない作業をしていた場合には、がっかりすることになるだろう。Securosis の Mike Rothman はこの経験を教訓として捉え、起こった事の良い面だけを見るようにしている。

直接的な解決策がいくつかある。まず、一番簡単なものは Bluetooth キーボードを詰め込む前に電源をオフにする事。Apple Wireless Keyboard では、オン/オフのスイッチは右肩の丸いキーボード支えのところにある(電池を入れる場所は左にある)。キーボードをオフにするためにこれを押す。電源をオフにする代わりに、もしあなたがオン/オフスイッチが押され続けた場合(従って上述した問題が引き起こされる)を心配するのなら電池を抜いてしまう。

image

代替案は、あなたの iOS 機器で Bluetooth をオフにして、もみくちゃにされたキーボードから偶発的にアクセスしてこないようにする事だ。

もちろん、Apple からすばらしい解決策が提供されるべきである。パスコード画面が表示されている間は Bluetooth キーボードからの入力を無視するようにする iOS オプションが提供される事が望ましい。

コメントリンク11448 この記事について | Tweet リンク11448


Apple、Q3 2010 に $3.25 Billion の利益計上

  文: Jeff Carlson <[email protected]>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

今回は少々趣向を変えてみた。この四半期の Apple の業績を単に報告するのではなく、双方向のスタイルにしてデータの一部はクイズ形式にしてみたい。

四半期業績 -- 今日の最初のクイズ問題は:Apple は 2010 年第三四半期の結果を報告したが、それは:

  1. 第三四半期としては最高の売上げであった
  2. 同社の歴史上のどの四半期に対しても最高の売上げであった
  3. "...驚異的な四半期で、我々の期待値をあらゆる点で上回った、その中には Apple の歴史上最も成功した新製品となった iPhone 4 も含まれる、" と Apple CEO Steve Jobs は言った
  4. 上記の全て

Apple は $15.7 billion の売上げを記録し、これが貢献し四半期純利益 $3.25 billion、或いは希薄化後一株当たり $3.51 となった。これに対して前年同期は、売上げが $9.73 billion そして利益は $1.83 billion であった。前四半期 (Q2 2010) では、Apple は売上げ $13.5 billion そして利益 $3.07 billion を計上している。

金額の裏にある数字 -- これらの結果に主として貢献したのは:

  1. 増大した Mac の販売:3.47 百万台、これは前年同期に対して 33% の増加である
  2. 増大した iPhone の販売:8.4 百万台、これは 61% の増加で (iPhone 4 の販売は二日分しか含まれていない) 売上げでは $5.33 billion となった
  3. 好調の iPad の販売:3.27 百万台、これは売上げに $2.17 billion 寄与した
  4. 馬鹿にしないで。勿論それは... 上記の全部である

これら全ての成長に対する例外は iPod カテゴリで、ここには iOS ベースの iPod touch に加えて Classic iPod, iPod nano, そして iPod shuffle が含まれる。Apple の iPod の販売数はこの四半期で前年同期よりも減少した (9.4 百万台で前年は 10.2 百万台、8% の減少)。iPod touch の販売は前年同期から 48% 伸びているので、非 iOS iPod の販売が劇的に落ちたことを物語っているが、これは実際の所驚きには値しないであろう。

興味深いのは、iPad に対する平均販売価格は $640 であったことで、これは多くの人が $499 のローエンドモデルを買っていないことを物語っている。

製品別 -- 下記の選択肢を読む前にこの質問に頭の中で答えてみて欲しい:Apple の売上げの中で一番高い割合を占めたのはどの製品群であったか?

  1. Mac (28%)
  2. iPhone (34%)
  3. iPad (14%)
  4. iPod (10%)

これで Apple がその収入源をいまだ Mac の販売にかなり依存していることがわかるが (部分的には教育部門に対する史上最高の Mac 販売のお陰である)、iOS 機器は合わせると同社の売上げの半分以上となる。この四半期間に、iOS 機器の販売は 100 百万台のラインを突破した。

Apple の利益に貢献した他のものとして iTunes Store があり、$1 billion の利益をあげ、これは前年同期比で 25% の増加である。

Apple 販売店 -- Apple の販売店に関する次の事柄で当てはまらないものを選べ:

  1. 販売店全体で $2.58 billion の売上げをあげ、これはこの四半期末で開業していた 287 店舗一つ当たりの平均で $9 million となる。
  2. Apple は この四半期中に 677,000 台の Mac を販売店経由で販売した。
  3. Apple 販売店から Mac を購入した顧客のほぼ半分は初めての人達であった。
  4. Apple が Apple 店を運営し始めて以来、この傾向は一貫していた。
  5. Apple は、最初の Lunar Apple Store (月面アップルストア) の建設を始めた所である。

(我々がこのクイズを本当に簡単なものにしようとした事が分かりますよね?)

手元資金 -- Apple は、前四半期の $41.7 billion から上昇今や $45.8 billion の手元資金を有しているが、これにはこの四半期での営業経費が $1.9 billion と比較的に小さい額で収まった事も貢献している。同社はこの軍資金を次のことに使おうとしている (次から _一つ_ を選択):

  1. これまで通り、資金を貯めておく。
  2. Dell を買い、同社を清算しその売却代金を株主に分配する。
  3. TidBITS から "Apple が 4 百億ドルで出来る事" (1 April 2010) でなされた提案に従う。
  4. 全てを硬貨に換え、そして Scrooge McDuck 金食い虫邸宅をつくり、そこで Steve Jobs がはしゃぎまわる。

先の見通し -- 次の四半期 (30 September 2010 に終了する) に対するガイダンスとして提供されたのは次のどれか:

  1. Apple は、売上げ $18 billion, そして希薄化後一株利益 $3.44 を予測している。
  2. Apple はおよそ $175 million を 12月期に繰り延べするが、これは iPhone 4 を購入した顧客に対する無償ケースの提供に必要と予測される金額である。Apple はケースが実際に顧客のもとに配達された時点でそのコストを計上すると言っている (これは 3 から 5 週間後であろう;複雑な会計原則に関係しているのであろう。 更なる情報に関しては "Apple、iPhone 4 アンテナ問題に答える" 16 July 2010 を参照。)
  3. Apple は iPad を新たな 9ヶ国で発売する。
  4. "我々がどれだけ利益をあげようが、これらの不機嫌なアナリスト達を満足させる事は決して出来ないであろう。"

これらの結果がどれだけ実際と合うのかは 10月になるまで待たねばならないが、それまでの間、Apple は引き続き好調を維持すると見るのはまず安全であろう。Jason Snell が Macworld の Live Update: Apple Q3 Earnings Call (我々もこの記事のための数字の多くをここから取った) で 言ったように、"Apple は今や業界の巨人になったと言っても間違いないと私は思う"、そしてもはや昔の "苦境に立つ" Apple でもない。

クイズに挑戦して頂いてありがとう!あなたの正解数をすべて合計し、それを 42 倍し、11 で割る、そしてそのスコアが幾つになったかに関わらず、あなたはあなた自身 Mac 通であると思ってよろしい。

コメントリンク11445 この記事について | Tweet リンク11445


iOS におけるアプリと書類

  文: Matt Neuburg <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Macintosh には、書類を一つのアプリケーションに対応させるという考え方が常に存在している。Finder で書類のアイコンをダブルクリックすれば、その書類に対応したアプリケーションが起動して、その書類を開く。このメカニズムはそれ自体、長年の間にいろいろな浮き沈みも経験してきた。ある時にはより高機能なものとなったし、ある時にはより荒削りのものに戻ったこともある。(2009 年 9 月 6 日の記事“Snow Leopard、クリエータコードにひじ鉄砲”参照。)それでも、少なくともこのメカニズムは常に使いやすく、全体的に言えばきちんと動作している。

iOS 3.2 から始まったことだが、iPad でも(そして今では iOS 4.0 により iPhone と iPod touch でも)書類のタイプをアプリに対応させるようになった。けれども、これら両者はほとんど比較にもならない。Macintosh のメカニズムを宇宙に飛び立つロケットに例えるならば、iPhone のメカニズムはまるで無声映画の中で羽根をバタバタさせたあげく、納屋に墜落して行くオンボロ自動車みたいだ。

iOS の下では、Finder は存在しない。また、ユーザーの目に見えるファイルシステムもない。(少なくとも機器を jailbreak したことのない普通のユーザーの目には見えない。)だから、書類をどれか他のアプリで開くオプションをユーザーに提供するか否かは、書類を処理する個々のアプリに任されているのだ。大多数の iOS アプリはいくつかの特定の書類タイプを処理するように作られていないし、たとえそのように作られていたとしても、そのオプションを提供するようにはなっていない。だから、話はそこで終わりになってしまう。

もしもアプリがそのようなオプションをユーザーに提供したいと思ったならば(例えば Safari や Mail がその例だが)そのアプリはシステムを呼び出して限定された範囲内のアクションを実行させることができる。システムはその書類のプレビューを示すことができるし、Options ダイアログを出すこともできる。また、Open In ダイアログを表示することもできる。結局のところ、両方のダイアログは基本的に同じことをする。例えば、Options ダイアログはその書類を開かせるアプリを選択肢として出すだろうし、それに加えて Open In ダイアログを開くというオプションも提供するだろう。だから、結局、問題は Open In ダイアログだ。そこに、その書類を開くことのできるアプリがリストされる。ユーザーは、そのリストにある名前の一つをタップするか、あるいは何もせずに Cancel をタップしてダイアログを閉じるか、どちらかをすることになる。

Image

注意すべきは、アプリが Open In ダイアログを表示している訳ではないし、アプリはそのダイアログの内容を何も知らないということだ。このダイアログは、あくまでもシステムに属している。ある特定のタイプの書類を開けるアプリとして他にどのようなものが存在しているのかを、アプリがシステムに問い合わせる方法はない。どうやらこれは、iOS の持つ「サンドボックス」方針のあらわれのようだ。つまり、アプリは厳しく範囲の決められた空間の中のみで動作を許され、他のアプリの領域に踏み込んだり、さらには他のアプリについて何かを知ったりすることが許されないのだ。

(ただし、例によって Apple 独自のアプリだけは、他のアプリならば手を触れることのできないようなシステム情報を知ることができる。Mobile Safari では間違いなくそうなっている。なぜなら、Mobile Safari は Open In ダイアログを表示せず、その代わりに独自のインターフェイスを使うからだ。これは、与えられたファイルをどんなアプリが開けるかという情報を何らかの方法でシステムに問い合わせなければできないことのはずだ。)

Image

同じく「サンドボックス」方針の理由によって、アプリが書類を見つけるために使える中心的な書類保管場所のようなものはない。標準の Open ダイアログを使って iOS アプリを見つけることはできない。なぜなら、iOS には標準の Open ダイアログが存在しないからだ。ファイルシステムを全体として調べるための設備は一切内蔵されていない。一つのアプリは、自分の サンドボックス内部にあるファイルシステムに書類を保管しておくことはできるし、そのファイルシステムを調べるための独自のカスタムインターフェイスを表示することはできるが、自分のサンドボックスの 外側 を見ることはできない。

そういうことならば、Open In ダイアログへの反応として、アプリはどうやって現在他のアプリのサンドボックスにある書類を開くことができるのだろう? それは、すべてシステム次第だ。特定のタイプの書類を他のどのアプリが開くことができるかをアプリは知らないが、システムは知っている。同じように、アプリが自分のサンドボックス内部から別の場所へ書類を移動させることはできないが、システムにはできる。もしも、システムの Open In ダイアログで、ユーザーが書類を第二のアプリで開くことを選んだならば、システムがそれを引き受ける。システムは、その書類を第二のアプリの Inbox フォルダに置く。このフォルダはその第二のアプリのサンドボックスの内部にある。それから、システムはその第二のアプリを起動して(あるいは前面に持ってきて)新たな場所にあるその書類を開くようにというメッセージをその第二のアプリに送る。

では、システムはどのようにして特定のタイプの書類をどのアプリが開くことができかを知っているのだろうか? 少なくともその点は、Mac OS X と似ている。各アプリのバンドルの中に、Info.plist と呼ばれる XML リソースが含まれている。システムはこれを読んで、そのアプリに関するさまざまの重要な情報を知る。例えばそのアイコンファイルのある場所や、どの nib ファイルに起動時インターフェイスが含まれているか、といったことだ。そして、この Info.plist にはそのアプリが開きたいと思う書類のタイプのリストを含めておくこともできる。そのリストでは、それぞれのタイプが uniform type identifier (UTI、統一タイプ識別子) によって指定される。(UTI は、旧来の4文字クリエータコードの現代版でもあり、同時にファイル拡張子と MIME タイプの間の対応付けをすることもできる。詳しくは、さきほど引用したクリエータコードに関する記事を参照されたい。)

さて、私はまだパズルのピースのうち二つに触れていない。その理由は、それら二つは本当の意味で この パズルのピースではないからだ。一つ目は、きっと皆さんもお気付きと思うが、iOS 機器をコンピュータに接続させている間、iTunes の中の File Sharing インターフェイスを通じていくつかのアプリの中へ書類をコピーすることができるということだ。これは、実は全く別のメカニズムだ。単純なオンかオフかの切り替えしかない。つまり、ユーザーがそのアプリのサンドボックスの中にある特定のディレクトリとの間で iTunes を使ってファイルを双方向にコピーできるか、それとも全然できないかのどちらかだ。

(さらに問題を複雑にしているのが iBooks だ。当然ながら iBooks は iTunes との間で特別の関係を持っている。なぜなら、これは Apple 独自のアプリだからだ。iTunes の Books カテゴリーにあるファイルを iBooks がどのようにして獲得するのか、説明できる人はいない。)

二つ目として、カスタム URL というものもある。個々のアプリが URL スキームを定義することができる。例えば "myScheme://something/or/other" といったものだ。そして、Web 表示でその URL がタップされた場合、あるいは他の方法でその URL がシステムに送られた場合、そのアプリが通知を受けることになる。けれどもこれは書類のタイプとは一切関係ない。どちらかと言えばこれはメッセージを送るための秘密のコードといったものであって、あるアプリがそれを定義し、ユーザーが、あるいは他のアプリが、その秘密を知っている場合にのみ利用できる。その上、そうしたメッセージを受け取った場合にアプリがどのように反応するかは、完全にそのアプリに任されている。

要約すれば状況はこうだ: 好きな書類をあなたが一つ選んで何らかのアプリがそれを開くよう指示することはできない。あなたが好きな書類を勝手に選ぶことすらできない。あなたが Open In ダイアログを目にすることができるのは、何らかのアプリがその書類に遭遇して、かつそのアプリが Open In ダイアログを出したいと思った場合のみだ。あなたは、あるファイルのタイプを開く用意があるのはどのアプリなのか、容易に知ることはできない。それは、アプリにそれができないのと同じ理由だ。アプリのバンドルの中を覗いてその Info.plist を眺めることのできる手軽な方法はないし、アプリが(ただし Apple 独自のアプリを除いては)そのような問い合わせを実行できるシステムコールもない。iOS に書類の処理を実行させようと思うなら、全体的に言って、その手順を例えれば、まるで誰かに編み物を教えようという時に、相手の人はミトン(指なし手袋)とイヤーマフ(毛糸の耳当て)をしているし、あなたの方は目隠しをしているようなものだ。

コメントリンク11430 この記事について | Tweet リンク11430


Take Control が iOS 上のアプリと書類で直面する問題

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

iPad が登場するより以前は、私たちの Take Control 電子ブックを iPhone や iPod touch で読みたいというリクエストがあまり届かなかった。けれども iPad が世に出るやいなや、この機能を希望する読者たちからの便りがどっと押し寄せるようになった。

私たちの望みは、そしてそれが実現できない理由は -- あなたが電子ブックを一冊買い物しようと思えば、別に何も難しくないはずだ。ウェブベースのカタログを一覧して、オンラインのカートを使って代金を払い、新しく手に入れた電子ブックを、あなたの機器にダウンロードするだけだ。その機器はラップトップあるいはデスクトップのコンピュータであろうと、新型の iPhone 4 や、iPad であろうと、旧型の iPhone や iPod touch であろうと、あるいはおそらく Android 携帯電話やその他の機器であっても構わないはずだ。

そして、Take Control ウェブサイトやカートでもそういうことはできるが、ただ一つ、ファイルをダウンロードするところだけが例外だ。私たちはまだ Android やその他のハンドヘルド機を真剣に考慮したことはないが、最近相当の時間を費やして、どうすれば iOS 機器にもダウンロードできるようになるのかを調べだり、iOS がアプリと書類との繋がりをどう扱うのか研究したりした。この研究の結果書かれたのが Matt Neuburg の記事“iOS におけるアプリと書類”(2010 年 7 月 15 日) だ。まだ読んでおられないなら、ぜひ Matt の記事を先にお読み頂きたい。私の記事の内容は、その予備知識がないと分かりにくいと思う。

さて、Matt が記事に書いていることを、出版者の立場から考えてみよう。ダウンロード可能なコンテンツ、例えば購入済みの電子ブックや、ソフトウェアマニュアルなどを、iOS 機器のユーザーたちに提供するためのインターネットサービスを提供する、そういう出版者の側から見てみよう。例として私たちの Take Control シリーズを考えれば、私たちはいくつかの障害に直面している:

私たちのカートではショッピング手順の最後に iOS を使う顧客に対してストレートな PDF を提示する機能を付けていないが、そのような機能はただ問題を招き寄せる以外の何物でもないだろう。ストレートな PDF のダウンロードは、iOS 4 でならば機能するかもしれない。その場合、Safari が通常通りの Open In ダイアログを開いてくれるからだ。けれども iPad 上の iOS 3.2 では、Safari は PDF の表示はするけれどもそれを他のアプリで開いて保存することは許さない。そのページから別のページへナビゲートするやいなや、その PDF は消えてしまう。それに、私たちのカートにあるダウンロード用の URL は限られた期間内しか有効でないので、後日その PDF を再ダウンロードすることもできない。これでは、良いユーザー体験とは言えない。

幸いにも、iOS ユーザーのためにより良い代替方法を探していた私たちは、たまたま新しい Take Control アカウント管理システムの構築も進めている最中だった。ある時点で、私たちは妙案を思い付いた。iOS ユーザーは、私たちのウェブサイトにログインした時点で、自分の電子ブックをダウンロードすればよいのではないか、と。私たちのサイトにはすべての電子ブックの PDF 版があり、多くの電子ブックについては EPUB 版と Mobipocket 版もあった。ユーザーは自分のアカウントにログインしてから PDF 版の電子ブックを Safari で読むこともできるし、GoodReader の中へダウンロードすることもできるだろう。電子ブックを読む環境としては Safari より GoodReader の方が優れている。 PDF については簡単に実現できることで、現在はこれで動作している。

でも、EPUB 版はどうだろうか? Apple の iBooks アプリの場合は、iTunes の Books カテゴリーにコピーされた EPUB ファイルを表示することができるのだが、実は iBooks は EPUB の UTI を持ったファイルを開くよう自己登録していない。Safari にロードしたページの上にある .epub ファイルのリンクをタップすれば、他のアプリがそれを開くことを申し出るかもしれないが、iBooks はそれをしない。さらに悪いことに、ユーザーが EPUB ファイルを開くアプリを持っていない場合、Safari はただ「ダウンロードに失敗しました。Safari はこのファイルをダウンロードできません。」と言ってくるのみだ。これも、良いユーザー体験とは言えない。

なぜ iBookstore では駄目なのか? -- この問題への一つの解答は、私たちの電子ブックを iBookstore にアップロードすることだ。そして実際、私たちは何冊ものタイトルでそれを実行している。(iBooks の中から "Take Control" を検索して頂ければわかる。)けれども、私たちから見て iBookstore が完璧な解決法だとは考えられない。それにはいくつも理由がある:

さらに、いろいろな書類を形式張らないやり方で iOS 機器にダウンロードできるようにしたいけれど、現時点での iOS のやり方に任せるほど形式張らないのは好まない、と考える団体や個人はきっと他にも大勢いるだろう。例えばパンフレット、ポスター、大学のコースカタログ、ニュースレターなどといったものは、基本的に iBookstore には馴染まない。

書類たちは暗闇の中に -- そういうわけで、私たちがインターネットベースの電子ブックファイル提供を推し進めて行きたいという前提の下に、良いユーザー体験とはどんなものである べき かを、ちょっと考えてみよう。問題は、個々の iOS 機器がどんなファイルタイプを開けるのか、それがどのアプリで開かれるのかを、誰もあらかじめ知ることができないという点だ。この疑問を探究するため、私はシンプルなウェブページを作り、そこに PDF、EPUB、Mobipocket の各ファイル、それに Zip ファイルへのリンクを入れてみた。そして、いろいろな機器上の Safari でこれらのリンクをタップして、何が起こるかを見てみた。それから、Safari 以外では違った結果になるのかどうかを調べるため、Matt がそれらのフォーマットそれぞれのサンプル書類を含んだ小さなアプリを書いて、ユーザーが対応するボタンをタップした際に Open In ダイアログが表示されるようにした。

残念ながら、実験の結果はてんでんばらばらだった。iOS 3.2 ベースの iPad は iOS 4 ベースの iPhone とは少し違った挙動をしたし、異なる機器は与えられたファイルタイプを開く際にそれぞれどんなアプリがインストールされているかによって異なるオプションを提供した。実際、iBooks が Open In ダイアログ経由で EPUB を開くことができないとか、iPad の iOS 3.2 における Safari が PDF 用の Open In ダイアログを提供しない(iOS 4 の Safari は提供する)とかいう事実を私たちが知ったのも、この実験結果のおかげだった。だから、Safari はリンクされたファイルのさまざまなタイプのものを開くことができ、それを他のアプリに手渡す可能性はあるのだが、その際に以下に挙げる三つのことのどれかが起こる:

iPad 上では、EPUB ファイルを StanzaGoodReader_BookShelfそれに CloudReaders で開けることがわかった。ただ、実際に EPUB ファイルを表示できるのは Stanza のみだ。また、Bookshelf が Mobipocket ファイルを開いて表示できることもわかった。BookShelf、CloudReaders、GoodReader はすべて Zip が開けると称しているが、実際にできるのは GoodReader のみだ。PDF を開けるアプリは iBooks や GoodReader をはじめたくさんある。(当初私たちが iPhone と iPod touch でテストしたところでは、GoodReader は Open In ダイアログに全く登場していなかった。その時点では、まだ iOS 4 用にアップデートされていなかったからだ。これもまた、絶え間なく進化を続ける iPhone システムに対応するためアプリたちが書き直されコンパイルし直されなければならない分野の一つだと言える。2010 年 6 月 23 日の記事“高速アプリ切り替えとは何か?”参照。)

信頼できる明確な手順説明を書こうと常に努めている私たちにとって、このような状況は心底堪え難い。Take Control において、私たちは読者へのサービスの一環として、インターネット経由で電子ブックを提供して、ユーザーたちがそれを何か適切なアプリで開くことができるように手を貸したいと思っている。けれども、それは私たちにとってこの上ない難題だ。なぜなら、あるユーザーの機器の上で何が起こるか、予想する方法がないからだ。

もしも私たちが iOS アプリを書くなりウェブページをコーディングするなりすることでユーザーの持っている選択肢をチェックし「あなたは EPUB を開けるアプリをお持ちです。この本を EPUB 形式でダウンロードしましょうか?」と提示することができたなら、それは素晴らしいことだ。でも、ユーザーがどんな選択肢を持っているかを知ることのできる方法を、私たちは知らない。特定のタイプの書類を開くことのできるアプリとしてそのユーザーがどんなものを持っているか、私たちが探知することはできない。中心的な保管場所もないので、特定のタイプの書類を開ける具体的なアプリがあるかどうか調べることさえできない。その一方で、もしも私たちが単純に電子ブックへの URL だけを提供してユーザーがそれを Safari で開くようにしたならば、それはつまり私たちがコントロール権限をすべて Safari に譲り渡してしまうことを意味し、その場合に Safari はこの書類を開くアプリがないとユーザーに告げるかもしれない。そうなればユーザーは混乱して、立ち往生し、きっと私たちに怒りの矛先を向けるだろう。

当面の解決策 -- では、私たちはどうしたか? 二つのことをした。まず第一に、iOS 機器からロードされた場合、私たちのカートの最初のスクリーンに青い字の注意書きを追加するようにした。注文を済ませた後にどうすればよいか、顧客たちにあてたアドバイスを入れたのだ。

image

第二に、あなた自身の Take Control アカウントページを iOS 機器から開けば、購入済みの個々の電子ブックごとに PDF ファイルをダウンロードするリンクが二つずつはっきり見えるようにした。一つのリンクは Safari にファイルをダウンロードし、もう一つのリンクは GoodReader にダウンロードする。GoodReader のみが理解する ghttp: スキームを使っているのだ。私たちとしては、後者をお勧めしたい。そちらの方が良いユーザー体験が得られるからだ。(実際、これでダウンロードされるのは zip 圧縮された PDF だ。これを GoodReader が展開でき、その結果、その本そのものが丸ごと手元に残って GoodReader に表示される。単に PDF のファイル名だけが残るのではない。)

私たちはこれらの決断を(それと、私たちの使っている具体的なインターフェイスを)定期的に見直して行くつもりだ。もしもより良いやり方が見つかれば、それを実装して行きたいと思っている。現時点ではまだはっきり言って手探りの状態なので、皆さんからの提案を歓迎したいと思う。

今のところ、私たちの電子ブックの EPUB 版や Mobipocket 版を読者が直接ダウンロードできるようにはしていない。それらはあなたの Take Control アカウントから zip アーカイブとしてのみアクセスでき、デスクトップまたはラップトップのコンピュータからしかアクセスできない。その理由は、さきほども述べたように、iBooks がまだ EPUB ファイルをリンクから開くことができないからだ。そうしたリンクは扱えるアプリは、今のところ Stanza (EPUB) と Bookshelf (Mobipocket) しかない。けれども、将来になっていろいろなアプリが(特に iBooks が)追い付いて来るようになれば、iOS の内部からもそれらのファイルをダウンロードできるようにする予定だ。

(不審に思われた方のために言い添えると、私たちは PDF、EPUB、Mobipocket ファイルのバンドル販売をしていない。その理由は、EPUB や Mobipocket への変換が済むのを待つためだけに出版を遅らせたくないからだ。また、ダウンロードする時期によってユーザーが違ったものを手にするようにもしたくないからだ。)

全体的に見て、この話の教訓は、Apple が iOS においてアプリと書類に関すること全体をもっと合理的でオープンなものにしてくれるまでは、それぞれの書類タイプはそれぞれ個別に処理せざるを得ず、場合場合に応じた対応が必須となる。つまり、インターネットからダウンロードする形で書類を提供したいと思う人は誰でも、さんざん頭を掻きむしり、際限なくフラストレーションの溜まる思いをしなければならないということだ。書類をタイプに分けることが良いアイデアであるのは言うまでもないが、Apple はもう少し縛りを緩めて、ユーザーたちにも開発者たちにも、どちらにももっと良い体験を提供できるようにすべきだ。そうしなければ、Apple がこれまで提供したものがないよりもなお悪いなどと言いたくはないが、正直それに近いと言わざるを得ない。

コメントリンク11459 この記事について | Tweet リンク11459


TidBITS 監視リスト: 注目のアップデート、2010 年 7 月 26 日

  文: TidBITS Staff <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

1Password 3.3 -- Agile Web Solutions が、人気のパスワード管理ユーティリティ 1Password に大きなアップデートをリリースした。バージョン 3.3 では Dropbox との統合を改善し、ベータ版の Firefox 4 のサポートを追加し、Camino 2.0.3 のサポートを追加した。1PasswordAnywhere には検索機能とコピー機能が加わり、アイドル時間が 1 分間を超えるとロックされるよう設定できるようになった。また、今回のアップデートでは Firefox の 1Password ツールバーボタンで最初にクリックした際に登録できなかった問題点が修正され、修飾キーを押すと 1Password メニューが開いて閉じることのあった問題も解消した。28 件の修正点をすべて記したフルリリースノートは Agile Web Solutions のウェブサイトで読める。(新規購入 $39.95、アップデート無料、15.1 MB)

1Password 3.3 へのコメントリンク:

Wiki Server Update 1.0 -- Apple の Wiki Server Update 1.0 (Mac OS X 10.6 Snow Leopard Server の一部) は、少数の一般的な信頼性の問題点に対処したマイナーなメンテナンス・アップデートだ。対処の施された問題点としては、ユーザのフルネームに高ビット文字(アクセント付きの文字など)が使用されているユーザの認証、iCal クライアントから Wiki グループカレンダーへのアクセスの許可、Leopard Server からの移行後 Wiki およびブログにアクセスできなくなる問題、フルネームを使用しているユーザによりページが変更された後の Wiki サービス開始、プライベートブログにオーナーがアクセスした際のプライベートブログの表示の問題などがある。このアップデートでの変更点はリリースされたばかりの Snow Leopard Server 10.6.4 アップデート 1.1 (deltaおよび combo) にも含まれており、ソフトウェア・アップデートから、あるいは Apple のサポートダウンロードページからも入手できる。(無料、26.3 MB)

Wiki Server Update 1.0 へのコメントリンク:

Firefox 3.6.7 -- Mozilla の Firefox 3.6.7 は、少数のセキュリティ脆弱性と多数の安定性のバグに対処したマイナーなメンテナンス・アップデートだ。このアップデートで対処の施された 126 件の安定性の問題はマイナーなものか、あるいは高度に技術的なものばかりだが、 そのリストをじっくり調べたい人は Mozilla のウェブサイトに行けば読める。今回対処の施された重大なセキュリティ脆弱性は、いつも通りに任意のコードが実行されたりアタッカーがメモリをコントロールできたりする可能性のあるものだった。より詳しいセキュリティノートもある。(無料、19 MB)

Firefox 3.6.7 へのコメントリンク:

iTunes 9.2.1 -- Apple がiTunes 9.2.1 をリリースし、数多くのバグを修正するとともに、項目のドラッグ&ドロップ時に起きる小さな問題に対処し、互換性のない他社製プラグインの古いバージョンの使用を停止し、iTunes 9.2 で一部のデバイスと初めて同期する際に起きるパフォーマンスに関する問題を修正、暗号化されたバックアップがある iPhone または iPod touch を iOS 4 にアップグレードする際に起きる問題を解決した。それに加えて、このアップデートでは重大なセキュリティの脆弱性一件にも対処している。iTunes 9.2.1 はソフトウェア・アップデートから、あるいは Apple のサポートダウンロードページからも入手できる。(無料、101.82 MB)

iTunes 9.2.1 へのコメントリンク:


ExtraBITS、2010 年 7 月 26 日

  文: TidBITS Staff <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今週、黒の iPhone 4 が新たにあと 17 カ国で発売になる。その一方で、白の iPhone 4 の発売は世界中でまたもや延期となり、今年後半の発売予定となった。iOS 機器についての他のニュースとしては、iPad がかなり多数の大学で学術用途での採用に向けてテストされ、冗談製品 Antenn-aid が Band-Aid 風のカスタム絆創膏で iPhone 4 のアンテナのトラブルを防ぎ、"Don't Hold It Wrong" ブログが他の携帯電話の説明書にも握り方の注意書きがあることを指摘し、それから無料の iPhone 4 ケースを欲しい人は無料の iPhone アプリを使って注文ができる。また、Safari が AutoFill (自動入力) を通じてあなたの個人情報を漏らしてしまう可能性があるという記事はぜひお読み頂きたいし、インターネット上にデータが残ることの悪影響について Jeffrey Rosen が書いた素晴らしい論説も必読だ。

iPhone 4 が 17 カ国でデビュー -- Apple の発表によれば、2010 年 7 月 30 日の金曜日に、iPhone 4 が新たに以下の 17 カ国で発売になる。オーストラリア、オーストリア、ベルギー、カナダ、デンマーク、フィンランド、香港、アイルランド、イタリア、ルクセンブルグ、オランダ、ノルウェー、ニュージーランド、シンガポール、スペイン、スウェーデン、スイス。iPhone 4 の購入は Apple のオンラインストアまたはリテール店で、あるいはすべての Apple 正規販売店でできる。

コメントリンク: 11463

Apple iPhone Case アプリで無料ケースの注文を -- Apple がアンテナ問題を緩和するための無料 iPhone 4 ケースの注文受け付けを開始した。注文は、新たに出された iPhone 4 Case Program プログラムを使ってのみできる。その際認証のためにあなたの iTunes アカウントパスワードが必要となる。それから、ケースを選択して(Apple の黒いバンパーケースか、いくつかのサードパーティ製品の中から選べる)配達のための情報を入力し、注文を送信して、3 週間から 10 週間(ケースにより異なる)待てば届く。注文は一回限りしかできないので、その後はこのアプリを消去してしまってもよい。

コメントリンク: 11455

インターネットで忘れる方法を覚えよう -- New York Times に寄稿記事を書いている Jeffrey Rosen は George Washington 大学の法律学の教授だが、ウェブ上にデータがいつまでも残ることの悪影響を論じた思慮深い記事を書き上げた。ソーシャルネットワーキングサービスを通じて個人的情報を共有している人たちは、自分の過去の行動、信条、当時自分がどんな存在であったかということがすべて子々孫々まで保存されるという、途方もない能力をインターネットは持っており、そのため現実と仮想の区別や、過去と現在の境界線が限りなく曖昧になってしまってさまざまの問題が起こるという事実に、否応無しに折り合いをつけざるを得ない。Rosen は、忘れることができないというこの新しい状況を克服するために、私たちが用いることのできる法律的、技術的、そして社会的な解決策について概観を述べている。

コメントリンク: 11453

iPad,大学に行く -- Ars Technica が、iPad を学術的活動に統合させるための実験を行なう大学がますます増えつつある、と伝えている。予備的なパイロットプログラム(Princeton による Kindle 実験に似たもの)を実施中のキャンパスも二つあり、新入生全員に iPad を提供しているところや、優秀な学生を選んで与えているところ、大学院生の一部に配っているところもある。また、少なくとも North Carolina 州立大学では、大学図書館にたくさんの iPad を揃えて誰でも使えるようにしている。(この機器の目的が個人使用を強く志向していることを考えれば、これはちょっと奇妙な使用形態にも思える。)

コメントリンク: 11452

Safari が自動入力で個人情報を漏洩 -- Jeremiah Grossman が発見し解説したのは、Safari 4 および 5 に内在する潜在的に重大なセキュリティ欠陥だ。基本的に、Safari の自動入力オプションで「自分のアドレスブックカードの情報を使用」を有効にしていると、悪意あるウェブサイトによってあなたの名前、会社名、住んでいる都市・州・国名、それに電子メールアドレスがあなたの知らないうちに読み取られてしまうおそれがある。現時点では、Safari の自動入力環境設定パネルでそのオプションをオフにしておくことをお勧めしたい。Apple は New York Times に対して(ただしこのバグを報告した Grossman にではなかった)「問題は認識しており修正を開発中」だと述べた。

コメントリンク: 11451

Apple、白の iPhone 4 を「今年後半」まで延期 -- iPhone の製造は見かけより難しいらしい。白い機種の iPhone 4 の発売をいったん「7 月後半」まで延期していた Apple が、今回これをさらに延期すると発表した。発表には次のように書かれている:「Apple の新しい iPhone 4 のホワイトモデルは、当初の想定以上に、生産をするにあたり困難な状況が続いています。その結果、お客さまへのお届けは今年後半になる予定です。なお、ブラックモデルの供給状況には、影響はありません。」

コメントリンク: 11450

Antenn-aid で iPhone 4 の信号の痛みを癒す -- Apple は最近開いた記者会見で、iPhone 4 のイメージが報道により受けた傷跡を癒そうと願った。でも、さらなる癒しの手段がある。Antenn-aid は、Band-Aid (バンドエイド) 風の絆創膏型ビニール製ステッカーで、あなたの iPhone 4 のアンテナの切れ目を覆って貼り付けるようになっている。これは主として冗談のためのものだが、ごついゴム製のバンパーを付けるのはどうもと思っている人には、ちょっと試してみる価値があるかもしれない!

コメントリンク: 11442

"Don't Hold It Wrong" が非難を広げる -- 他社の携帯電話も信号受信の際に "death grip" 問題に影響されるという Apple のビデオに納得できない? ならば、David Chartier が自身の Don't Hold It Wrong ブログに新たな証拠を提示しているので読んでみよう。彼は、いくつかの YouTube ビデオや、またユーザー向けハンドブックの記述などの実例を引用して、これは業界全体に共通した問題であって秘密でも何でもないことを示している。(追伸: このブログの About ページは、絶対に小さい子供に見せてはいけない。)

コメントリンク: 11441


tb_badge_trans-jp2

TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

©Copyright 2010 TidBITS: 再使用は Creative Commons ライセンスによります。

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2011年 1月 8日 土曜日, S. HOSOKAWA