如何使我的J2EE Web应用程序脱机工作？

Question

我希望使我的Web应用程序能够脱机工作，并且一旦它变得联机或再次连接，它就应该能够在脱机模式下传输用户所做的修改。

我认为Google Gears是解决我的问题的理想解决方案，不建议使用它，因为现在已不建议使用。

在使用技术和应用程序设计方面，使我的应用程序脱机工作的最佳方法是什么？

Answer 1

不推荐使用Gears，因为HTML5标准允许在兼容的浏览器中提供等效功能。

关于当前处理脱机Web应用程序访问时遇到的问题，您可以通过对客户端SQL数据库访问的支持以及客户端应用程序HTTP缓存 ，来研究HTML5为脱机Web应用程序提供的支持。

这些功能必须结合使用，因为客户端数据库访问将允许以结构化格式存储数据（在应用程序脱机时生成），而脱机应用程序缓存将允许缓存来自服务器的HTTP响应。服务器; 您不应该缓存依赖于用户提供的任何输入的动态响应。

可以在W3C HTML5规范中找到建议的API的详细信息，该规范目前正在草拟中，尽管某些用户代理似乎已经实现了此功能。

Answer 2

首先，您将需要某种形式的脱机存储。 正如Google Gears 开发者博客上所述，HTML5的功能是Google Gears的后继产品； 本质上，Google Gears的目的只是推动HTML 5功能的开发和后续采用。

具体来说，您应该查看脱机的HTML5 API（ 这是一个教程 ），并且Storage API也可能派上用场（ 相关的教程 ）。

在设计方面，您基本上需要维护客户端的完整Web应用程序状态，然后在与服务器的连接再次可用时立即发送差异（即更新服务器端状态）。

在我头顶上，有两种简单的方法可以设计此方法：

1. 明确维护客户端和服务器的单独应用程序状态。 本质上，当用户执行某项操作时，首先将其应用于客户端应用程序状态，然后按指定的时间间隔（和/或触发，例如用户单击“保存”按钮），客户端发送过去的已知状态之间的差异。服务器和客户端的当前状态。 这可能最适合高度交互的Web应用程序，我怀疑Google Docs可以在这种设计上工作。 根据您的应用程序（如果可能发生“冲突的更改”），您还需要考虑合并应用程序状态：您是否使用上次接收到的客户端状态进行覆盖，还是明智地尝试合并？ （您必须确定哪种方法更适合您的特定应用程序。）

2. 离线记录用户操作，并在连接再次可用时重播它们。 本质上，您实现了Command设计模式 ，并且使您的客户端代码和服务器端代码都能够处理每个命令。 客户端代码始终处理每个命令，并且在与服务器的连接可用时，客户端代码也会将命令发送给服务器。 您可能要实现一些批处理，以避免对服务器的连续请求，以及对服务器的请求失败（例如，更改发生冲突）时的一些回滚功能。 最终看起来或多或少像GMail的主电子邮件管理用户界面，您可以在其中撤消操作。

Answer 3

这与J2EE无关，而与您如何编写Web客户端有关。 一种可能的解决方案是使用javascript客户端，该客户端会将数据确实保存在html5引入的本地存储中（请参阅http://diveintohtml5.ep.io/storage.html ）。 这基本上也是Google Gears被停止的原因...