Undolog.com

Nell’ottica della programmazione ad oggetti viene spontaneo realizzare componenti per riutilizzarli in altri progetti, soprattutto se questi componenti sono general-purpose. L’uso delle classi è sicuramente un primo passo nel riutilizzo del codice, tuttavia, spesso, queste classi sono legate a MovieClip anche estremamente complessi. Così nasce la necessità di “importare” sia il codice ActionScript della classe (cosa assai facile) ma anche tutti i simboli ad esso associato.

Creare Componenti in Flash

Questa strada è sicuramente la più corretta da un punto di vista strettamente logico. Tuttavia, almeno nella versione Flash MX, creare un componente che quantomeno si avvicini a quelli forniti con l’ambiente di sviluppo non è impresa da poco. I componenti, infatti, soprattutto quelli visuali, richiedono tutta una serie di procedure (come l’inclusione delle interfacce UIObject o UIComponent) e la scrittura estremamente accurata della classe legata al nostro componente. Rimane comunque il fatto che creare un componente è un’esperienza interessante da fare, ma il tempo di sviluppo è davvero notevole. Inoltre un componente come si deve supporta la modalità in designtime o authortime che altro non fa che proporre un’anteprima di quello che accadrà a runtime. È possibile associare un’icona e una documentazione perfettamente integrabile nell’IDE di Flash, con tanto di intellisense durante la scrittura del codice. Ecco quindi che scegliere questa strada comporta un dispendio temporale notevole, probabilmente riservato a particolari progetti dove, ad esempio, sia proprio il componente l’obiettivo del progetto.
Ci sono software house specializzate nella produzione di componenti per Flash, sia come prodotti gratuiti che a pagamento. Esclusi quindi i componenti estremamente semplici, dove ad esempio non c’è interfaccia utente, questo metodo è ottimo ma temporalemte dispendioso e quindi poco usato nella maggioranza dei casi.

Condividere simboli in Runtime

Questa soluzione può essere un’ottima alternativa alla creazione di complessi componenti. In questo caso si crea un libreria (un filmato swf) che contiene uno o più simboli (MovieClip) da esportare. Nonostante bisogna impostare alcuni parametri con attenzione, esportare (e quindi condividere) un simbolo in questo modo è assai più semplice ed immediato che creare un complesso componente. Come vedremo più avanti a differenza della condivisione authortime, la condivisione runtime impone di selezionare ed impostare il simbolo da esportare nella libreria sorgente. Questo significa che un filmato non può importare un simbolo che non sia stato impostato per tale funzione.
Inoltre la libreria che contiene i simboli che vogliamo usare dev’essere posizionata su un URL ben determinato e quindi accessibile.
Partiamo dalla nostra libreria, creiamo un simbolo (complesso quanto vogliamo) e selezioniamo proprietà:

I tre punti importanti sono: l’identificatore del simbolo, che dovrà essere lo stesso quando andremo ad usare il simbolo esportato. Selezione della casella “Esporta per condivisione runtime”. E per finire l’URL del filmato (SWF) che contiene il nostro simbolo.
Il filmato che vuole usare questo simbolo deve eseguire delle operazione simili. Aprite un nuovo filmato e create un simbolo vuoto. Selezionate il simbolo vuoto e cliccate su proprietà:

Anche qui i punti sono tre: usare lo stesso identificatore usato nella libreria sorgente, spuntare la casella “Importa per condivisione runtime” e inserire lo stesso URL usato nella libreria.
Se volessimo fare un paragone, alla fine, la situazione finale è che il filmato che userà il simbolo della libreria lo carica (a runtime, appunto) come se usassimo LoadMovie() o derivati.

NOTA: come noterete il simbolo rimane vuoto e ulteriori componenti (altri MovieClip) del simbolo non sono visualizzati nella libreria.

Vantaggi

• Il simbolo condiviso viene caricato a runtime, quindi non occupa spazio nel filmato destinazione
• Non è necessario ricompilare il filmato destinazione in caso di cambiameti al simbolo sorgente, a meno che questi non siano ovviamente rilevanti e non tenuto in considerazione durante lo sviluppo iniziale (come dimensioni, forma, nuove proprietà, eventi o metodi…)

Svantaggi

• I simboli da esportare vanno impostato esplicitamente nella libreria e in modo rigoroso
• Bisogna creare una libreria e posizionarla nelle “vicinanze” del filmato che la vuole usare
• Durante lo sviluppo il simbolo importato non è visibile e compare come MovieClip vuoto, solo eseguendo il filmato verrà mostrato il simbolo

Condividere simboli in Authortime

La soluzione authortime è quella che preferisco nella maggioranza dei casi. Nella sua semplicità permette un controllo maggiore anche sulle revisioni del codice. Essa si basa totalmente sulla capacità dell’ambiente di sviluppo di Flash, l’IDE, di legare un simbolo di un sorgente (.fla) ad un diverso sorgente (.fla). Nella condivisione authortime, quindi, non abbiamo necessità di creare esplicitamente delle librerie (filmati SWF compilati), queste, per così dire, sono altri sorgenti .fla e il tutto è controllato in authortime (o designtime, se preferite). La condivisione, quindi, avviene durante lo sviluppo e termina alla compilazione del filmato.
Anche in questo caso si opera tramite la finestra delle proprietà di un simbolo. Basta creare un simbolo vuoto nel nostro filmato e aprire la finestra delle sue proprietà:

Cliccate quindi sul bottone “Sfoglia” e selezionate un qualsiasi altro sorgente .fla. A questo punto si aprirà un’altra finestra con la lista dei simboli presenti nel sorgente che avete selezionato:

Selezionate il simbolo che volete usare e, tornati alla finestra delle proprietà…

… spuntate “Aggiorna sempre prima di pubblicare”. Questo punto è essenziale in quanto permette di legare questo simbolo ad eventuali aggiornamenti che farete nel filmato sorgente. L’importazione del simbolo, in questo caso, avviene in designtime, quindi il simbolo e le sue parti sono fisicamente incluse nel nostro filmato. Semplificando, dunque, il simbolo che andrete ad usare non è davvero presente nel vostro sorgente… lo è come link. Infatti, se provate, Flash vi “impedirà” di modificarlo direttamente nel vostro filmato. Sarete “costretti”, per così dire, ad aprite la “libreria” (sorgente .fla) da cui lo avete importato per effettuare aggiornamenti. Inoltre, se modificate un simbolo che avete “incluso” nella libreria originale, dovete ricompilare tutti i filmati che lo usano!

Vantaggi

• Semplicità nell’importanzione dei simboli
• Non è necessario impostare nulla nei sorgenti da cui si prelevano i simboli (i sorgenti sono altri sorgenti .fla)
• Non è necessaria nessuna libreria runtime, il filmato finale è autosufficiente

Svantaggi

• Il simbolo condiviso (e tutte le sue parti) viene incluso nel filmato destinazione
• Se viene modificato un simbolo sorgente bisogna ricompilare tutti i filmati che lo usano

Condivisione di simboli ibrida: authortime e runtime

Questa è una mia scoperta, credo, comunque non documentata nei testi a me a disposizione. Nasce esclusivamente da prove fatte e non ho ulteriori notizie a riguardo. Quello che sono riuscito a fare è unire l’uso delle condivisioni runtime e authortime semplicemente selezionandole contemporaneamente!

Facendo così abbiamo i pregi di entrambi i metodi! Durante lo sviluppo visualizziamo correttamente il simbolo e in libreria sono presenti le sue parti. Se modifichiamo la libreria sorgente non è necessario ricompilare il nostro filmato nonostante abbiamo importato tutto anche in authortime. Insomma, almeno dai test che ho eseguito, questa potrebbe essere la soluzione ideale se non definitiva; si hanno i vantaggi di entrambe le situazioni. Inoltre il peso finale del nostro filmato è inferiore in quanto il simbolo è caricato sempre in runtime con il vantaggio di vederlo mentre sviluppiamo!

NOTA: nei testi che ho visionato queste due modalità vengono trattate in modo separato come se una escludesse l’altra. Forse l’errore è proprio qui, ovvero che possono essere usate contemporaneamente.

Conclusioni

Scegliere è comunque sempre difficile e dipende dalle necessità del progetto e del momento. La condivisione authortime è la più semplice ma anche la meno performante. Risulta comoda in designtime ma costringe a ricompilare tutti i filmati in caso di nuove release del simbolo usato.
La condivisione runtime richiede più tempo e la creazione di una libreria compilata, ma garantisce filmati più snelli che si aggiornano senza bisogno di ricompilazioni. Rimane scomoda in designtime in quanto non viene proposta un’anteprima del simbolo.
Creare un componente sarebbe la soluzione ideale, tuttavia il tempo richiesto per il suo sviluppo restringe l’uso di questa tecnica in rari e specifici casi.
La condivisione ibrida sembra essere perfetta anche se non documentata, almeno in Flash MX. Io comunque la uso e fino ad ora…

Questo articolo ti è stato utile?:

 Loading ...

• 

• Tweet