Procedure ottimali - Linee guida per la creazione di applicazioni SWF

Il metodo migliore per creare applicazioni Animate dipende dall'applicazione specifica e dalla tecnologia adottata per realizzarla.

Un'applicazione in linea consente all'utente di interagire con un sito Web e di apportare modifiche. L'applicazione potrebbe, ad esempio, raccogliere informazioni dall'utente, quali il nome utente e la password per una registrazione, aggiungere informazioni al sito, ad esempio in un forum, oppure l'utente potrebbe interagire in tempo reale con altri visitatori, ad esempio in una chat room o in una white board interattiva. I risultati provenienti dal server vengono spesso visualizzati nel file SWF, in base al tipo di interazione. Gli esempi forniti riguardano applicazioni che coinvolgono l'utente e diversi tipi di interazione con il server. Un sito Web che non utilizza le informazioni o i dati forniti dai visitatori non è un'applicazione (ad esempio, un sito informativo statico o un disegno animato). Le applicazioni Animate prevedono un processo interattivo tra l'utente, un'applicazione Web e un server. Il processo di base è il seguente:

Quando create un'applicazione dovete selezionare un protocollo per il trasferimento dei dati. Attraverso tale protocollo l'applicazione viene avvisata dell'invio o della ricezione di dati, del relativo formato e di come deve essere gestita una risposta del server. Dopo la ricezione dei dati nel file SWF, i dati devono essere gestiti e formattati. Se utilizzate un protocollo, non sarà necessario verificare il formato dei dati. Se trasferite dati utilizzando coppie nome-valore, potete verificarne la formattazione, ovvero controllare che i dati siano formattati in modo corretto per evitare di ricevere dati in formato XML e assicurare che il file SWF riceva e possa elaborare i dati nel formato previsto.

Raccolta e formattazione di dati

Le applicazioni dipendono dall'interazione dell'utente con il file SWF e spesso dall'immissione di dati da parte dell'utente nei form. Con Animate potete immettere e formattare i dati nelle applicazioni Animate in diversi modi. Questa flessibilità è disponibile grazie alla possibilità di aggiungere animazione e controllo creativo dell'interfaccia e alla verifica e convalida degli errori eseguibili con ActionScript.

L'uso di Animate per la creazione dei form di raccolta dati assicura diversi vantaggi:

• Maggiore controllo sulla progettazione.

• Poca o nessuna necessità di eseguire l'aggiornamento della pagina.

• Possibilità di riutilizzare le risorse comuni.

   Per archiviare le informazioni raccolte dall'utente, salvatele in un oggetto condiviso sul suo computer. Gli oggetti condivisi consentono di memorizzare dati sul computer di un utente, analogamente a quanto avviene con i cookie. Per ulteriori informazioni sugli oggetti condivisi, vedete la classe sharedObject nella Guida di riferimento di ActionScript 2.0 o nella Guida di riferimento del linguaggio e dei componenti ActionScript 3.0.

Invio ed elaborazione di dati

L'elaborazione delle informazioni deve in genere avvenire prima dell'invio al server, per consentire una formattazione comprensibile per il server. Quando il server riceve i dati, la gestione può avvenire in diversi modi e i dati possono essere inviati nuovamente al file SWF in un formato accettabile, ad esempio coppie nome-valore o oggetti complessi.

 Sul server di applicazioni il tipo MIME dell'output deve essere impostato su application/x-www-urlform-encoded. Se tale tipo MIME non è presente, il risultato sarà in genere inutilizzabile da Animate.

La tabella seguente mostra diverse opzioni per l'invio di dati a un server e la ricezione di dati mediante Animate:

Aggiunta del caricamento dati e della convalida

Convalidate le informazioni recuperate prima di inviare dati a un server al fine di ridurre il carico sul server remoto, in quanto il server non è in grado di gestire troppe richieste se gli utenti non compilano i campi obbligatori. Non basatevi mai esclusivamente sulla convalida sul lato client in nessuna applicazione. Anche la convalida sul lato server deve sempre avvenire.

Anche se create una registrazione semplice o un form semplice per il login, verificate che l'utente abbia immesso il nome e la password ed eseguite la convalida prima di inviare la richiesta allo script remoto sul lato server e attendete il risultato. Non basatevi esclusivamente nemmeno sulla convalida sul lato server. Se un utente immette solo il nome utente, lo script sul lato server deve ricevere la richiesta, convalidare i dati inviati e restituire un messaggio di errore all'applicazione Animate indicando che è necessario immettere sia nome utente che password. Analogamente, se la convalida viene eseguita solo sul lato client (all'interno del file SWF), un utente potrebbe accedere al file SWF in modo fraudolento, evitare la convalida e inviare dati errati al server.

La convalida sul lato client può essere molto semplice, ad esempio potete verificare che il campo di un form sia lungo almeno un carattere o che l'utente abbia immesso un valore numerico e non una stringa. Per convalidare un indirizzo e-mail, verificate che il campo di testo in Animate non sia vuoto e contenga almeno il simbolo della chiocciola (@) e il punto (.). Per la convalida sul lato server, aggiungete operazioni più complesse e verificate che l'indirizzo e-mail appartenga a un dominio valido.

Scrivete codice ActionScript per gestire i dati che vengono caricati nel file SWF dal server. Al termine del caricamento dei dati in un file SWF, sarà possibile accedere ai dati da quella posizione. Utilizzate codice ActionScript per verificare che i dati vengano caricati completamente. Potete utilizzare funzioni di callback o listener per segnalare che i dati sono stati caricati nel documento.

I dati caricati possono essere formattati in modi diversi:

• Se vengono caricati dati XML, utilizzate i metodi e le proprietà della classe XML per analizzare i dati e utilizzarli. Se utilizzate coppie nome-valore, queste vengono trasformate in variabili e sono gestibili in tale formato.

• I dati potrebbero provenire da un servizio Web o da Animate Remoting.

In entrambi i casi, le strutture potrebbero essere complesse e contenere, ad esempio, array, oggetti o recordset da analizzare e associare in modo appropriato.

Gestione degli errori e debug

L'applicazione deve essere sufficientemente affidabile per prevedere determinati errori e gestirli in modo appropriato.

Uno dei metodi migliori per eseguire la gestione degli errori in ActionScript 2.0 è rappresentato dall'uso dei blocchi try-catch-finally che consentono di generare e rilevare errori personalizzati. Creando classi di errori personalizzate, potete riutilizzare il codice per la gestione degli errori in tutta l'applicazione senza doverlo riscrivere. Per ulteriori informazioni sulla generazione di errori personalizzati, vedete la classe Error nella Guida di riferimento di ActionScript 2.0. Per ulteriori informazioni sui blocchi try-catch-finally, vedete try.catch..finally nella Guida di riferimento di ActionScript 2.0.

In ActionScript 3.0, utilizzate la classe flash.errors per individuare gli errori.

Per ulteriori informazioni sulla gestione degli eventi, vedete “Gestione degli errori sincroni delle applicazioni” in Programmazione in ActionScript 3.0.

Organizzazione dei file e inserimento del codice

Considerate le seguenti linee guida prima di iniziare a organizzare i file e a inserire il codice:

• Il file SWF viene suddiviso in più file SWF e, in tal caso, come avviene l'interazione tra i file?

• Quali risorse potete condividere tra i file SWF?

• Quali file caricate in modo dinamico?

• In che modo e dove inserite il codice ActionScript?

  Durante lo sviluppo di un'applicazione, inserite il codice lato server e i file in una struttura di directory logica, analoga a quella di un pacchetto ActionScript, per garantire un'organizzazione corretta e ridurre il rischio di sovrascrittura del codice.

  Nel caso di applicazioni di grandi dimensioni, incorporate la comunicazione e i servizi client-server in classi per ottenere i vantaggi seguenti:

• Riutilizzabilità del codice in più file SWF.

• Possibilità di modificare il codice in una posizione centrale e di aggiornare tutti i file SWF semplicemente ripubblicandoli.

• Possibilità di creare una sola API che gestisca diversi elementi dell'interfaccia utente o altre risorse che eseguono funzioni simili.

Uso del modello di progettazione MVC

Il modello di progettazione MVC viene utilizzato per separare l'elaborazione dei dati, dell'output e delle informazioni nell'applicazione. L'applicazione viene suddivisa in tre elementi: modello, vista e controller e ogni elemento gestisce una parte diversa del processo.

Incorpora i dati e le regole dell'applicazione. L'elaborazione dell'applicazione avviene per lo più in questa parte. Il modello contiene anche eventuali componenti (ad esempio CFC, EJB e servizi Web) e il database. I dati restituiti non vengono formattati per l'interfaccia, o front-end, dell'applicazione in questa parte del processo, quindi possono essere utilizzati per interfacce (o viste) diverse.

Gestisce il front-end dell'applicazione, ovvero l'interfaccia con cui l'utente interagisce, ed esegue il rendering dei contenuti del modello. L'interfaccia specifica in che modo vengono rappresentati i dati del modello e restituisce la vista che verrà utilizzata dall'utente per accedere ai dati dell'applicazione o gestirli. Se il modello cambia, la vista viene aggiornata per riflettere le modifiche tramite push o pull, ovvero invio o richiesta, dei dati. Se create un'applicazione Web ibrida (ad esempio un'applicazione che include l'interazione tra Animate e altre applicazioni presenti nella pagina), considerate le diverse interfacce come parte della vista nel modello di progettazione. Il modello di progettazione MVC supporta la gestione di un'ampia varietà di viste.

Gestisce i requisiti del modello e della vista per l'elaborazione e la visualizzazione dei dati e in genere contiene molto codice. Chiama qualsiasi parte del modello, in base alle richieste effettuate dall'utente dall'interfaccia (o vista), e contiene codice specifico per l'applicazione e pertanto non riutilizzabile. Gli altri componenti del modello di progettazione sono invece riutilizzabili. Il controller non elabora né restituisce dati, ma accetta la richiesta dell'utente e definisce la parte del modello o della vista che deve essere chiamata dai componenti, determinando dove inviare i dati e quale formato applicare ai dati restituiti. Assicura inoltre che le viste possano accedere alle parti dei dati del modello che devono visualizzare. In genere trasmette le modifiche che riguardano il modello e la vista e risponde ad esse.

Ogni parte del modello è creata come componente autonomo nel processo globale. Se una parte del modello viene modificata, ad esempio se si rielabora l'interfaccia, le altre parti del processo in genere non necessitano di modifiche e quindi il processo globale risulta semplificato. Se il modello di progettazione è stato creato correttamente, sarà possibile modificare la vista senza dover rielaborare il modello o il controller. Se l'applicazione non è basata su MVC, apportare modifiche in più punti può risultare controproducente perché il numero di modifiche potrebbe risultare molto più elevato rispetto a quello necessario con un modello di progettazione specifico.

Il modello MVC è importante perché permette di separare i dati e la logica dall'interfaccia utente. Separando queste parti del processo, si hanno a disposizione più interfacce grafiche diverse che utilizzano lo stesso modello e dati non formattati. Ciò significa che potete utilizzare l'applicazione con diverse interfacce Animate, ad esempio con un'interfaccia per il Web, una per Pocket PC, una versione per i telefoni cellulari e persino una versione HTML che non utilizza affatto Animate. Separare i dati dal resto dell'applicazione può essere sinonimo di significativa riduzione del tempo necessario per lo sviluppo, la prova e l'aggiornamento di più interfacce client. Analogamente, l'aggiunta di nuovi front-end per la stessa applicazione risulterà più semplice se utilizzate un modello esistente.

L'uso di MVC è consigliato solo se create un'applicazione complessa o di grandi dimensioni, ad esempio un sito Web per l'e-commerce o un'applicazione di e-learning. L'uso di questa architettura richiede infatti una buona pianificazione e un'ottima comprensione del funzionamento di Animate e del modello di progettazione. È bene considerare attentamente l'interazione tra i diversi elementi, effettuando le necessarie procedure di prova e debug. Con MVC le attività di prova e debug sono più frequenti e complesse rispetto a quelle necessarie per le normali applicazioni Animate. Tuttavia, se create applicazioni più sofisticate, l'uso di MVC per organizzare il lavoro potrebbe risultare vantaggioso.

Creazione di applicazioni sicure

Indipendentemente dal tipo di sito che dovete creare, ad esempio un portale di piccole dimensioni a cui gli utenti possono accedere per leggere articoli oppure un sito di e-commerce di grandi dimensioni, esiste il rischio che utenti disonesti tentino di accedere all'applicazione in modo fraudolento. Per questo motivo, valutate la possibilità di proteggere l'applicazione adottando le seguenti misure.

• Inviate tramite il protocollo HTTPS i dati che necessitano di protezione. Crittografate i valori in Animate prima di inviarli a un server remoto per l'elaborazione.

   non inserite mai in un file SWF informazioni o codice che non desiderate mostrare agli utenti. È estremamente semplice decompilare i file SWF e visualizzarne i dati con software di terze parti.

• Aggiungete criteri inter-dominio (“cross-domain”), che impediscono l'accesso alle risorse da domini non autorizzati.