2015-05-28 15 views
7

Qual è il modo accettato di sincronizzare i dati di una webapp con un server quando un utente chiude la finestra del browser senza prima salvare il proprio lavoro? Sto parlando colpendo la "X" o anche premendo F5 o qualcosa del genere.Come salvare lo stato della pagina durante la chiusura

Un po 'di storia:

La webapp in questione ha una finestra principale, e poi finestre figlio, che depongono le uova dalla finestra principale, consentendo "lavoro" sandboxed da fare nelle finestre figlio. Non ho il controllo su questo aspetto dell'attuazione.

Il caso d'uso:

Ogni finestra bambino può avere una quantità abbastanza considerevole delle informazioni inserite prima che l'utente decide di fare clic su "OK" a persistere i dati sul server.

cose Ho considerato/provato:

  • semplice stretta di conferma restituendo una stringa da un gestore di onbeforeunload evento se non c'è lavoro non salvato. (problema: il mio team guidato non è disposta a muoversi su permettendo una specifica del browser "alert finestra di dialogo" per essere in webapp Secondo lui:. L'esperienza utente va fuori dalla finestra basandosi su quella finestra guardando brutto.)
  • AJAX richiesta emessa durante l'evento onpageunload che invia nuovamente i dati al server. (problema: dal momento che il callback XHR non viene mai chiamato, ho trovato alcuni browser lasciando il collegamento aperto, e quindi in modo casuale che tentano di sparare il richiamo di un futuro finestra che viene aperta.)
  • sincrono AJAX richiesta sparato durante il onpageunload evento. (problema: ignorare il fatto che le persone tra cui me stesso tendono a odiare fare questo e il fatto che sia deprecato e verrà rimosso in futuro ... L'interfaccia utente potrebbe potenzialmente bloccarsi per un lungo periodo di tempo in attesa della richiesta AJAX per completa, forse a tempo indeterminato se perdono internet.)
  • Salvare il contenuto della pagina a intervalli regolari, oppure allegando onchange/onblur/onwhateverelse gestori di eventi. :
  • Utilizzando localStorage per mantenere i campi modificati sulla macchina del cliente fino a quando non realtà impegnano il loro lavoro al server (problema di enormi quantità di codifica in testa rispetto alle altre implementazioni "pigri" sopra e sotto.). (problema: supporto browser ... questo ha bisogno di supportare tante postazioni di supporto XHR. Lo storage lato client ha quel vasto supporto? Penso che ci sia un po 'di vuoto se non mi sbaglio.)

Grazie in anticipo per il vostro contributo.

+1

"L'esperienza utente esce dalla finestra basandosi su quella brutta finestra di dialogo." Lo vedo usato su Facebook, Gmail e altrove. Sospetto che abbiano fatto test sull'esperienza utente più estesi di quelli del tuo team. – ceejayoz

+0

concordato. Purtroppo questo individuo ha un sacco di tiro e, ahimè, non posso usare l'opzione 1 :( – Harvtronix

+1

Poiché le opzioni 2, 3 e 5 hanno il potenziale per irritare almeno alcuni browser, fai in modo che la tua squadra scelga tra le opzioni 1 e 4. Essi può spendere tempo e denaro per fare qualcosa che richiederà più sforzo per mantenere, oppure può scegliere la soluzione facile, 'brutta' che sarà familiare agli utenti finali – BSMP

risposta

2

La soluzione che ho trovato è essenzialmente una versione modificata della scelta 4 dall'alto.

Ho sviluppato una logica che registra i gestori di eventi onchange/onkeypress con nodi identificati da un determinato attributo (in questo caso data-save-state="true") al caricamento della pagina.

Per fare uso di questo, l'unico requisito per gli sviluppatori di ciascuna delle "finestre figlio" che vengono lanciati dalla finestra principale è quello di registrare l'URI a cui vogliono i loro dati salvati con il mio nuovo modulo javascript Saver.

I valori dell'elemento identificato sono serializzati e inviati come oggetto JSON allo Saver. Lo Saver è responsabile dell'accodamento di gruppi di richieste e dell'invio al server come gruppo una volta che non sono state rilevate ulteriori modifiche per 1000 ms.

Questo è stato per me un ulteriore vantaggio per chi ha dovuto sviluppare la capacità di farlo, ma ora che è lì, è piuttosto semplice per gli altri membri del team integrarsi nel proprio codice.

Per quanto riguarda il potenziale di perdita di dati, l'unico rischio è ora durante quel secondo di tempo prima che la richiesta di salvataggio venga inviata al server. Questa soluzione sembra molto "Google Docs", per me in natura.

+0

Ah, questo è un modo interessante per risolvere il tuo problema! :) – towerofnix

1

Mi sembra che tu voglia utilizzare i cookie. Per quanto ne so è supportato praticamente da qualsiasi browser web.

L'unica cosa che non è supportata su localStorage è Opera Mini .. Immagino che sia un po 'troppo il non-supporto per te, o la persona per cui stai facendo il programma.

Here's a plugin for handling cookies, perché in realtà non sono qualcosa che si desidera gestire senza plug-in. ;) Sembra che sia supportato da qualsiasi browser!

Nel caso in cui non si desideri utilizzare una libreria, consultare la pagina della rete per sviluppatori Mozilla allo Document.cookie.

Se si desidera leggere la cronologia dei cookie, è possibile controllare this.

+0

Tuttavia è importare ricordare le dimensioni dei cookie/limitazioni di lunghezza che possono variare anche tra i browser. È importante tenerlo presente poiché l'autore dice che potrebbe essere co quantità considerevole di dati. – jjczopek

+0

@jjczopek Sì, esattamente. Stiamo parlando di grandi quantità di informazioni (centinaia di campi modulo alla volta). Sfortunatamente l'utilizzo di un cookie per contenere questi dati non sarebbe fattibile. – Harvtronix

Problemi correlati