Nuova linfa alle applicazioni web

28 marzo 2011

L’acronimo alla base di HTML è chiaro, ‘HyperText Markup Language’; ipertesto: un insieme di documenti messi in relazione tra loro da parole chiave. La tecnologia in questione dovrebbe essere quindi utile per strutturare collezioni di contenuti legati fra di loro in modo più o meno oggettivo; Wikipedia ne è il classico e più calzante esempio. Lascia invece un po’ più perplessi realizzare che l’HTML è sempre più la base di vere e proprie applicazioni web: google docs, Google Maps, Meebo, solo per citarne alcune, dove la forma ipertestuale è decisamente marginale quando non completamente assente. Come già abbiamo avuto modo di anticipare, l’HTML5 nasce anche per meglio indirizzare questo crescente filone di realtà web, mettendo a disposizione dello sviluppatore una nutrita serie di nuovissime API studiate per dare adito alle più ardite applicazioni all’interno di un browser. È un po’ come se il prematuro sogno di Marc Andressen stesse per avverarsi.

La risposta ad un bisogno molto sentito

Lo sforzo profuso prima dal gruppo WHAT e poi dal W3C è stato parzialmente accentuato dalla necessità di porre un freno al dilagare di tecnologie, parallele all’HTML, sorte per rispondere ai nuovi bisogni delle applicazioni web. Il motivo principale di questo comportamento è da ricercarsi nella necessità di mantenere unito il controllo sullo standard e, conseguentemente, di evitare che l’insediamento in pianta stabile di soluzioni non interne al consorzio possa complicare di fatto la gestione dell’intero sistema.

Flash ed il cugino Flex sono due ottimi esempi della tendenza intrapresa dal web in tal senso, seguono Google Gears, Google O3D e un’infinita di altre estensioni, ognuna delle quali cerca di riempire un vuoto più o meno piccolo percepito dagli utenti della rete.

I punti chiave dell’offerta

Ecco un elenco esaustivo delle API trattate nelle prossime lezioni della guida. E` possibile suddividere tale insieme sommariamente in due categorie: nella prima, multimedialità, trovano spazio le API studiate per gestire ed incanalare nuovi strumenti di comunicazione, come video, audio e grafica bi/tridimensionale; nella seconda, che invece potremmo chiamare arricchimento, si posizionano le nuove funzionalità studiate per avvicinare l’esperienza di fruizione di una web application a quella di un normale programma eseguito in una finestra del desktop.

Multimedialità

  • Gestione di flussi video (il tag <video> e le relative API);
  • Gestione di flussi audio (il tag <audio> e le relative API);
  • Gestione di grafica libera bi/tridimensionale (il tag <canvas> e le relative API);
  • Grafica vettoriale e notazioni matematiche (i tag <svg>, <math> e le relative API).

Arricchimento

  • Applicazioni web offline (file .manifest e API di sincronizzazione);
  • Memorizzazione di informazioni sul browser (WebSQL e LocalStorage API);
  • Javascript asincrono e parallelo (Web Workers API);
  • Comunicazioni bidirezionali tra client e server (Web Socket API);
  • Drag and Drop;
  • Utilizzo di informazioni georeferenziate (GeoLocation API).

Oltre a questo elenco, meritano di essere citate e brevemente esplorate alcune funzionalità che, seppur non rivoluzionarie, promettono di semplificare alcuni aspetti dello sviluppo odierno di applicazioni web.

Manipolare la cronologia: le History API

Tutti conosciamo il meccanismo per navigare all’interno della cronologia del browser:

alert("La cronologia contiene " + history.length + " documenti." ); 
// torna al documento precedente 
history.back();

Meno invece sanno che di questo oggetto history, seppur supportato dalla totalità degli user-agent, non esiste traccia nelle attuali specifiche HTML. Con l’avvento della versione 5 il W3C ha deciso di includere le API per la navigazione della cronologia all’interno del futuro standard; l’occasione si è rivelata ghiotta anche per un interessante arricchimento delle funzionalità. In particolare è ora possibile creare nuovi elementi della cronologia associando loro un payoff di dati, come ad esempio un hash chiave-valore, che poi potrà essere recuperato attraverso l’utilizzo del tasti di navigazione del browser. Vediamone un esempio:

<!doctype html> 
<html> 
<head>
  <title>Messaggi dalla storia:</title> 
  <script>
    historyInject = function(){ 
      message = prompt('Che messaggio vuoi salvare in history?'); 
      history.pushState(message, document.title + " '" + message + "'");
    }; 
    onpopstate = function(event){
      document.getElementById("messagelist"). 
      insertAdjacentHTML('beforeend',"<li>"+event.state+"</li>");
    } 
  </script>
</head> 
<body>
    <h1>Lista dei messaggi presenti nella cronologia:</h1> 
    Premi il tasto back del browser o <a href="javascript:historyInject();return false;">
    carica un nuovo messaggio.</a>
    <ul id="messagelist"></ul>
</body> 
</html>

La funzione historyInject crea, attraverso il metodo pushState, un nuovo elemento nella cronologia che contiene il messaggio generato dall’utente. Successivamente, la pressione del tasto back del browser viene intercettata dall’handler onpopstate che recupera il messaggio e lo aggiunge all’elenco a fondo pagina. Con questo meccanismo diviene possibile simulare una normale navigazione con i pulsanti back e forward anche all’interno di applicazioni web che fanno uso intensivo di Javascript, come ad esempio la maggior parte delle realizzazioni sviluppate con il framework Ext.JS.

Associare protocolli e MIME type alla propria web application

Supponiamo di aver sviluppato una web application per inviare e ricevere sms. Le specifiche HTML5 introducono la possibilità di registrare la propria applicazione come gestore preposto ad uno specifico protocollo; nel nostro caso sarebbe quindi auspicabile che qualunque link nel formato:

<a href="sms://+39396819577">Manda un SMS a Sandro Paganotti</a>

convogli l’utente alla nostra applicazione a prescindere dal sito in cui si trova il link, un po’ come succede con il client di posta al click di link col protocollo ‘mailto’. Registrare un protocollo è molto semplice:

<!doctype html> 
<html> 
<head>
  <title>TuttiSMS: Il servizio per inviare e ricevere SMS</title> 
  <script> 
  registraProtocollo = function(){
    navigator.registerProtocolHandler( 
      'sms', 'http://localhost/invia_sms?dest=%s', 'TuttiSMS');
  };
</script> 
</head>
<body onload="registraProtocollo();"> 
</body> 
</html>

Caricando la pagina in un browser che supporta questa funzionalità, noi abbiamo usato Firefox 3.5, verremo notificati della volontà da parte dell’applicazione web di registrare il protocollo sms e potremo decidere se consentire o meno l’operazione:

Figura 41 (click per ingrandire) – Associazione del protocollo su Firefox

screenshot

Una volta accettata questa associazione, ad ogni link nel formato: ‘sms://qualsiasi_cosa’ seguirà un redirect automatico all’indirizzo specificato come parametro nella funzione registerProtocolHandler, nel nostro caso: ‘http://localhost/invia_sms?dest=%s’, con la particella ‘%s’ sostituita con l’intero link in questione. Ecco un esempio di risultato:

http://localhost/invia_sms?dest=sms%3A%2F%2F%2B39396819577

E’ possibile seguire esattamente la stessa procedura anche per registrare uno specifico MIME type utilizzando la funzione gemella: registerContentHandler.

Un progetto ambizioso

Chiudiamo la lezione gettando le basi per lo sviluppo del progetto guida associato al prossimo gruppo di lezioni: FiveBoard, una lavagna interattiva basata su canvas. Chiaramente l’obiettivo del progetto è quello di fornire un pretesto per poter esplorare le novità introdotte dall’HTML5 in un contesto un po’ più ampio rispetto a quello solitamente offerto. Proprio per questo alcune scelte potranno essere opinabili in un ottica di efficenza o di strutturazione dell’architettura.

Bene, cominciamo creando una cartella di progetto, ‘fiveboard’, contenente un file ‘index.html’ e una cartella ‘js’ con un ulteriore file ‘application.js’:

Figura 42 – Vista delle cartelle

screenshot

Ora impostiamo la pagina html perché richiami il file Javascript:

<!doctype html> 
<html lang='it'> 
<head>
  <meta charset="utf-8"> 
  <title>FiveBoard: uno spazio per gli appunti.</title> 
  <script src="js/application.js" defer></script>
</head> 
</html>

L’attributo defer, poco supportato perché definito in modo poco chiaro nelle specifiche HTML4, assume nella versione 5 un significato più delineato:

“(se) [..] l’attributo defer è presente, allora lo script viene eseguito quando la pagina ha finito di essere processata.”

In questo nuovo contesto è interessante l’utilizzo di defer per velocizzare il caricamento della pagina posticipando in seconda battuta il load del file Javascript. Da notare, prima di proseguire, anche l’aggiunta nelle specifiche dell’attributo async che causa il caricamento dello script in parallelo, o asincrono, da qui il nome, rispetto a quello della pagina.

Prima di concludere sinceriamoci del funzionamento del nostro impianto aggiungendo al file Javascript:

alert("pronti per cominciare!");

e caricando il tutto all’interno di un browser:

Figura 43 (click per ingrandire) – Risultato dell’operazione

screenshot

Codice degli esempi

Prima di proseguire, potete scaricare per una migliore consultazione il pacchetto zip che contiene il codice di tutti gli esempi che vedremo nelle lezioni che seguono.

Tutte le lezioni

1 ... 34 35 36 ... 51

Se vuoi aggiornamenti su Nuova linfa alle applicazioni web inserisci la tua e-mail nel box qui sotto:
Tags:
 
X
Se vuoi aggiornamenti su Nuova linfa alle applicazioni web

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy