Skip to content

5. Conclusione

Abbiamo realizzato la seguente applicazione client/server:

Image

Per arrivare alla versione finale del codice, abbiamo dovuto spiegare numerosi aspetti dei framework AngularJS e Spring 4. Questo documento può quindi essere utilizzato per imparare a utilizzare questi due framework. Il paragrafo 1.3 spiega dove trovare i codici e come utilizzarli.

Abbiamo dimostrato che l’applicazione client/server è utilizzabile in diversi ambienti:

  • come una classica applicazione web;
  • come binario eseguibile su emulatori Android;

Ancora una volta, questo tutorial non è esaustivo per quanto riguarda lo studio dei due framework. Per Angular, sarebbe certamente necessario presentare gli strumenti di test che lo accompagnano. I test sono fasi indispensabili durante la scrittura di un’applicazione. Gli strumenti che ruotano attorno ad Angular consentono di automatizzarli e di includerli in un processo di integrazione continua.

Da questo lavoro ricavo due considerazioni:

  • la scrittura del servizio web Spring è stata moderatamente complicata. Fin dall’inizio conoscevo bene i concetti di Spring. Ho incontrato difficoltà solo con la messa in sicurezza del servizio web e, successivamente, con la gestione delle intestazioni HTTP CORS, due ambiti che non conoscevo;
  • la realizzazione del client Angular è stata molto più complessa per diversi motivi:
    • Non conoscevo abbastanza il linguaggio JavaScript e le sue potenzialità;
    • ho avuto difficoltà a comprendere come funzionasse la programmazione asincrona all'interno del browser. Ragionavo come se fossi su un server, dove tale asincronia si ottiene con l'uso simultaneo di più thread. Nel browser, invece, c'è un solo thread e le operazioni asincrone vengono elaborate in successione e non in parallelo. Più precisamente, le attività asincrone possono essere eseguite in parallelo (ad esempio, richieste multiple HTTP), ma gli eventi che generano una volta completate vengono elaborati in modo sequenziale. Non c’è quindi un’esecuzione concorrente da gestire, con i numerosi problemi che ne derivano;
    • Angular è un framework ricco di concetti (MVC, direttive, servizi, ambito dei modelli, ...). Impararlo richiede tempo;
    • Angular non impone un metodo di sviluppo specifico. Pertanto, per ottenere lo stesso risultato, è possibile utilizzare architetture diverse. Questo crea confusione. Mi trovo più a mio agio con framework chiusi in cui tutti utilizzano gli stessi modelli di progettazione (design pattern). Ho quindi cercato costantemente di riprodurre i modelli di progettazione che utilizzo sul lato server. Sono soddisfatto del risultato perché ritengo che sia riproducibile. È proprio quello che cercavo. Tuttavia, non so affatto se mi sia discostato o meno dalle «buone pratiche» di Angular;

Serge Tahé, luglio 2014.