Windows 8ユーザーズ・ワークベンチ

その名は“Window 8”

 Windows OSは、複数のWindowを開いて、相互にデータをやりとりできるからこそ、最後に複数形を示す「s」がついている。ところが、Windows 8では、没頭型のインターフェイスを持たせたことで、Windowsというのはふさわしくない面もある。今回は、Windows 8におけるアプリ間でのデータ連携について見ていくことにしよう。

アプリ間でデータ共有

 Windows 8は、ハイブリッドOSとして、2種類のプラットフォームが共存していると考えていい。1つは旧来のクラシックデスクトップであり、もう1つがストアアプリによる新しいUIだ。

 デスクトップアプリは、何でもやり放題である点は従来と同様で、どのような経路でアプリを入手したとしてもインストールはたやすい。それに対して、ストアアプリは、リリースはMicrosoftの審査を経ていることが保証され、ストアを介してしか入手できない。そういう意味ではストアで入手できるストアアプリはきわめて安全であると考えてよさそうだ。

 そして、ストアアプリには、さまざまな制限が課せられ安全が確保されている。たとえば、ストアアプリ間ではドラッグ&ドロップによるデータの受け渡しができない。“Windows 8”が“Window 8”でないことの証として、ストアアプリは1個に限ってスクリーンサイドにスナップさせて、同時に2つのストアアプリを開いた状態にできるが、その状態であってもドラッグ&ドロップは許されない。

 その代わりに使われるのが「共有」だ。

 たとえば、新しいUIのInternet Explorerで、Webを見ているときに、このページは面白いからFacebookやTwitterで紹介したいと思ったとする。その場合は、スクリーン右からのスライドインやWindows + Cでチャームを出し、共有をタップすると、共有APIをサポートしたアプリの一覧が表示される。手元の環境には、標準アプリのほかに、結構な数のアプリがインストールされているが、メール、People、OneNote、MetroTwitがリストアップされた。

新しいUIのIE10でページを開いているときに、チャームから共有を実行すると、リンクの受信をサポートしたアプリの一覧が表示される

 それぞれをタップすることで、開いているページを共有できるようになっている。Windows 8のPeopleアプリには、FacebookとTwitterが統合されているので、どちらかでページのURLを紹介することができるわけだ。

 この時、ページ内の文字列を選択した状態で同じ操作をすると、今度は、その文字列を共有しようとする。同様の操作で共有しようとすると、文字列が選択された状態では、Peopleアプリが一覧にないことに気がつく。これは、テキストの受信をPeopleアプリがサポートしていないからだ。

 共有の場面では、データを送る側をソースアプリ、データを受け取る側をターゲットアプリと呼ぶ。アプリ間で共有できるデータとしては、書式なしのプレーンテキスト、リンク、書式付きコンテンツ、ファイル、画像といったものがある。これらのうち、何をサポートするかをあらかじめ宣言しておく必要があり、それについてはアプリの実装に委ねられる。

Peopleアプリでは、TwitterとFacebookがサポートされている。ここでは、TwitterにページのURLが送られる準備ができていることがわかる。これにコメントを書き足せばいい
文字列が選択された状態で、共有しようとすると、URL共有ではあったPeopleが一覧にないことに気がつく。これは、Peopleがテキストの受信をサポートしていないためだ

ファイルピッカーでファイルを開き、保存する

 ドラッグ&ドロップができず、共有もできない。そんな場合にも、ファイルを介してデータをやりとりできる可能性がある。まるでMS-DOSの時代のアプリに戻ったかのようだ。

 各アプリは、ファイル保存ピッカー、ファイルオープンピッカーに対して、参加することを宣言しておき、一般的なファイル操作ができるようにしておく。

 まず、ファイルオープンピッカーでは、そのアプリがサポートするファイルしか一覧に現れない。さらに、さまざまなアプリを試してみても、ファイル保存ピッカーが使えるアプリがほとんどないことがわかる。

 それぞれのアプリを使って作成したデータは、基本的に独自のデータとして、あらかじめ決められたAppDataフォルダに保存され、そのアプリ以外からのアクセスは許されない。ファイルでデータを連携することに積極的ではないアプリは保存ピッカーをサポートする必要がない。ユーザーは適当に中味だけを作成し、ファイル名を考えるといった作業をしなくても、勝手にデータは保存されるというわけだ。

ファイルオープンピッカーでは、ファイルシステムのほとんどにアクセスできるが、サポートされているファイルだけが一覧に表示される。これはストアアプリのAdobe Readerのファイルオープンピッカー

 例えば、標準のカメラアプリでは、撮影した写真は、特に指定しなくても個人用フォルダ内のピクチャフォルダにあるカメラロールフォルダに「画像nnn」という名前をつけて画像を保存する。同様のことが他のアプリでも行なわれるため、ストアアプリにおいてはあまり保存ということを考えなくてもいいようになっている。

 つまり、新しいUIでは、何かを作業したから、それをファイルとして保存するという概念が希薄だ。まさに、コンテンツ消費型の環境であるといえる。例外はSkyDriveなど、汎用的なクラウドストレージへの保存であり、その際には、相変わらずファイル名をつけて内容を保存するといった操作が求められる。

 ただ、それではフォトレタッチアプリなどで、写真を加工した際に、別のローカルファイルとして保存したいようなケースで困ることになる。そういう場合に、ファイル保存ピッカーがサポートされ、Windows OSのファイルシステム内の任意のフォルダにファイルを保存することができるわけだ。

 さらに、ストアアプリではアプリにデータを保存するという概念が取り入れられている。これは共有のメカニズムを使ったもので、文字通りファイルの内容をそのまま別のアプリのデータとして送信し、ターゲットアプリがそれを受け取る。たとえば、カメラで撮影した画像ファイルをレタッチソフトに送ったり、テキストデータをメモ帳アプリに送ったりといった具合だ。

フォトレタッチソフトなどではファイル保存ピッカーがサポートされる。レタッチした写真にファイル名をつけ、形式などを指定してファイルシステムの任意のフォルダにファイルを保存できる。これはレタッチソフトALSeeのファイル保存ピッカー

クリップボードは健在

 このように、新しいアプリ間連携がサポートされているものの、その扱いはかなり限定的なものとなっている。将来的に、アプリを開発する側も手慣れてくれば、もっと柔軟なことができるようになっていくだろうが、少なくとも現時点では、古式ゆかしきクリップボードを使ったコピー&ペーストによるデータ連携に頼るのがもっとも簡単だ。

 クリップボードによるコピー&ペーストはストアアプリ間でのデータのやりとりをサポートするのはもちろん、デスクトップアプリとストアアプリの間で、ファイルを介さずにデータをやりとりするための唯一の方法だといってもいい。

 しかも、デスクトップアプリでは、ウィンドウ間でのドラッグ&ドロップ編集ができないものはほとんどなく、アプリ間データ連携という点では圧倒的な優位性を維持している。こうした点からも、Windowsを情報の生産ツールとして使うためには、当面、クラシックデスクトップとそこで動くデスクトップアプリは欠かせない存在だといえそうだ。

(山田 祥平)