Da Flash a Flex: ActionScript 3 verso l’OpenSource

Un ambiente per grafici, un linguaggio poco performante e una libreria
scadente sono storicamente annoverati fra i problemi che i programmatori
incontrano in Flash, tutt’ora malvisto proprio per questi motivi. Aggiungete a
questo risorse in rete scadenti e poco aggiornate, unite a fastidiose
animazioni e risulta chiara la cattiva fama di Flash.

Fortunatamente nel giugno 2006 Adobe ha rilasciato la versione 9 del Flash Player e la 2 di Flex che ha letteralmente rivoluzionato il panorama:

  • una nuova virtual machine (AVM2) estremamente più performante: 10x50x di miglioramento,
  • il linguaggio ActionScript v3 aggiornato a ECMAScript 4th ed. draft,
  • una libreria completamente ristrutturata e resa a oggetti.

A questo si aggiunge la volontà espressa da Adobe di liberare il proprio codice sotto licenza opensource Mozilla (MPL): la virtual machine, Tamarin è già disponibile, mentre Flex 3 SDK verrà rilasciato nei mesi a venire.

Un ulteriore aspetto da considerare è AIR (Adobe Integrated Runtime), che consente di fare diventare i propri progetti Flash o Flex degli applicativi desktop multipiattaforma (Windows, OSX e più avanti Linux).

Questo articolo ha lo scopo di fornire il minimo insieme di elementi per approcciare dal versante opensource ActionScript 3.0, cercando di spiegare a chi non conosce il linguaggio come partire e offrendo contemporaneamente a chi già ha conoscenze in Flash un modo per estendere l’orizzonte verso Flex.

RIA

I vantaggi nell’uso di Flash sono abbastanza noti: una notevole potenza multimediale (2D, audio, video) che si traduce nella possibilità di realizzare interfacce innovative e ad-hoc, unitamente ad una capillare diffusione presso gli utenti.

Si possono identificare due modalità efficaci nella realizzazione di Rich Internet Applications in Flash:

  1. Flash come componente, ove l’applicazione è realizzata in altre tecnologie e solamente ove necessario viene utilizzato un componente SWF. Solitamente è la soluzione adottata nel caso di una piattaforma Ajax (che fornisce la libertà maggiore lato server).
    Questa è la situazione più comune, basti pensare alle varie piattaforme video (YouTube, Viddler), audio (Last.fm, Pandora) e testo (SlideShare, Scribd).
  2. Flash come piattaforma, ove tutta l’applicazione è realizzata in ActionScript 3. Questa soluzione è interessante perché il server ancora una volta è indipendente e fornisce solamente le API, garantendo una ottima separazione delle funzionalità (BuzzWord, SlideRocket).

Ognuna di queste alternative ha pro e contro, che vanno valutati in rapporto al progetto che si sta realizzando. D’altronde è una cosa che andrebbe comunque fatta. 😉

La recente piattaforma AIR, apre altre prospettive:

  1. Il codice per il web e per il desktop può essere scritto una volta sola e riutilizzato fra browser e sistemi operativi.
  2. Aumenta l’integrazione del web con il desktop, portando anche supporto per la modalità offline (ma non solo: filesystem, drag’n’drop, etc).
  3. Non è necessario imparare un nuovo linguaggio di programmazione per sviluppare una applicazione desktop (in questo senso consiglio di buttare un occhio anche a XULRunner).
  4. AIR non fornisce solo supporto a Flash, ma anche ad applicazioni Ajax.

Volendo una definizione semplice, il vantaggio nell’utilizzare la tecnologia Flash è rappresentato dalla flessibilità che si può ottenere assieme all’ampio ventaglio di possibilità che vengono offerte ad un basso costo di sviluppo.

Programmare in Flash

Flash è un ambiente nato essenzialmente per grafici ed animatori e anche se nelle ultime versioni fa l’occhiolino agli sviluppatori il suo focus rimane quello originale.
Ci si potrebbe quindi chiedere perché si parla di programmare in Flash, quando esiste Flex che è nato proprio per gli sviluppatori. Le ragioni possono essere varie:

  1. È diffuso: spesso si parte da un applicativo Flash già esistente e si modifica quello.
  2. È semplice: una volta installato non serve altro per iniziare.
  3. È integrato: workflow già esistenti spesso implicano un contatto diretto con grafici e animatori.
  4. È documentato: seppure molto si riferisca ad ActionScript 1 e 2, la maggior parte delle domande e risposte che troverete online sono legate a Flash.

È però consigliabile tenere una buona separazione della parte visuale da quella logica, esternalizzando il codice sorgente. In questo modo, oltre ad avere una buona architettura, si da potenzialmente al grafico la gestione completa del file FLA. È quasi inutile aggiungere che in questo modo i file possono essere messi sotto VCS.

Una volta creato il file esterno (supponiamo di chiamarlo “MyApp.as”), vi sono due semplici modi per eseguire il bootstrap del codice:

  • Metodo Grezzo:
    Si scrive una riga di inclusione sul primo frame della prima scena di un livello qualsiasi del file FLA:

    include "MyApp.as";

    La semantica del comando è intuitiva: include il file “MyApp.as” come se fosse scritto direttamente nel file FLA. Viene posizionato sul primo frame in modo che sia la prima cosa eseguita.

  • Metodo Elegante:
    Si apre il menu File -> Publish Settings… -> Flash -> Settings… -> Document Class e si scrive qui il nome della classe AS: “MyApp”.

    Notate che non ho citato il file? Infatti “MyApp.as” conterrà la vostra classe base che erediterà da MovieClip (o da Sprite).
    Il codice al suo interno è:

    package {
        import flash.display.MovieClip;
    
        public class MyApp extends MovieClip {
            public function MyApp() {
                // code
            }
        }
    }

    Per evitare dubbi: sì, il file deve avere lo stesso nome della classe.

Cito anche il metodo grezzo perché in alcune situazioni risulta ultile: non richiede alcuna conoscenza pregressa ed è possibile usarlo rapidamente in progetti già esistenti, se necessario anche includendolo puntualmente solo nel momento giusto e non nel primo frame, agendo subito sugli oggetti presenti nella scena in quel momento.

Un consiglio che posso fornire è quello di inserire tutta la propria gerarchia di classi all’interno della sottocartella source/ e aggiungerla nella configurazione del file FLA (stessa schermata del metodo elegante, poco più sotto).

Flex SDK

La prospettiva di Flex SDK opensource è assieme ad AVM2 e AS3 il motivo per cui ora ritengo la “piattaforma Flash” degna di sviluppo più consistente.

Vediamo alcuni vantaggi:

  1. E’ free.
  2. Eliminazione del peso di Flash CS3 (240Mb di RAM usata…), che torna ad essere un ambiente visuale.
  3. Possibilità di usare alcune macro di inclusione automatica [Embed].
  4. Possibilità di usare MXML (”HTML per Flash”) e i suoi CSS.
  5. Possibilità di eseguire script batch.
  6. Possibilità di configurare sorgenti, librerie, etc in modo flessibile.
  7. E’ meglio indicato per chi volesse sviluppare in AIR.

Potete scaricare Flex SDK (2.0 stable o 3.0 beta). Io utilizzo la 3, al momento senza alcun problema. Non serve altro, a parte un buon editor.

Per chi volesse c’è anche Flex Builder, a pagamento, che è l’IDE di sviluppo per Flex SDK. Io tendo a fare notare solo una cosa: è Eclipse customizzato. Il risultato è che pesa più di Flash CS3. DIY.

Da Flash a Flex

Se avete sviluppato il progetto come ho indicato sopra, ovvero senza praticamente niente realizzato dentro Flash CS3 non dovrete quasi riscrivere nessuna parte del codice.

  1. Prima di tutto, se non l’avete già fatto, passate al metodo elegante di bootstrap del codice.
  2. Se utilizzate classi nel namespace flash.* e non in fl.* allora il vostro codice è già pronto.
  3. Se utilizzate classi nel namespace fl.* dovete aprire la cartella contenente la vostra installazione di Flash CS3 e localizzare la cartella “fl” (su OSX si trova nella sottocartella “ActionScript 3.0/Classes/fl”). Prendetela e copiatela nella vostra cartella dei sorgenti.
  4. Se utilizzate anche componenti fl.controls il metodo più semplice è creare un SWC da Flash CS3:
    Aprite quindi Flash, create un nuovo progetto AS3.
    Aprite il pannello components (Window -> Components) e trascinate nella Library tutti i controlli che volete utilizzare (non preoccupatevi, non saranno inclusi automaticamente tutti in compilazione).
    Aprite File -> Publish Settings… e specificate di voler creare anche il file SWC.
    Pubblicate.
    Copiate il file SWC in una sottocartella del vostro progetto. Per i sorgenti consigliavo source/, qui consiglio lib/.
  5. Se includete font o altri oggetti grafici da libreria dovrete includerle nuovamente con [Embed(…)] o altre tecniche.Faccio notare che i comandi [Embed()] sono ignorati da Flash, che lascerà vuote le variabili a cui sono associati. Questo dettaglio è utile se si vuole mantenere il codice compilabile in entrambi gli ambienti.

Come è abbastanza logico pensare potete vedere che all’aumentare delle risorse di Flash che avete utilizzato aumenta anche la difficoltà di transizione. Il vantaggio è però che avrete un progetto funzionante sia su Flash che su Flex.

Compilare in Flex SDK: MXMLC

Il compilatore a riga di comando incluso in Flex è MXMLC ed è lo strumento di lavoro principale.

Una cosa molto interessante non molto ben documentata è che MXMLC funziona
anche prendendo come parametro un file AS, non soltanto file MXML (che
richiederebbe l’apprendimento di un altro “linguaggio”).
Si tratta proprio dello stesso file AS creato con il metodo elegante
di bootstrap del codice
. Comodo, no?

I parametri
a linea di comando
essenziali per MXMLC sono:

  • -sp [path]: il path contenente i sorgenti AS. Se avete seguito il mio consiglio di sopra sarà quindi source/ (i.e. -sp ./source/).
  • -library-path+=[path]: il path contenente le librerie SWC aggiuntive. Se avete seguito il mio consiglio sopra sarà quindi lib/ (i.e. -library-path ./lib/). Fate attenzione al “+=”.
  • -default-frame-rate [int]: il framerate del file SWF generato. Non avete più un file FLA, quindi va specificato (i.e. -default-frame-rate 25).
  • -default-size [int] [int]: le dimensioni di default del filmato SWF (i.e. -default-size 800 600).
  • -default-background-color [hex]: il colore di sfondo del filmato SWF (i.e. -default-bacckground-color 0×0066cd).
  • -debug=true: è utile in fase di sviluppo per poter debuggare meglio il codice (tramite fdb o altri). Ovviamente è da rimuovere quando si compila per la pubblicazione.
  • -incremental=true: crea un file di cache che permette alle esecusioni seguenti di ricompilare solamente le parti modificate nel frattempo.
  • -compiler.warn-no-type-decl=false: questo lo utilizzo io perché ritengo importante che la tipizzazione opzionale e la reputo uno dei più grossi vantaggi di AS3.
  • -allow-source-path-overlap=true: questo comando evita un warning in MXMLC dovuto al fatto che avete la cartella source/ come sottodirectory del file che state compilando.

Quindi per esempio, per compilare un programma con la struttura analoga a
quella qui presentata si utilizzerà:

mxmlc "MyApp.as" -sp "source" -library-path+="lib" -incremental=true -compiler.warn-no-type-decl=false -allow-source-path-overlap=true -default-frame-rate 25 -default-background-color 0xffffff

Se volete vedere il tempo di esecuzione, in millisecondi, potete aggiungere anche -benchmark=true.

Esiste anche un altro tool, che potrebbe essere comodo, fornito con Flex 3 SDK: fcsh, Flex Compiler Shell. Questa applicazione non è altro che una shell che tiene in memoria tutte le librerie, in modo da rendere ancora più veloce la compilazione del codice.

A questo punto dovrebbero esserci tutti gli elementi per poter lavorare con efficacia in ActionScript 3. Alcune cose sono state solamente citate, nozione utile comunque per iniziare e per procedere eventualmente ad un approfondimento tramite gli oracoli della rete: con la parola chiave giusta si può fare molta strada.

È davvero OpenSource?

Inserisco in chiusura una piccola appendice: per molte persone è importante sapere che che la piattaforma su cui si sta costruendo non è soggetta al capriccio di una sola azienda. È quindi importante chiarire che non tutto lo stack produttivo di Adobe è opensource.

Per ora sono rilasciati opensource o lo saranno a breve:

  • Tamarin, o AVM2 (MPL/GPL/LGPL)
  • Flex 3 SDK (MPL)

Rimangono invece chiusi:

  • il formato SWF, per il quale c’è la documentazione disponibile, molto dettagliata, ma è vietato utilizzarla per realizzare un player,
  • la piattaforma AIR.

Per la precisione: Tamarin è soltanto la virtual machine, non tutto il Flash Player, che invece è costituito da più parti (fra cui la più ovvia è il motore di rendering).

Comments

  1. Penso valga la pena di citare anche FDB, il debugger Flex, che risulta utilissimo se si abbandona Flash CS3 IDE.

    Aggiungo un link alla documentazione di FBD perché non è facilissima da trovare 😉

  2. Con Flash si può fare anche grafica 3D, grazie a Papervision3D: http://blog.papervision3d.org/ .

  3. Sure! 😀

    E’ che non volevo estendere troppo il discorso. Il 3D di Papervision in fondo non è cmq nativo (come potrebbe esserlo Shockwave 3D) ed è possibile comunque grazie alla nuova virtual machine (le demo con la vecchia erano da brivido :D).

    Thx per il link a FDB, in effetti è utile per chi si trova in Windows a causa di quel bug sul sistema di help. 😀

  4. emmemeno says:

    Bell’articolo Folletto. Non seguivo lo sviluppo di Flash e AS dalla versione 1.0 😀

    Posso fare una domanda ingenua? Oltre il dimostrato aumento di 50volte dell’AS 3.0 rispetto alle versioni precedenti, per quanto riguarda la grafica vettoriale e lo streaming video come siamo messi? Grava ancora tutto sul processore come una volta o hanno trovato un modo per sgravare la CPU tramite GPU?

  5. Beh la domanda è più che lecita, anche perché comunque riguarda cambiamenti recenti. 🙂

    Sin’ora infatti Flash Player ha utilizzato sempre sostanzialmente la CPU, nonostante fosse ottimizzato.
    L’ultimo aggiornamento del Flash Player 9 (9.0.115, se non erro) ha incorporato fra le varie cose il playback del formato H264 e alcune accelerazioni hardware (come hardware scaling ed effetti grafici).

    Lo sgravio comunque esiste solo nel playback video e in alcune applicazioni specifiche. 🙂

  6. Sulla questione “Flash/Flex open source”, Mike Shaver di Mozilla la pensa un po’ diversamente:

    “But I think it’s pretty misleading to imply that the majority of Flash is provided by Tamarin: it’s quite possible to have Flash that doesn’t use ActionScript, but everything relies on the implementation of the Flash VM itself — with its own bytecodes, graphics semantics, object model implementation and data management. The Flash VM is a huge piece of engineering, and one that Adobe has not opened up at all, though Flash artists have been clamoring for years to know more about the platform they invest so heavily in, to say nothing of people wanting to bring Flash capabilities to other operating systems and devices.”

    (Il resto su http://shaver.off.net/diary/2007/12/12/being-open-about-being-closed/)

  7. Diversamente? Mi sembra quello che dicevo in conclusione (peraltro, era proprio il pezzo che mi ha portato a scrivere la precisazione finale). 😉

    In realtà avrei potuto essere più preciso, citando in modo più dettagliato quel pezzo. Solo che avrei dovuto addentrarmi di più nella questione (Tamarin è una VM che interagisce con “Flash”, che è una VM) e mi sembrava eccessivo per gli scopi dell’articolo. 🙂

    Giusta precisazione, comunque. 🙂

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.