bitmama

Dal sito Adobe: <<Flex è un framework open source gratuito ad alta produttività per la creazione e gestione di applicazioni web interattive implementabili uniformemente su tutti i principali browser, desktop e sistemi operativi>>.

Perché è nato Flex?
In un mondo in cui ormai la banda larga è di comune accesso, almeno nei paesi industrializzati, il confine tra applicazioni locali (installabili sul proprio PC) e remote (siti web) sta diventando sempre più labile.

Già oggi esistono applicazioni remote fondamentalmente indistinguibili dalle loro declinazioni locali.

Basta considerare l’esempio di Outlook Web Access e Microsoft Outlook.
Comparando OWA con qualunque sistema di web mail, è evidente da subito che sono state scavalcate in pieno molte caratteristiche tipiche delle “pagine web”. Interazioni evolute,  grafica marcatamente “applicativa”, plasticità dell’ambiente di lavoro, tutto fa pensare ad una applicazione installata sul proprio PC, mentre in realtà tutto avviene via web.
OWA è uno dei primi precursori di una trasformazione che vedrà nel tempo spostarsi in remoto applicazioni sempre più massicce, addirittura del calibro di Photoshop o di Illustrator. I vantaggi di questa delocalizzazione del software sono evidenti: nessuna installazione sul proprio PC, aggiornamenti software totalmente trasparenti e istantanei, ma soprattutto – quando i tempi saranno maturi – delocalizzazione dei file di lavoro.
Questo passaggio, oltre a garantire l’incorruttibilità e non volatilità dei dati che non saranno più soggetti a rotture del disco rigido, furti del laptop, crash di sistema e cortocircuiti degli alimentatori, porterà i nostri PC ad essere sempre di più “scatole vuote”, che useremo per lavorare con programmi remoti su dati remoti.
Il completamento di questa trasformazione probabilmente significherà che qualunque PC del mondo potrà essere il nostro PC. Ci basterà portare con noi la nostra “identità digitale” comodamente custodita in una chiavetta USB o addirittura solo in una combinazione username - password, e istantaneamente potremo sederci a qualunque PC del pianeta e ritrovarci il nostro desktop, i nostri file, i nostri settaggi.
Per raggiungere un simile risultato, e quindi far girare applicazioni tremendamente complesse su browser, è evidente che linguaggi come HTML, PHP, Javascript e ASP sono insufficienti. E’ necessario avvalersi di framework molto più avanzati di quelli gestiti normalmente da un browser. Dovremo operare invece all’interno di “runtime environment” come ad esempio JRE (Java Runtime Environment) o Flash Player 9, che ci garantiscono la possibilità di programmare e far girare i nostri applicativi facendo uso di tutte le risorse normalmente a disposizione di un tipico linguaggio a oggetti – del tipo di C# e Java – che rappresenta lo standard di programmazione per qualunque applicativo ora utilizzato in locale.
Nell’ottica di rendere possibile questa trasformazione, Adobe e Microsoft si sono ritrovate a rilasciare quasi contemporaneamente due framework di sviluppo (Adobe CS3 ed Expression rispettivamente) con le caratteristiche necessarie a sviluppare progetti di questo tipo.

Cos’è Flex?
Come già detto, Flex è un framework per la programmazione di applicazioni. Flex permette di sviluppare applicazioni rich media, che possono essere eseguite via browser da Flash Player 9 oppure proiettate localmente come eseguibili attraverso Adobe AIR, di cui parleremo tra non molto.
A tutti gli effetti, Flex esporta file swf, esattamente come fa Flash. E’ in grado anche di utilizzare, all’interno delle proprie “pagine”, componenti, animazioni ed applicazioni create con Flash, esattamente come un filmato swf ne può caricare un altro all’interno di un suo movie clip.
Il risultato è che Flex si propone come un ambiente di assemblaggio attivo, in grado di contenere, organizzare e far comunicare tra loro componenti nidificate ed anche estremamente complesse, create in Flash o in Flex stesso.
Certo tutto questo non viene senza un prezzo da pagare. Per poter utilizzare una logica di questo tipo, Flash si è dovuto trasformare internamente, evolvendosi dall’ibrido che era, a metà strada tra programma di animazione – dal quale ha ereditato la struttura a timeline – e linguaggio di scripting, in vero e proprio linguaggio di programmazione a oggetti.
La timeline in Flash esiste ancora, ma la sua centralità è stata soppressa in favore di una solida struttura di programmazione a classi, che ricalca perfettamente quella di un normale linguaggio Object-Oriented come C#.
Se questo salto evolutivo da un lato ha destabilizzato e sprofondato nel panico un’intera comunità di programmatori che si trovavano perfettamente a loro agio con uno scripting language ma molto meno in presenza di un linguaggio a oggetti, ha conseguito il doppio scopo di attirare verso Flash/Flex l’immenso bacino di programmatori Object-Oriented (che da sempre operano in campo applicativo) e di consentire lo sviluppo di applicazioni effettivamente modulari, scalabili e velocissime in calcolo, che sarebbero state impossibili da creare con un linguaggio come ActionScript 2.

Com’è fatto un progetto Flex?
Flex opera sostanzialmente su due fronti: un linguaggio ad oggetti, AS3, che definisce il comportamento “attivo” di ogni componente, ed un metalinguaggio, MXML, modellato sulla base di XML, che definisce un componente e il suo contenuto, e in questo modo – in virtù del fatto che un componente può contenere un altro componente – assembla tra loro i componenti stessi e li rende reciprocamente accessibili.
Senza scendere nel dettaglio di come metalinguaggio e codice interagiscono e si completano tra loro, possiamo concederci una certa approssimazione e dire che qualunque elemento Flex può essere visto come una scatola che esegue determinate operazioni e può ospitare al suo interno altre scatole.
In questo gioco di scatole cinesi, il contenitore più esterno sarà la nostra applicazione, e il più interno sarà un componente base (area di testo, bottone, dropdown menu e così via) o una sua declinazione.
Affidandoci a Flash e ad AS3 potremo anche creare componenti da zero, usando tutte le risorse che ActionScript, in questa sua ultima incarnazione, ci mette a disposizione. Vale la pena rimarcare che queste risorse e le loro applicazioni già pronte sono virtualmente illimitate, in quanto un’intera, estesissima comunità di utenti è quotidianamente impegnata nel titanico sforzo globale di sviluppare e condividere componenti di ogni tipo.
Il fatto che Flex e Flash oramai operino in una logica totalmente ad oggetti, garantisce entro certi limiti che questi componenti saranno universalmente intercompatibili, semplici da customizzare e semplici da integrare in qualunque applicazione da qualunque altro programmatore sparso sul pianeta.
Flex inoltre consente di utilizzare dei “resource manager” interni, che permettono ad esempio  di staccare completamente i contenuti testuali e raggrupparli in file esterni pronti per la localizzazione in più lingue.

Oppure di tenere in luoghi terzi le componenti grafiche o di skinning, evitando in questo modo di contaminare la buona lettura di un componente con lunghe sequenze di dichiarazioni inerenti alla rappresentazione grafica.

Ancora, Flex consente di utilizzare dei veri e propri fogli di stile, che ci consentono di mantenere solido e snello il codice dei componenti stessi, e di controllare centralmente l’aspetto dell’applicazione, senza dover apportare pesanti e ridondanti modifiche a ciascun componente di un certo tipo.

È tutto oro quel che luccica?
Ovviamente no. Il passaggio a questa nuova logica di strutturazione dei progetti, ha ricadute importanti sull’aspetto, il peso e i tempi di sviluppo delle nostre applicazioni.
Innanzitutto, programmare secondo la logica di un linguaggio ad oggetti estremamente formale come AS3 significa che non possiamo più improvvisare. Se in AS2 potevamo metterci alla tastiera, andare un po’ a caso, e modificare in corso d’opera il nostro lavoro con una certa libertà, AS3 ci obbliga ad aver chiaro fin dal primo istante come l’applicazione si dovrà muovere in ogni dettaglio. L’approccio “a scatole cinesi” implica che qualunque modifica noi facciamo si ripercuoterà a cascata su tutte le scatole di ordine superiore, e pertanto – anziché metterci allegramente alla tastiera – dovremo iniziare lo sviluppo prendendo carta e penna e mettendo giù uno schema dettagliato dell’applicazione e di tutti i moduli che la compongono. Questo, unito alla proverbiale prolissità dei linguaggi a oggetti, può arrivare anche a decuplicare il tempo di sviluppo di un progetto. Un sito che in Flash AS2 veniva creato con un paio di decine di file swf, in AS3 probabilmente sarà composto da diverse centinaia di file. Un labirinto in cui ci perderemo certamente se non ne abbiamo disegnato in precedenza una mappa chiara e dettagliata.
In secondo luogo, un approccio modulare crea inevitabilmente un oggetto dall’aspetto modulare.

Sviluppare in Flex significa rendere evidente questa logica. La libertà che ci era concessa fino a poco fa di concepire ogni volta un progetto originale e variegato, con strumenti di navigazione bizzarri e fantasiosi, rappresentazioni grafiche dinamiche e folli, ne esce pesantemente ridimensionata. Se è vero che comunque possiamo interpretare il nostro sito, la nostra applicazione o alcune sue parti, come singoli giganteschi componenti Flash e quindi recuperare in quei contesti il nostro grado quasi assoluto di libertà, questa viene comunque – a causa del linguaggio e, come dicevamo, della sua struttura intrinseca – al prezzo di un incremento dei tempi di sviluppo di un entità tale da suggerirci implicitamente di cambiare strada. Tanto più che l’uso di Flex come infrastruttura, intesa come facilitatore dell’assemblaggio di componenti complesse, a questo punto perde di senso.

In sostanza, limitare l’uso di componenti standard in favore di oggetti monouso sviluppati da zero, significa dover mettere in conto un’enorme mole di lavoro in più: una mole di lavoro che tra l’altro difficilmente potremo riciclare su progetti futuri. E’ inevitabile quindi che un progetto sviluppato in Flex, per quanto spingiamo lo skinning o l’uso dei CSS o la creazione di componenti custom, finirà sempre e comunque per rivelare la struttura modulare tipica di un’applicazione più che di un progetto di comunicazione web.
In terzo luogo, il peso dei file swf prodotti da Flex è considerevole. Se una semplice applicazione Flash poteva avere un peso di pochi KB, difficilmente un swf prodotto da Flex scenderà sotto i 200 KB. Questo perché ciascun componente Flex di base deve poter essere totalmente riconfigurabile, solido e multi-purpose, il che comporta molte linee di codice. Come se questo non bastasse, siccome tipicamente un componente customizzato comunque estende un componente di base, quando tentiamo di “contenere i costi” sviluppando oggetti da zero, in realtà non facciamo altro che aggiungere linee di codice ad oggetti che già sono tutt’altro che snelli.

Allora perché passare a Flex?
In realtà “Passare a Flex” è una frase fuorviante e priva di senso. Flex è uno strumento che si aggiunge alla nostra scatola degli attrezzi, non la nuova versione più evoluta di un attrezzo di cui disponevamo già. In realtà non c’è praticamente nulla che si possa fare in Flex che non si possa fare anche solo con Flash CS3.

Del resto, come abbiamo visto, Flex produce come risultato dei file swf. Non c’è quindi motivo di supporre che gli swf prodotti da Flex siano differenti da quelli prodotti da Flash.
Dovremmo piuttosto interrogarci su quali siano le occasioni in cui Flex semplifica il nostro lavoro, e imparare a distinguere queste situazioni da quelle in cui Flex diverrebbe soprattutto un ostacolo al nostro lavoro.
Abbiamo già alcuni criteri che ci permettono di trarre conclusioni di questo tipo. In generale, la disponibilità che ci viene data di “blocchi di costruzione” già pronti e facilmente integrabili e customizzabili, ci suggerisce l’uso di Flex ogni qual volta ciò che dobbiamo costruire fa pesante uso di questi blocchi: data grid, dropdown menu, tile list, view stack, tab navigator, selettori di ogni tipo che debbano interfacciarsi a sistemi di dati complessi, accordion, pannelli, slider, e chi più ne ha più ne metta.
Già questa lista ad ogni modo identifica il nostro progetto più come un’applicazione in senso stretto che come un sito web classico, almeno dove con sito web si intenda un’entità il cui scopo è presentare, interessare e stupire, più che gestire in modo dinamico, organico e intellegibile una grande quantità di dati.
Un ottimo esempio potrebbe essere un sito di commercio elettronico. In una situazione simile possiamo prevedere un’area in cui il prodotto viene presentato, concepita come un unico grosso componente Flash AS3, ma appoggiata tuttavia ad una infrastruttura di navigazione e ricerca dei prodotti sviluppata in Flex.

Nel componente di presentazione del prodotto potremo agevolmente sfruttare tutte le possibilità di Flash di gestire in modo complesso oggetti grafici, video ed effetti speciali, mentre nell’infrastruttura di navigazione potremo usare tutta la potenza e la semplicità d’uso di Flex nel gestire maschere, selettori e filtri sui dati.
Tuttavia, se inserire componenti Flash in infrastrutture Flex è un’operazione intrinsecamente naturale per Adobe CS3, ed anzi fa parte del modo in cui Flex è concepito, inserire moduli Flex in un progetto Flash può rivelarsi tutt’altro che semplice e molto meno sensata. Per questo motivo, nel caso di un sito che ospita un motore di commercio elettronico all’interno di un ambiente “cool” di presentazione generale del marchio, è sempre una buona idea tenere la componente di e-commerce staccata dal resto del progetto; in alternativa dovremo rassegnarci a creare il “contenitore” esterno del sito in Flex, magari tenendo in Flex la navigazione principale – con tutto ciò che questo comporta – e sviluppare poi le singole pagine di presentazione in Flash.

Flex, pro e contro
Per concludere, sintetizziamo in una lista i pro e i contro relativi all’uso di Flex, cercando di darci dei parametri che ci consentano di fare una scelta ponderata quando si tratterà di scegliere quale tecnologia usare per lo sviluppo di un determinato progetto.
Pro:
•    Disponibilità di un largo numero di oggetti già pronti per lo sviluppo di applicazioni rich media
•    Possibilità di integrare componenti custom che fanno largo uso di Flash AS3
•    Mantenimento di modularità, scalabilità e stabilità strutturale dell’applicazione intrinsecamente garantite
•    Gestione efficace e puntuale della sicurezza
•    Semplicità di gestione di data provider complessi e di grandi quantità di dati
•    Importazione diretta delle definizioni degli web service e dei relativi metodi (WSDL)
•    Riusabilità delle componenti custom su altre applicazioni future
•    Disponibilità in aumento continuo di componenti sviluppate da terze parti (commerciali ma anche freeware)
Contro:
•    Peso consistente dei file SWF prodotti dal framework
•    Pesanti limitazioni al design grafico e funzionale dell’applicazione prodotta
•    Lunghi tempi di sviluppo
•    Scarsa plasticità del design in corso d’opera
•    Necessità di pianificare in anticipo e con un grande livello di dettaglio la struttura e le funzioni dell’applicazione e delle sue componenti
 

Conclusioni
Flex è una tecnologia complessa e potente, che solo con l’’attuale versione 3 ha raggiunto una stabilità sufficiente a giustificarne la scelta per lo sviluppo di applicazioni commerciali. E’ ancora afflitta da numerosi bug, ed eredita dalla sua natura ibrida un approccio un po’ sporco allo sviluppo. Lo stesso risultato, ad esempio, può essere conseguito strutturando l’interrelazione del codice tra componente MXML e AS3 in almeno tre modi diversi, ciascuno dei quali porta con sé stramberie e limitazioni. Tuttavia Flex rappresenta una scelta eccellente in un circoscritto insieme di situazioni, nelle quali i suoi punti di forza lo rendono lo strumento ideale per lo sviluppo. Ovunque dobbiamo sviluppare un sistema visivamente e strutturalmente modulare, che opera in modo complesso su una grande quantità di dati, e pensiamo di aver bisogno di strumenti di navigazione relativamente standardizzati, Flex sicuramente rappresenta la scelta ideale. In tutti gli altri casi, è meglio considerare le alternative.

Adobe AIR
Dal sito Adobe: << Il runtime Adobe AIR consente agli sviluppatori di utilizzare tecnologie web di provata efficacia per la creazione di rich Internet application implementabili sul desktop ed eseguibili sui sistemi operativi.>>

Cos’è AIR?
AIR significa Adobe Integrated Runtime. Un “runtime” in questo caso indica una piattaforma software in grado di “proiettare” sul desktop del nostro PC, e quindi all’esterno del browser, un’applicazione originalmente concepita per il web, e quindi di farla girare localmente (per il vecchio Flash erano disponibili pacchetti simili, come Zinc ed mProjector). Inoltre rende disponibili alla nostra applicazione delle API (Application Programming Interface) che la mettono in grado di interagire con il file system locale. In questo modo, la nostra applicazione può accedere alle cartelle locali, crearne di nuove o cancellare quelle esistenti, leggere e scrivere file di qualunque tipo, effettuare upload e download di file e così via. Rende quindi possibile effettuare, ad esempio, drag and drop di file tra l’applicazione e il desktop, così come siamo abituati a fare con gli oggetti OLE (Object Linking and Embedding) con la maggior parte delle applicazioni locali.
Attualmente AIR funziona sui seguenti sistemi operativi: Microsoft Windows 2000, Windows XP, Windows Vista Home Premium, Business, Ultimate o Enterprise e Mac OS X v. 10.4 o 10.5. Nel Settembre del 2008 è stata rilasciata in beta la versione per Linux.
Programmare con AIR in sostanza significa produrre un file in un metalinguaggio specifico simile all’XML, che specifica per una determinata applicazione alcuni parametri di base del proiettore, come ad esempio le dimensioni minime e massime dell’applicazione su schermo, i folder di installazione, la trasparenza del fondo, una eventuale chrome (maschera di contorno) e così via.
AIR produce come risultato un file eseguibile, al quale può essere apposta una firma digitale (dall’Agosto 2008 Adobe ha stretto un accordo in questo senso con VeriSign), e che può essere installato e lanciato come qualunque programma eseguibile. AIR è provvisto anche degli strumenti per fornire all’applicazione un installer standard che rimane comunque completamente riconfigurabile.
Combinato con Flex, AIR è in grado di produrre applicazioni a tutto tondo, per nulla dissimili dai programmi per PC che utilizziamo quotidianamente: Word, Photoshop, ma anche Flash e Flex stessi. La sua capacità di includere nel pacchetto di esportazione interi sistemi basati su web, comprensivi di pagine HTML, AJAX e Flash, lo rendono un “proiettore” unico nel suo genere.