HTML5にはアプリケーションキャッシュやストレージなど、オフラインアプリケーションを実現するための機能が用意されていますが、そもそもオフラインアプリケーションって何なんだろうって考えてみたいと思います。なぜかというと、オフラインアプリケーションと一言で言っても、どこまで「オフライン」である必要があるのかに差があるからです。
まずWebサイトを分類したいと思います。
- 閲覧をメインとしたサイト： WikipediaやAsahi.comなどの新聞サイトがこれに該当します。
- 個人用にカスタマイズしたコンテンツをメインにしたサイト： Facebook, Twitter, LinkedInなどがこれに該当します。
- データ入力や加工をメインにしたサイト： GmailやGoogle Docsがこれに相当します。
以下、それぞれについて考えていきます。
閲覧をメインにしたサイト
1の閲覧をメインにしたサイトについてはオフラインへのアプローチは２通り考えられます。一つはサーバから帰ってくるHTMLをそのままキャッシュすることです。もう一つはAPIでデータをJSONなどの形式でダウンロードし、これをキャッシュすることです。そして画面に表示するときはJSONデータからDOMを作ります。
どっちを選択するかに関わらず、このようなサイトに共通しているのは、ブラウザ側ではModelを持つ必要が無いということです。保存する内容はページの内容だけですので、ModelはせいぜいPage一つです。わざわざクライアントサイドのMVCフレームワークを用意する必要がありません。
このようなサイトで一番大きな問題はデータ量ではないでしょうか。Wikipediaであればすべてをローカルに保存するわけにはいかず、一部だけをダウンロードすることになります。それでも数千ページを保存すれば相当な容量になります。このデータを効率的にサーバから出力し、ブラウザ側で処理し、ローカルに保存していくかは簡単ではありません。
個人用にカスタマイズしたコンテンツをメインにしたサイト
実際問題、こういうサイトではオフラインの閲覧はほとんど実現できていません。例えばHTML5をやめてnative Appを開発していくということで話題になったFacebookのiPhone用アプリですが、オフラインで見られるのは以前に閲覧した内容のキャッシュです。先読みしてローカルにページを保存することはしません。したがってオフラインでやれるのは見直しだけです。
Twitter, LinkedInのiPhone用Nativeアプリも同じです。
ただ「いいね！」などはオフラインでも押すことができて、オンラインになるとその変更がサーバに送られることを期待しましたが、テストしてみたところ反映されていませんでした。
もともとこのようなソーシャルネットワークアプリはタイムラインを中心としたUIなので、タイムラインさえキャッシュすればほとんど用が足りると発想をしているのだと思われます。いずれにしてもオフラインではたいして使えないのが現状です。
このようなサイトを実現する方法は「閲覧をメインにしたサイト」とよく似ています。サーバから帰ってきた内容をキャッシュすれば良いのです。ただし内容が変更されることが頻繁にあるので、ネットワーク接続があれば積極的にデータを更新することになります。
データ入力や加工をメインにしたサイト
GmailやGoogle DocsはもともとデスクトップのemailクライアントやMS Officeをウェブ用に作り替えた製品であり、完全にオフラインで動作するようにGoogleがかなり開発をしてきた製品です。
これらの特徴は、様々に加工した後に作られるドキュメントが非常に独立していることです。デスクトップのアプリであればドキュメントはファイルシステム上のファイルであり、属性としてはタイムスタンプやフォルダー名、ファイル名、そして権限ぐらいです。Facebookの書き込み、コメント、いいねと違い、複雑なリレーションがありません。
このようなWebサイトはデータを加工するのには複雑なJavascriptを使う必要がありますが、一方でサーバとやりとりするデータはかなり境界がはっきりしていて単純です。この際に便利なのがクライアントサイドのJavascript MVCフレームワークです。ブラウザの中で複雑な処理が行われデータが加工されていきます。上述の「閲覧をメインにしたサイト」「個人用にカスタマイズしたコンテンツをメインにしたサイト」と異なり、ブラウザはデータに対して受け身ではなく、積極的にデータを作り、改変します。ブラウザ内での処理が複雑になりますので、MVCフレームワークの必要が出てきます。
このように、どのようなWebサイトでオフライン閲覧を実現しようとしているかによって、どこまでやるべきか、どこまでやれるかがかなり分かれます。
さて私が考えているのはソーシャル機能を持ったオンライン抄録集ですので、1, 2の機能を併せ持ったものになります。それを実現するために何が必要かを考えていきます。
ソーシャル機能を持ったオンライン抄録集ではブラウザ側のMVCは必要ない
オンライン抄録集は根本的には「閲覧をメインにしたサイト」ですので、各ページのデータをローカルに保管すれば十分です。ソーシャル機能については「個人用にカスタマイズしたコンテンツをメインにしたサイト」と同じように考えますので、普通に考えればオフラインでソーシャル機能を提供する必要はありません。したがってサーバのレスポンスをキャッシュするアプローチで十分です。
もし一歩先を行って、「いいね！」などをオフラインでも可能にしようと思うと、ブラウザの中にModelを作っていく必要が出てきます。しかしModelの数は少なくて済むと思われますので、全面的にクライアントサイドMVCを導入するのは無駄だと考えられます。
残念ながら適当なフレームワークがない
残念ながらこういう目的のJavaScriptフレームワークは存在しないのが現状です。Sencha Touchはローカルにデータを保存することができますが、完全なクライアントサイドMVCフレームワークなので今回の目的に合いません。
jQuery Mobile, jqMobiなどはサーバ側にHTMLの生成を任せているフレームワークで、クライアントサイドにModelを持つ必要の無いものです。しかし主眼はNativeアプリと似たようなUIをブラウザ内で実現することであり、ページをローカルにキャッシュする機能はありません。
Naofumi Kagami 