Recentemente lavoro ad un grosso progetto, di cui non posso far trapelare nulla, basato sull'architettura Model Driven (BPMN e WebML) per la progettazione e realizzato secondo le specifiche SOA.
E' stato richiesto, inerente la realizzazione di un web client, di offrire all'utente la possibilità di poter lavorare anche offline.
Bene: all'interno del team di lavoro si è subito puntato sulla tecnologia, o le tecnologie, che HTML5 offre.
Di cosa bisogna tener conto?
Il seguente diagramma UML riassume molto sinteticamente tutto ciò che è strettamente necessario, indipendentemente da come poi sarà implementato.
Ovviamente, diagramma use case a parte, sono diverse le considerazioni fatte o da fare.
1. HTML5 non è ancora uno standard!
Ad oggi è però considerato uno standard de facto per via del crescente supporto che i produttori di browsers offrono, adottando ed implementando le specifiche W3C, e per via di dell'importanza che ha già assunto nell'ambito mobile.
E' il W3C, per primo, a sostenere che HTML5 è ancora un work in progress sebbene ormai moltissimi tra i più grandi players che offrono servizi web (Google, MS) già lo adottano.
Ogni produttore è libero di implementare le specifiche in progress rilasciate da W3C rendendo almeno per il momento più difficile capirne il limite di utilizzo.
2. Cache delle risorse statiche
E' necessario conservare le caratteristiche e le funzionalità dell'interfaccia grafica: files javascript, files CSS, immagini e codice HTML di tutte le pagine visitate e di quelle che potranno servire.
Per ottenere questo è possibile seguire una sola strada (inizialmente si potevano sfruttare anche le Web SQL Database API ma recentemente sono state deprecate per motivi di sicurezza): l'utilizzo di .manifest files. Praticamente si dichiarano in un file esterno alle pagine HTML, e da queste referenziato, la lista delle risorse che il browser utente deve conservare. Principali caratteristiche:
- Tutte le risorse da cachare devono essere indicate una per una con path relativi o assoluti. Non è previsto l'uso di caratteri wildcards (ES: /img/*);
- Consente di cachare risorse utilizzando protocollo https://;
- Automaticamente qualunque pagina HTML che referenzia un manifest viene anch'essa cachata;
- Consente di gestire offline richieste fatte a risorse non cachate (Fallback);
- Consente di elencare tutte le risorse online che non devono essere mai cachate (Network);
Ma questo non è tutto, bisogna infatti conservare anche tutti i dati applicativi e della sessione utente.
3. Cache dei dati applicativi
Conservare i dati applicativi significa riuscire a stoccare lo stato degli oggetti caricati, e modificati, durante l'utilizzo dell'applicazione da parte dell'utente.
Per esempio, l'utente modifica un ordinativo tramite un FORM HTML: essendo in modalità offline non è possibile contattare il server per l'invio dei dati e quindi?
Una possibile soluzione consiste nel serializzare l'intero FORM in un formato stringa JSON e salvare quest'ultima temporaneamente per poi sincronizzare il client con il server quando si riotterrà la connessione alla rete.
Per poter far questo le specifiche HTML5 forniscono le Indexed Database API, cioè il supporto di un vero DB persistente. Le caratteristiche principali di queste API sono:
- Offrono l'accesso ad un database ufficialmente senza limiti e persistente anche dopo aver svuotato la cache del browser;
- E' consentito lo storage di informazioni testuali come stringhe e oggetti javascript serializzati;
- La gestione del I/O su DB va trattata manualmente: non esistono strumenti per il mapping automatico degli oggetti con record di tabelle SQL;
- L'implementazione della sincronizzazione dei dati con il server quando on-line va gestita manualmente;
4. Salvataggio della sessione utente
Infine, è necessario conservare anche i dati relativi all'utente: username e password, sessionId ed altre informazioni utili all'occorrenza.
Ovviamente anche per questa problematica HTML5 offre una soluzione: le Web Storage API.
Esse in realtà si compongono di due classi:
- la classe sessionStorage: consente la persistenza dei dati per ogni sessione utente distinta, anche all'interno dello stesso browser;
- la classe localStorage: conserva e maneggia le informazioni riposte nel cookie, che comunque rimane comune a tutte le finestre del browser che puntano lo stesso dominio;
Le caratteristiche principali di queste API sono:
- Possono trasportare (pare) fino a 5MB;
- Sono persistenti anche dopo la chiusura e riapertura del browser;
- Conservano informazioni in forma di mappa chiave/valore;
- Le chiavi ed i valori devono essere testuali (stringhe e serializzazioni JSON di oggetti javascript);
Al momento, nè a me nè agli altri del team in cui lavoro è venuta in mente qualche possibile issue da aggiungere all'elenco di cui sopra: ci sembra di aver tenuto conto di tutto ............. se hai avuto modo di affrontare già il tema e ti pare che manchi qualcosa allora ti sarei grato se mi accennassi qualcosa a riguardo della possibile lacuna.
Alla prossima,
MA.
