2011-08-24 7 views
5

私のWebアプリケーションをオフラインで作業できるようにしたいのですが、オンラインになったり、再び接続したりするとすぐに、ユーザーが行った変更をオフラインモードで転送できるはずです。J2EE Webアプリケーションをオフラインで動作させるにはどうすればよいですか?

私はこの問題の理想的な解決策としてGoogle Gearsを使用していますが、これは現在推奨されていません。

私のアプリケーションをオフラインで使用するには、使用するテクノロジとアプリケーションの設計の両方で、どのような方法が適していますか?

+0

代替手段を試すことができます。たとえば、オフラインモードで使用されるフラッシュアプ​​リケーションです。 Webアプリケーションはオンラインモードで使用されていました。 –

+0

オフラインストレージは過大評価されています。 – bhagyas

答えて

4

HTML5標準では対応ブラウザに同等の機能が存在するため、Gearsは非推奨です。

オフラインWebアプリケーションへのアクセスを処理する現在の問題点に関しては、client-side SQL database accessclient-side application HTTP cacheのサポートによってHTML5 for offline web applicationsのサポートを調べることができます。

クライアント側のデータベースアクセスでは、アプリケーションがオフラインのときに生成されたデータを構造化された形式で格納できるため、オフラインアプリケーションキャッシュではキャッシュを使用できるため、機能を併用する必要があります。サーバーからのHTTP応答。ユーザが提供する入力に依存する動的な応答をキャッシュしてはいけません。

提案されたAPIの詳細は、現時点では下書きされているW3C HTML5 specificationにありますが、特定のユーザーエージェントが既にこの機能を実装しているようです。

0

これはJ2EEとあまり関係ありませんが、Webクライアントをどのようにコーディングするかです。 1つの可能な解決策は、html5で導入されたローカルストレージにデータを保存するjavascriptクライアントを使用することです(http://diveintohtml5.ep.io/storage.htmlを参照)。これは基本的にGoogleの歯車が停止された理由です...

+0

私はそれらの友人を見たことがありますが、ブラウザのキャッシュがクリアされていれば動作しません。これはこのループバックの1つです。 – deepmoteria

1

まず、オフラインストレージが必要です。 HTML5の機能は、google gears developer blogに記載されているように、Google Gearsの後継機種です。本質的に、Google Gearsの目的は、HTML5の機能を引き続き採用するために、&の開発をプッシュすることでした。

具体的に、あなたはHTML5 offlinehere's a tutorial)のAPIを見てしなければならない、とStorage APIも(relevant tutorial)便利になることがあります。

デザインに関しては、完全なWebアプリケーション状態のクライアント側を維持し、サーバーへの接続が再び利用可能になるとすぐに差異を送信(つまり、サーバー側の状態を更新)する必要があります。

  1. 明示的にクライアントとサーバのための独立したアプリケーションの状態を維持する:私の頭の上オフ

    は、これを設計する2つの簡単な方法があります。基本的には、ユーザーがアクションを実行すると、クライアントアプリケーションの状態に最初に適用され、次に指定された間隔で(および/またはユーザーが保存ボタンをクリックするなどのトリガー)、クライアントは最後の既知の状態サーバーとクライアントの現在の状態。高度なインタラクティブなWebアプリケーションにはおそらく最適ですが、Google Docsはこの種のデザインで動作すると思われます。アプリケーションに応じて(変更が矛盾する場合)、アプリケーションの状態をマージする必要があります:最後に受信したクライアントの状態で上書きするのか、それともインテリジェントに結合しようとしますか? (特定のアプリケーションにはどちらが適しているかを判断する必要があります。)

  2. オフラインでユーザーの操作を記録し、接続が再び利用可能になったら再生します。基本的にはCommand design patternを実装し、クライアント側コードとサーバー側コードの両方で各コマンドを処理できるようにします。クライアント側のコードは常に各コマンドを処理し、サーバーへの接続が利用可能な間は、クライアント側のコードもコマンドをサーバーに送信します。サーバーへの継続的なリクエストを避けるために、いくつかのバッチ処理を実装し、サーバーへの要求が失敗した場合(たとえば、変更が競合する)ロールバック機能を実装することもできます。これは、GMailの主な電子メール管理ユーザーインターフェースのように、操作をやり直すことができます。

関連する問題