Se non si implementa alcun gestore di eventi e non si chiama swapCache(), significa che il browser utilizzerà sempre la prima versione (più vecchia) della versione scaricata dell'applicazione?È richiesto swapCache() nelle app offline HTML5?
In caso negativo, perché è necessario il metodo swapCache()?
Il metodo SwapCache fornisce un meccanismo che consente all'applicazione di avere il controllo su come applicare gli aggiornamenti. Nelle normali app HTML, può essere difficile determinare se il JS corretto è presente sul browser dei client. Anche le implementazioni del browser variano quando una cache viene aggiornata, ho trovato l'iPhone particolarmente testardo. swapCache mi ha rimesso in controllo di come viene aggiornata la mia app, potrei scegliere di applicare automaticamente la patch o lasciare che l'utente scelga quando applicare ecc.
Mi stavo chiedendo la stessa cosa. Mi sembra di essere in grado di attivare un aggiornamento di successo semplicemente chiamando "window.applicationCache.update()". Se il file manifest è stato modificato, viene attivato l'evento "download", quindi "pronto per l'aggiornamento".
Quando lo ricarico, sembra che sia stato applicato. Non mi sembra necessario chiamare swapCache(). Ho la possibilità di chiamarlo dall'app, ma finora non ho notato alcun effetto sul processo di aggiornamento.
La chiamata all'aggiornamento() elimina fondamentalmente una ricarica, AFAICS.
Ho un'app con una cache piuttosto grande (> 100mb). Questo richiede un tempo particolarmente lungo per scambiare la cache in (e praticamente blocca il browser mentre questo sta accadendo). Quindi visualizzo un messaggio che indica che l'app è in fase di aggiornamento (attendere ...), quindi chiamare swapCache(), quindi visualizzare un nuovo messaggio quando è terminato.
Non sono sicuro se questo risponde alla tua domanda (sul perché sia necessariamente bisogno ), ma penso che fornisce un caso d'uso valida per swapCache() almeno.
Questo è abbastanza bello. Cosa succederebbe se non lo avessi chiamato, il browser sarebbe rimasto bloccato per un lungo periodo nel caricamento della pagina successiva? E poi, cosa succede dopo averlo chiamato, se includi alcuni nuovi file ... può succedere che metà dei file (quelli già caricati) provengano dalla vecchia versione, altri da una nuova? –
Non penso che ti imbatterai mai in un caso in cui hai un sacco di file cache. 'swapCache()' verrà eseguito solo quando 'status = 'updateready'' (altrimenti genera un errore o semplicemente non fa nulla che io creda). Se avessi aggiunto nuovi file, verrebbero scaricati tramite il normale meccanismo e, una volta completato, attiverai un nuovo evento "updateready". Non riesco a pensare a uno scenario in cui è possibile combinare file da versioni cache differenti. Non sono sicuro di cosa succederebbe se non lo avessi chiamato. Presumo che l'applicazione non venga mai memorizzata nella cache. Forse lo verificherò questo fine settimana e tornerò da te. – ggutenberg
Testato. Se 'swapCache()' non viene chiamato, l'applicazione non viene aggiornata immediatamente, ma viene aggiornata la volta successiva che la pagina viene aggiornata.Quindi in pratica puoi dare all'utente la possibilità di aggiornarlo ora o aggiornarlo in seguito. Se sono nel mezzo di fare qualcosa, questa è una buona opzione da avere. – ggutenberg
swapCache passerà dal set precedente di risorse elencate nel manifest della cache (quando è stata caricata la webapp in esecuzione) al nuovo set. Lo fai in risposta a un updateready, che segnala che è stato caricato un nuovo manifest.
Questo non deve essere confuso con il caricamento di singole risorse, per le quali si applicano ancora le solite politiche di memorizzazione nella cache del browser. In altre parole, scambierete set di risorse, ma le risorse individuali necessitano della propria gestione della cache per garantire che vengano ricaricate quando ne avete bisogno.
Non l'ho ancora provato, ma sembrerebbe suggerire di strutturare il codice come un file javascript di "controller di aggiornamento" che gestisce il processo di aggiornamento e sorgenti javascript con un nome file (o URL) con punti di ingresso noti .
Swapcache si assicura che le chiamate "successive" alle risorse memorizzate nella cache vengano prese dalla nuova cache. Significato successivo dopo lo swapcache. Per vedere questo in azione provare a impostare la proprietà src di un'img in modo dinamico dopo la chiamata a swapcache nell'evento updateready (in modo che il browser la carichi in quel particolare tempo ). Assicurati che questa immagine non sia già stata caricata da un'altra parte nella pagina, dal momento che sarà distorcere questo test. Adesso cambia l'immagine e cambia i file manifest (per forzare il ricaricamento dei file memorizzati nella cache). Ricarica la pagina nel tuo browser. Ora dovresti vedere la nuova versione dell'immagine nella pagina di rendering. Adesso commenta la chiamata a swapcache. Apporta una modifica al file manifest e ricarica la pagina e quindi tutte le risorse. Aggiorna di nuovo la pagina (per assicurarsi di avere una versione dalla nuova cache). Adesso cambia di nuovo l'immagine e cambia il manifest. Ricarica nuovamente la pagina: ora vedi la vecchia versione dell'immagine. Nell'ultimo caso, il browser ha terminato di caricare le nuove versioni nella cache, ma dal momento che lo swapcache non è stato chiamato , l'immagine è stata ancora prelevata dalla vecchia cache.
Se non si esegue alcun caricamento dinamico delle risorse nella pagina, lo swapcache non ha alcun effetto.
In particolare, se si ricarica la pagina nel gestore di eventi updateready chiamando swapcache primo ha alcun effetto in quanto a ricaricare la pagina otterrà dalla nuova cache comunque.
Immaginiamo 2 diversi scenari.
Si chiama location.reload() quando il nuovo contenuto è disponibile. La pagina verrà ricaricata utilizzando il suo nuovo contenuto. applicationCache.swapCache() non è necessario in questo caso.
L'utente continua a interagire con la tua pagina, senza alcuna ricarica. Questa interazione fa caricare una risorsa in modo dinamico. Per ragioni, immaginiamo che si tratti di un'immagine di rollover e immaginiamo di aver appena aggiornato questa immagine di rollover. Senza applicationCache.swapCache(), l'utente continuerà a vedere la vecchia immagine di rollover. Dopo applicationCache.swapCache(), vedrà la nuova immagine di rollover.
Così applicationCache.swapCache()senza un ricaricamento dice: "tenere la pagina di guardare il modo in cui era quando è stato caricato, ma utilizzare tutti i nuovi asset ora, non appena la pagina chiede per loro".
In "updateready", viene visualizzato un avviso "Aggiornamento disponibile, fare clic per riavviare ora" ed eseguire 'location.reload();' al clic. Se non fanno clic, l'app viene aggiornata automaticamente al successivo caricamento. Non capisco come posso aggiornare l'app senza ricaricare, con 'swapCache()'. E * con * ricarico, non ho comunque bisogno di 'swapCache()'. Ancora non capisco quando è necessario. –
Ottiene anche più strano di quello: in Chrome Im ottenendo l'evento 'updateready' e quando chiamo' swapCache() 'all'interno del gestore, Chrome si lamenta' Uncaught InvalidStateError: Impossibile eseguire 'swapCache' su 'ApplicationCache': non c'è una nuova cache dell'applicazione scambiare a. – Mati