E alcuni mesi che lavoro assieme a Simbul su un progetto interno a Kallideas realizzato integralmente in Flash CS3.
Data la mia predilezione per ECMAScript 3.x come linguaggio non ho potuto che apprezzare il passaggio di Flash da una interfaccia a livello codice orrenda e inconsistente ad un paradigma finalmente sensato con una Virtual Machine mostruosamente più efficiente e veloce (AVM2).

Fra i dispiaceri che posso annoverare ci sono:

1. L’utilizzo di ECMAScript 4.x (draft). ECMAScript 3.x utilizza il paradigma a oggetti basato su prototipi, mentre la 2.x ci aggiunge (e quasi preferisce) il paradigma a oggetti basato su classi (alla Java, C#, etc per intenderci). Se non fosse chiaro, preferisco i prototipi.
2. La scelta di obj.addEventListener(Event.EVENT, function() {}) invece di obj.onEvent += function() {}, sintatticamente più chiaro.

Non voglio però approfondire qui i miei rant su AS3, quindi proseguiamo con questo breve corso introduttivo. Tenderò a dire tante cose in modo molto sintetico, per dare un panorama generale e contemporaneamente tutti gli elementi necessari per partire. I buchi mancanti dovrete ovviamente riempirli voi… o chiedermi nel caso ulteriori spiegazioni.

Esternalizzare il Bootstrap del Codice AS3

Il progetto l’ho avviato fin da subito in modo che utilizzasse l’IDE praticamente solamente per la compilazione (ed eventualmente la programmazione, se non si ha un altro editor).

Questo può essere fatto nel modo grezzo mettendo sul frame 1 il seguente codice:

include "init.as";

Oppure il modo elegante implica configurare il file FLA aprendo File -> Publish Settings… -> Flash -> Settings… -> Document Class e scrivere qui il nome della classe AS che si posizionerà a fianco del file FLA (o in uno dei path di ricerca).
La classe richiamata deve ereditare da MovieClip (o credo da qualunque oggetto erediti da DisplayObject). Supponendo di aver scritto in Document Class il nome “MyApp” il codice contenuto nell’omonimo MyApp.as è:

package {
    import flash.display.MovieClip;

    public class MyApp extends MovieClip {
        public function MyApp() {
            // code
        }
    }
}

Dentro il costruttore della classe, come dentro il file “init.as” specificato nel metodo grezzo, scriverete il vostro codice AS3.
A questo punto Flash non lo toccherete più se non per eseguire il codice o debuggare.

Io consiglio di tenere il file FLA nella root del vostro progetto e creare una cartella source/ che conterrà tutte le vostri classi e package AS.

Se interessa come strutturare i package e le classi ActionScript consiglio Google e la documentazione Adobe piuttosto buona. Poi beh, se proprio volete scriverò un altro post.

Flex SDK (MXMLC) è free

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

Potete scaricare Flex SDK (2.0 stable o 3.0 beta 2). Io utilizzo la 3, al momento senza alcun problema.

Alcuni vantaggi nel passare a MXMLC:

1. E’ free.
2. Eliminazione del peso di Flash CS3, 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.

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

E ‘ bene notare anche una cosa: è vero che Flex è free (opensource), ma il formato SWF è ancora chiuso e soprattutto rimane chiuso Flash Player. La virtual machine AVM2 invece è aperta (Tamarin).
Certo, anche Windows come piattaforma è chiusa, anche OS X. Ognuno sceglie, però è meglio chiarire questo dubbio.

Da Flash a MXMLC

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

Prima di tutto, passate al metodo elegante di bootstrap del codice.

• Se utilizzate classi nel namespace flash.* e non in fl.* allora il vostro codice è già pronto.
• 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 (i.e. source/).
• 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).
  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/.
• 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: le variabili su cui agiscono risulteranno quindi vuote se compilate da Flash, piene da MXMLC.

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.

Eseguire MXMLC

Una cosa molto interessante che ho scoperto solo recentemente è che MXMLC funziona anche prendendo come parametro un file AS, non soltanto file MXML.

Si tratta proprio dello stesso file AS creato con il metodo elegante di bootstrap del codice.

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 0x0066cd).
• -compiler.warn-no-type-decl=false: questo lo utilizzo io perché ritengo importante che in AS3 la tipizzazione sia 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.

Sono tutt’ora in fase di osservazione e transizione, l’applicazione di cui parlavo all’inizio ad esempio è tutt’ora su Flash e vi sono alcune cose che devo ancora chiarirmi (ad esempio l’embed). Aggiornerò questo post.

A questo punto dovreste avere un progetto compilabile contemporaneamente su Flash e su Flex/MXMLC. Spero che non vi siate spaventati troppo.

Suppongo non abbia nativamente tutta la ricchezza che una applicazione Apollo può avere (visto che crea solo un wrapper intorno all’SWF) però è un ottimo passo soprattutto per la semplicità. L’avvio deve essere semplice, c’è sempre tempo per approfondire.

Io pensavo più a Firefox (per la precisione XULRunner) + Ruby on Rails (possibile) in modo da avere un contenitore standalone di Firefox, Ruby on Rails e SQLite. Ma d’altronde avere solo le idee senza i soldi e le persone per realizzarle significa solo che ci arriverà prima o poi qualcun altro.

Peraltro, il concept di un prodotto simile, almeno su Apple Mac OSX, già esisteva. Ed era un prototipo parecchio instabile di Instiki (Wiki su RoR) realizzato da Oleg Kourapov. Un singolo file .app (ovvero, un programma OSX) che conteneva Instiki, RoR, e credo un database di qualche tipo.

Vantaggi? Ok, vantaggi. In due righe: sviluppare un programma desktop standalone con le stesse skill necessarie per un applicativo web, capace di garantire una forte coesione con un servizio online e una “assenza” di differenze fra l’interfaccia web e quella desktop. In aggiunta, caching offline dei dati (non tutti hanno 24/7 una connessione internet).

L’unico, enorme dubbio che ho su Apollo è la pesantezza, vi raffiguro il mio dubbio con una domanda: in quanto tempo si apre a voi Adobe Acrobat Reader ultima versione su PC?