我想让我的网络应用程序能够脱机工作，一旦它上线或再次连接，它就应该能够在离线模式下传输用户所做的修改。
我已经看到Google Gears是我问题的理想解决方案，建议不要使用它，因为它已被弃用。
在使用技术和应用程序设计方面，使我的应用程序脱机工作的好方法是什么？
答案 0 :(得分：4)
Gears已弃用，因为HTML5标准允许在兼容的浏览器中提供等效功能。
关于您当前处理离线Web应用程序访问的问题，您可以查看HTML5 for offline web applications通过client-side SQL database access支持和client-side application HTTP cache提供的支持。
这些功能必须结合使用，因为客户端数据库访问将允许以结构化格式存储数据（在应用程序脱机时生成），而脱机应用程序缓存将允许缓存HTTP来自服务器的响应;你不应该缓存依赖于任何用户提供的输入的动态响应。
建议的API的详细信息可以在W3C HTML5 specification中找到，目前正处于草案中，尽管某些用户代理似乎已经实现了此功能。
答案 1 :(得分：1)
首先，您需要某种形式的离线存储。正如google gears developer blog所述，HTML5的功能是Google Gears的继承者;从本质上讲，Google Gears的目的只是推动开发和发展。随后采用HTML 5功能。
具体来说，您应该查看HTML5 offline（here's a tutorial）API，Storage API也可以派上用场（relevant tutorial）。
关于设计，您基本上需要维护完整的Web应用程序状态客户端，然后在与服务器的连接再次可用时立即发送差异（即更新服务器端状态）。 / p>
在我的脑海中，有两种简单的设计方法：
明确维护客户端和服务器的单独应用程序状态。本质上，当用户采取行动时，它首先应用于客户端应用程序状态，然后以指定的时间间隔（和/或触发器，例如用户单击保存按钮），客户端发送最后已知状态之间的差异服务器和客户端的当前状态。这可能最适合高度交互的Web应用程序，我怀疑Google Docs可以在这种设计上运行。根据您的应用程序（如果可能发生“冲突的更改”），您还需要考虑合并应用程序状态：您是否覆盖最后收到的客户端状态，还是智能地尝试合并？ （你必须决定哪个对你的特定应用更有意义。）
在离线时记录用户操作，并在连接再次可用后重播它们。您基本上实现了Command design pattern，并且您的客户端代码和服务器端代码都能够处理每个命令。客户端代码始终处理每个命令，并且在与服务器的连接可用时，客户端代码也会将命令发送到服务器。您可能希望实现一些批处理，以避免对服务器的连续请求，以及当对服务器的请求失败（例如，冲突的更改）时的某些回滚功能。这最终看起来或多或少像GMail的主要电子邮件管理用户界面，您可以在其中撤消操作。
答案 2 :(得分：0)
这与J2EE没什么关系，而是您如何编写Web客户端代码。一种可能的解决方案是使用javascript客户端将数据保存在html5引入的本地存储中（参见http://diveintohtml5.ep.io/storage.html）。这也基本上是谷歌齿轮被停止的原因......