アークウェブのブログ

まずは、Google GearsがどのようにしてオフラインでWebを閲覧するかのようにしているのか確認します。

Google Gears
http://code.google.com/apis/gears/

ベース技術は「ローカルサーバ」「データベース」「ワーカープール」の３つがあります。
詳しくは上記URLを参照してほしいのですが、かいつまんで説明します。

『ローカルサーバ』
Webアプリケーションが動作するURLのキャッシュです。
通常、我々がどこかのWebにアクセスする場合、URLにアクセスしてコンテンツを表示します。
ローカルサーバは、ローカルで動作するWebアプリのURLのキャッシュ、というわけですね。

このキャッシュは2種類あって、そのときだけのURL保持と、ファイルに保存するものがあります。
ファイルに保存することで、後からオンラインとデータを同期する際に利用できるようです。

『データベース』
オープンソースのSQLiteをDBとして使用しているそうです。
これによって、オフライン環境でもデータの検索ができるようになります。
セキュリティ面の配慮として、同一DomainのURLに対するデータベースにのみアクセスできるようになっているとのこと。

ローカルアプリを作る際は、SQLInjectionに気をつける必要がありますね。
SQLiteのデータは、ユーザのデスクトップ上に保持されます。

『ワーカープール』
Developer's Guideには下記のように書いてあります (ただし竹村の意訳です^^;)
> メインページのスクリプト実行を妨害することなく、Webアプリケーションが
> バックグラウンドでJavaScriptコードを走らせるのを許可します。

AjaxやJavaScriptなどがクライアントサイドのCPU/メモリをかなり使用するタイプのWebサイトへアクセスしたことはありませんか？ そのような際は、コンテンツが表示されるまではその他のJavaScriptコードは動作しない、もしくは著しく重い、という思いをされるはず。

ワーカープールは、あるスクリプトコードの実行を妨げることなく別のスクリプトコードを実行できるようなので、バックグラウンドでデータベースを検索している間でも、フォアグラウンドでJavaScriptのコードを実行し続けることが可能になると思います。

これにより、ユーザーの体感速度を遅くしないようにできるわけです。

さて、Google Gearsについては何となくどういう仕組みか分かったところでAdobe Apolloとの違いについて考えてみます。

まずApolloは、HTML、JavaScript、Ajax、Flashによるローカル環境でも動作するアプリケーションが作れるというものですね。

Apolloの強みとしては、ブラウザ/プラットホームに依存しないので実装後のテストは少し楽ができると思います。また、ブラウザに依存しないので、ウィンドウの変更などユーザの嗜好に合わせて好きなようにカスタマイズできる点がかなりデスクトップアプリらしいように思います。

ただ、Google Gearsに劣るとであろう箇所としては、AjaxやJavaScriptの処理はバックグラウンドで実行されないため、重い処理が走っている間はユーザは待たなければならない点。またもう一点、Apolloアプリはデータベースをローカルに保持しないので、「ローカルのデータを検索する」という部分では弱いように思います。

逆に考えれば、1ページに表示する要素をあまりゴテゴテしすぎないようにし、シンプルにレスポンスを返すアプリケーションを開発する場合にはApolloは向いているのかもしれません。

Webの延長を非Web(ローカル・デスクトップ環境)でも実現したい場合はGoogle Gearsが向いている、というように思います。

オフラインアプリの特性を意識して、開発・提供する環境を使い分けるようにしたいですね。