2011-08-24 13 views
5

Quiero hacer que mi aplicación web pueda funcionar sin conexión y, tan pronto como esté en línea o se vuelva a conectar, podrá transferir las modificaciones realizadas por el usuario en modo fuera de línea.¿Cómo puedo hacer que mi aplicación web J2EE trabaje fuera de línea?

He visto Google Gears como una solución ideal para mi problema, que no se recomienda para su uso ya que ahora está en desuso.

¿Cuál es una buena manera de hacer que mi aplicación funcione sin conexión, tanto en términos de tecnología para usar como para diseñar aplicaciones?

+0

Puede probar una alternativa. Por ejemplo, una aplicación flash utilizada para el modo fuera de línea. Mientras que una aplicación web se utiliza para el modo en línea. –

+0

El almacenamiento sin conexión está sobrevalorado. – bhagyas

Respuesta

4

Gears está en desuso porque el estándar HTML5 permite que funciones equivalentes estén presentes en los navegadores compatibles.

Con respecto a su problema actual de manejar aplicaciones de acceso web sin conexión, puede buscar en el soporte ofrecido por HTML5 for offline web applications a través de soporte para client-side SQL database access, y client-side application HTTP cache.

Las funciones se deben usar conjuntamente, ya que el acceso a la base de datos del cliente permitirá el almacenamiento de datos (generados cuando la aplicación está fuera de línea) en un formato estructurado, mientras que la caché de aplicaciones sin conexión permitirá el almacenamiento en caché de Respuestas HTTP del servidor; no debe almacenar en caché respuestas de naturaleza dinámica que dependan de las entradas proporcionadas por el usuario.

Los detalles de las API propuestas se pueden encontrar en el W3C HTML5 specification, que está en borrador en este momento, aunque parece que ciertos user-agents ya implementaron esta característica.

0

Esto no tiene mucho que ver con J2EE, sino más bien cómo codifica su cliente web. Una posible solución sería utilizar un cliente de JavaScript que guarde los datos en el almacenamiento local introducido con html5 (consulte http://diveintohtml5.ep.io/storage.html). Esa también es básicamente la razón por la que se detuvo Google Gears ...

+0

He visto a esos amigos, pero si se borra la memoria caché del navegador, entonces no funcionaría. este es uno de los bucles en esto. – deepmoteria

1

En primer lugar, necesitará algún tipo de almacenamiento sin conexión. Las capacidades de HTML5 son el sucesor de Google Gears, como se indica en el google gears developer blog; En esencia, el propósito de Google Gears era simplemente impulsar el desarrollo & posterior adopción de las características de HTML 5.

Específicamente se debe buscar en los HTML5 offline (API) here's a tutorial, y los Storage API también puede ser útil (relevant tutorial).

En lo que respecta al diseño, básicamente necesitará mantener su estado de aplicación web completo del lado del cliente y luego enviar las diferencias (es decir, actualizar el estado del servidor) tan pronto como la conexión al servidor vuelva a estar disponible.

De la parte superior de mi cabeza, hay 2 formas sencillas para diseñar este:

  1. a mantener explícitamente a los Estados de aplicaciones independientes para el cliente y el servidor. Básicamente, cuando el usuario realiza una acción, primero se aplica al estado de la aplicación cliente y luego a intervalos específicos (y/o activadores, por ejemplo, el usuario hace clic en el botón Guardar), el cliente envía las diferencias entre el último estado conocido de el servidor y el estado actual del cliente. Esto probablemente sea más adecuado para aplicaciones web altamente interactivas, y sospecho que Google Docs funciona en este tipo de diseño. Dependiendo de su aplicación (si pueden ocurrir "cambios conflictivos"), también deberá contabilizar la fusión del estado de la aplicación: ¿anula con el último estado de cliente recibido o intenta fusionarse de forma inteligente? (Tendrás que decidir cuál tiene más sentido para tu aplicación en particular).)

  2. Registre las acciones de los usuarios mientras está fuera de línea, y repítalas una vez que la conexión vuelva a estar disponible. Implementa esencialmente el Command design pattern, y tiene tanto el código del lado del cliente como el código del lado del servidor para manejar cada comando. El código del lado del cliente siempre maneja cada comando, y mientras la conexión al servidor está disponible, el código del lado del cliente también envía los comandos al servidor. Es probable que desee implementar algunos lotes, para evitar solicitudes continuas al servidor, y también alguna funcionalidad de retrotracción cuando las solicitudes al servidor fallan (por ejemplo, cambios en conflicto). Esto termina pareciéndose más o menos a la interfaz de usuario de gestión de correo electrónico principal de GMail, donde puede deshacer operaciones.

Cuestiones relacionadas