Il problema che andrò ad affrontare è il seguente:
come faccio a comunicare ad una classe il risultato di una funzione, o pi√π generalmente dei “dati” elaborati in maniera asincrona da un’altra classe istanziata nella mia classe di partenza?

Se i dati fossero elaborati e restituiti in diretta non ci si porrebbe il problema, esempio ne sono le classi di largo consumo come Math e Date (es: var mioint:int = Math.round(9.99999)).

Ma se volessi delegare (termine usato non a caso, visto i trascorsi di as2 ) a delle classi customizzate la mole di lavoro tipo delle routines di caricamento o qualcosa di simile?

Poniamo il caso di voler caricare una configurazione per la nostra applicazione\sito\game\… che risiede su un file cfg.xml.
Potremmo fare il tutto all’interno della document class cos√¨,

1. creiamo una private var _cfgxml:XML
2. nel costruttore andiamo a caricarci i dati con var myLoader:URLLoader = new URLLoader(new URLRequest(‘cfg.xml’));
3. appioppiamo al loader un gestore di evento Event.COMPLETE a cui associamo il parsing dei dati myLoader.addEventListener(Event.COMPLETE,cfgParse);
4. creiamo private function cfgParse(e:Evento) in cui istanziamo _cfgxml = new XML(e.target.data);

Ok, √® un’ipotesi plausibile, ma se questo nostro file richiedesse attenzioni particolari? o se semplicemente volessimo delegare ad altre classi le funzioni di parsing, di comunicazione con componenti, ecc ecc, solo per la soddisfazione di essere pi√π “puliti” nel codice…?

In actionscript 2 avremmo utilizzato Delegate passando come argomento la timeline (o l’istanza di classe) di riferimento. Ma in actionscript 3 “Delegate √® stat’ segheit”

Si rende quindi necessario passare la timeline\istanzadiclasse di riferimento come parametro per l’istanziazione della classe che elaborer√† i dati.

Esempio:

document class

private var _cfg:CFGManager;
 
public function Main(){
//costruttore
_cfg = new CFGManager(this);
_cfg.loadCFG();
 
}public function continuaMainClass(){}

classe richiamata dalla document class

private var _main:Main; //riferimento alla classe chiamante
public function CFGManager(m:Main){//costruttore
_main=m;//qui vado a memorizzare i riferimenti al main
}
 
public function loadCFG(){
//qui carico il mio xml di configurazione
//appioppo l'event listener per il caricamento
//e poi passo il tutto a parseCFG
}
private function parseCFG(e:Event){
//qui parso l'xml da e.target.data
//e poi faccio continuare l'esecuzione del main
_main.continuaMainClass();
}

Perfortuna non è nulla di così complesso

Per ottimizzare il tutto per√≤ sar√† opportuno non ricevere in ingresso un parametro fortemente tipizzato, ad esempio la classe CFGManager accetta in input solo parametri di tipo “Main”…se si vuole “astrarre” il codice, in modo da renderlo riutilizzabile sar√† opportuno che accetti potenzialmente qualsiasi tipo di dato, da DisplayObject all’estremo “*”…ma poi sono gusti

avevo detto che sarei stato breve, quindi alla prossima

Esistono vari plugin di eclipse in grado di affrontare questa necessit√†, cito ASDT (actionscript development tools) per as2 e il binding dell’sdk di flex alle risorse di eclipse via flex2ant per as3.

Tuttavia tutti i metodi che ho sperimentato sono a mio avviso insoddisfacenti.

Dopo il rilascio del plug-in di aptana per il supporto della tecnologia Adobe AIR tutti (io per primo ) si aspettavano un supporto che tale plug-in apportasse all’ambiente di editing le capacit√† di gestire anche actionscript, ma nessuna risposta √® stata data in merito dallo staff tecnico di Aptana.

MA girovagando tra i ticket di Aptana oggi mi sono imbattuto in questo post il team esecutivo scrive:

We are currently working on the next milestone release of the core IDE and will discuss AS3 support once we start to plan our next Adobe AIR plugin release.

 (Stiamo giustappunto lavorando alla prossima release di aptana e discuteremo del supporto di actionscript 3  nonappena inizieremo a pianificare la prossima versione del plug-in per il supporto di AIR)

Certo, non è una risposta capace di entusiasmare le folle, ma almeno è una risposta
Inoltre il post procede con un

“This is definitely the most requested enhancement so we will take a hard look at what it will take to implement this.”

(questa è in assoluto la feature più richiesta quindi vedremo di fare il possibile per fare in modo di implementarla)

Ecco, in una riga hanno gi√† corretto il tiro…

Aspettiamo fiduciosi…
nel frattempo, bè, asdt e flex2ant non sono poi così male

Riporto il topic su wave9.it, leggetelo qui o andate direttamente alla fonte

Apro questo thread perch√® √® forte lo slancio che da un p√≤ di tempo a questa parte ha trascinato l’attenzione di molti “flasher” su AS3, e diverse sono le opinioni a riguardo tra gli addetti ai lavori e non solo.

Actionscript 3 ha portato insieme gioie e perplessità,
ha sicuramente accentuato le differenze tra le figure “flash coder” e “flash designer” marcando pi√π strettamente il territorio di confine.
Forse ha incrinato la figura del “flasher” come “colui che sviluppa in flash” e ha attirato (soprattutto con la sempre maggiore diffusione di flex) una valanga di coders a cimentarsi con actionscript.

C’√® chi pensa che AS3 abbia solo complicato le cose, o meglio turbato l’equilibrio che si era andato a creare con l’avvento di flash mx,
che con AS3 serva scrivere molto pi√π codice per fare le stesse cose che si facevano in AS2, e quindi non serva a nulla,
che AS3 e la AVM2 (la virtual machine di flash player 8.5+) sia solo una strategia di marketing per stravolgere il mercato e vendere flash 9 (ehm…cs3) e flex builder ad una fetta pi√π ampia di coders….

C’√® anche chi pensa che AS3 sia il “futuro” ( anche se non ancora ben rodato),
che AS3 sia effettivamente pi√π valido di AS2, che la virtual machine sia nettamente pi√π performante della precedente…e via cos√¨…

…e intanto hanno presentato al MAX il flash player 10…

E voi cosa ne pensate?

ma vediamo di cosa si tratta…

“AS3 Data Structures For Game Developers” is a package containing common data structures useful for flash game programming and application development, mai descrizione fu pi√π sintetica e completa.

Il package contiene infatti diverse strutture di dati utili alla rappresentazione delle diverse situazioni riscontrabili sia nella programmazione di videogames che in quella delle applicazioni (anche nelle pi√π semplici).

Le strutture di dati di questo package suppliscono alla “semplicit√†” dei tipi di AS3, vengono implementate infatti strutture largamente diffuse e utilizzate dai pi√π come

• array multidimensionali (2 e 3 dimensioni)
• alberi e alberi binari
• liste concatenate
• code di priorit√†
• grafici (graph)

La documentazione del package √® ottima (http://www.polygonal.de/ds/api/) e non ci sono lacune di sorta o concetti lasciati all’interpretazione.

L’utilizzo di queste strutture di dati, o meglio, l’approccio a questo “nuovo” (che poi nuovo non √®, questo √® solo un porting in AS3 delle strutture pi√π utilizzate nella logica di programmazione) modo di archiviare i dati pu√≤ intimorire un newbie che sta solo cercando di fare la sua image gallery, ma una volta sperimentato questo package sar√† la base da cui partire, quindi

import flash.display.Sprite;
import de.polygonal.ds.*;

e buon coding!

Se la domanda che vi assilla è:
“Come si fa ad adattare un swf alle dimensioni della finestra del browser in modo che il risultato sia compatibile con i maggiori browser?” continuate pure a leggere

Partiamo dalle basi:

Dentro Flash:

Il flash player fornisce ad Actionscript una serie di API destinate all’interazione con lo stage del nostro swf fin dai tempi di flash mx.
Utilizzare questi appigli per determinare le dimensioni del nostro swf in esecuzione è piuttosto semplice e richiede davvero poche righe di codice:

Actionscript 2:

Stage.scaleMode = "noScale";
Stage.align = "TL";
var myListener:Object = new Object();
myListener.onResize = onScreenResize;
Stage.addListener(myListener);
 
function onScreenResize():Void
{
	trace(Stage.width);
	trace(Stage.height);
}

Actionscript 3:

import flash.display.StageAlign;
import flash.display.StageScaleMode;
import flash.events.*;
 
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT;
//assegno la funzione al gestore evento
stage.addEventListener(Event.RESIZE,onScreenResize);
//funzione per gestire il resize
//(e=null di default per evitare errori a runtime)
function onScreenResize(e:Event=null):void
{
	trace(stage.stageWidth);
	trace(stage.stageHeight);
}

La logica come potete vedere è la medesima:

• si blocca il ridimensionamento automatico dello stage (ossia lo “zoom” indesiderato)
• si allinea lo stage in una delle 9 posizioni possibili (da top-left a bottom-right)
• si va a gestire l’evento onResize dell’oggetto Stage in una funzione che esegue del codice a nostro uso e consumo

Cambia un pochino la sintassi, ma è solo questione di abitudine
Nel codice HTML e nel foglio di stile CSS:

ora possiamo passare alla parte xhtml e css, ossia quella parte che effettivamente va a gestire le dimensioni del player all’interno del browser.

Gli elementi della ricetta sono i seguenti:

• un div
• le direttive di stile per gli elementi del DOM “html”, “body” e “#nomediv”
• SWFObject a piacere per scrivere il nostro swf in #nomediv

Il nostro CSS apparirà simile a questo:

html {
	height: 100%;
	overflow: hidden;
}
#flashdiv {
	height: 100%;
}
body {
	height: 100%;
	margin: 0;
	padding: 0;
	background-color: #FFFFFF;
}

Conclusione e Sorgenti

Questo è solo uno dei vari modi in cui si può ottenere un swf grande quanto la finestra del browser e compatibile con la maggior parte dei browser in circolazione.

Ad ogni modo, nel file zip ci sono i vari casi elencati in questo mini “tutorial”,

stay tuned

La risposta è:
esiste un hack a riguardo fin dai tempi di flash mx.

Funziona così:
si maschera un movieclip direttamente da timeline, gli si assegna un nome istanza (ad esempio “myClip”).
Una volta mascherato si può procedere con la parte di script.

myClip.attachMovie("movieclipinlibreria","nome",myClip.getDepth()-1);

così facendo il nuovo clip inserito nello stage sarà mascherato esattamente come myClip.

Quanto vale per attachMovie vale anche per createEmptyMovieClip, baster√† mantenere il livello “myClip.getDepth()-1″ per rientrare nel caso.

Ma, se volessi mascherare direttamente il mio clip via actionscript senza doverlo mascherare da timeline?
Qui casca l’asino.
Con questo “hack” non si elude il metodo setmask della classe MovieClip, √® solo un modo per raggirarlo facendo leva sui livelli.
Un modo per ovviare al problema però esiste.
Nessuno ha detto che myClip debba essere visibile o non vuoto.
Creando in libreria un movieclip “mc_mascherato” nel quale posiziono una maschera e un “myClip” vuoto si potrebbe replicare la situazione all’infinito utilizzando come timeline di riferimento proprio quella di mc_mascherato anzich√® quella principale.
Le applicazioni di questo “hack” per il multi masking sono davvero tante, dalla image gallery all’intro animata, ad una semplice transizione.

Quasi dimenticavo, qui potete scaricarvi un esempio base.qui potete scaricarvi un esempio base

var myInstance:MyClass = new MyClass();
myInstance.myVar = 1;

la propriet√† “myVar” dell’istanza di classe myInstance assume il valore 1.

Ma forse non è così immediato capire cosa può nascondere la stessa riga di codice.

public var
E’ possibile che nell’ipotetica classe MyClass di cui myInstance √® un’istanza nella mia timeline ci sia effettivamente una variabile pubblica di nome “myVar”, di tipo Number (AS2\AS3) o int\uint (AS3) come mostrato dal codice qui sotto

class MyClass{
public var myVar:Number;
}

In questa situazione la variabile myVar √® accessibile, veloce ma accessibile…forse troppo accessibile.
Poniamo il caso che si verifichi la situazione per cui erroneamente venisse associato a myVar un valore di tipo errato…

var myInstance:MyClass = new MyClass();
 
myInstance.myVar = "ciao";

..si genererebbe un errore grossolano…
Ecco uno dei motivi principali per cui esistono i cosiddetti “getters” o “setters”.

getters setters
Sicuramente alla maggior parte di chi sta leggendo questo articolo su FlashFuck sarà capitato di incappare su del codice simile a questo

//Void AS2 | void AS3
private var _myVar:Number;
public function set myVar (n:Number):void{
_myVar = n;
}
public function get myVar ():Number{
return _myVar ;
}

Questo tipo di approccio permette di gestire con le due funzioni get e set il recupero e l’assegnazione di dati alla variabile privata _myVar.

In termini di utilizzo non cambia nulla, si potrà continuare ad usare la notazione

var myInstance:MyClass = new MyClass();
myInstance.myVar = 1;

per assegnare il valore alla variabile.. (solo che in questo caso il valore viene assegnato alla variabile privata _myVar, mentre myVar è solo il nome del getter\setter)

In termini di controllo del codice l’utilizzo di get e set √® notevolmente migliore rispetto all’utilizzo di una variabile pubblica,
tuttavia in termini di prestazioni una variabile pubblica √® notevolmente pi√π veloce di una funzione (non dimentichiamo che get e set sono appunto delle funzioni, quindi richiedono l’allocazione di pi√π memoria).

Quindi, quando usare get e set al posto di una variabile pubblica?
La risposta √® presto detta anche se piuttosto banale: quando se ne richiede l’uso.

• se √® possibile che il codice generi degli errori dovuti all’assegnazione di valori ambigui ad una variabile…
• se √® necessario che all’assegnazione del valore venga eseguita qualche altra funzione…
• se √® necessario eseguire il dispatch di un evento…

potrebbe rendersi preferibile l’uso dei getter\setter piuttosto che utilizzare variabili pubbliche…

In un linguaggio Object Oriented il codice viene organizzato appunto in “oggetti”, ossia contenitori di funzionalit√† con metodi e propriet√† definite.

Ora, per comprendere meglio cosa significhi in AS3 questa affermazione procediamo ad esempi.

Immaginiamo un nostro “mondo” da codificare, un esempio potrebbero essere le persone…

Creiamo quindi una classe “Human” come segue:

public class Human
{
	public var sex :String;
	public var name : String;
	public var age : Number;
	public var height : Number;
	public var weight : Number;
 
	public function Human(strName:String, strSex:String)
	{ /* nascita + assegna nome + setta age=0 + assegna sesso (costruttore)*/ }
 
	public function compleanno() : void
	{ /* invecchia (age++) */  }
 
	public function morte() : void
	{ /* morte */  }
 
	public function respira() : void
	{ /* respira continuamente */ }
}

Extend
Nella classe “Human” abbiamo stabilito delle “propriet√†” e delle “funzionalit√†” che caratterizzano tutti gli esseri umani.
Ora cerchiamo di capire come lavorare la classe in termini di OOP e proviamo a capire il concetto di ereditarietà delle classi.

Creiamo 2 classi partendo da, o meglio estendendo Human:

public class Man extends Human
{
	public function Man(strName:String)
	{ super(strName,"M"); }
}
 
public class Woman extends Human
{
	public function Woman(strName:String)
	{ super(strName,"F"); }
 
	public function parto():void
	{ /* crea un nuovo human */ }
}

Le due classi Man e Woman ereditano dalla classe estesa Human tutte le sue funzionalit√† e propriet√† e ne possono aggiungere delle altre, ad esempio Woman ha a disposizione tutti i metodi di Human con l’aggiunta del metodo “parto”.

E’ possibile usare anche la keyword override per sovrascrivere uno stesso metodo in una classe estesa. Mi spiego meglio, se volessi modificare la frequenza di respirazione di un’istanza della classe “Man” dovrei ridichiarare all’interno della classe Man la funzione “respira” gi√† presente in Human, cos√¨ facendo Human manterr√† invariata la funzione respira e Man (e le sue eventuali sottoclassi) erediterebbero la funzione sovrascritta.

override public function respira() : void
{ /* cambia frequenza di respirazione */ }

Seguendo questa logica di programmazione la classe che ne estende un’altra √® a sua volta un membro della classe estesa. Questo significa che ad esempio ad una funzione che accetta come input un valore di tipo Human √® possibile passare un valore di tipo Man o Woman in quanto Man e Woman estendono Human e ne ereditano propriet√† e metodi.

Interface
Un’altra logica di programmazione per ottenere un simile risultato √® l’ottica delle interfacce.
Un’interfaccia √® una serie di regole alle quali le classi che la implementano si devono attenere.
Un’interfaccia non definisce del codice vero e proprio, definisce piuttosto i contenitori che dovranno essere riempiti dal codice.
Torniamo all’esempio della classe Human.
Se pensassimo alla classe Human di prima come interfaccia avremmo questo:

public interface IHuman
{
	function compleanno() : void
	function morte() : void
	function respira() : void
}

L’interfaccia IHuman (√® buona norma mettere una “I” davanti alle interfacce…non cambia nulla, ma almeno vi capite) comprende le definizioni dei metodi delle classi che andranno ad implementarla.

Ma come si implementa un’interfaccia?
Tornando all’esempio di prima:

public class Man implements IHuman
{
	private const sex :String = "M";
	private var age : Number;
 
	public function compleanno() : void
	{ /* invecchia (age++) */  }
 
	public function morte() : void
	{ /* morte */  }
 
	public function respira() : void
	{ /* respira continuamente */ }
}

“Man” implementa l’interfaccia IHuman, quindi se una funzione chiedesse in input un valore di tipo IHuman accetterebbe anche Man senza problemi.
Ma se creassimo un’altra classe “Woman” che implementi IHuman, che rapporto avrebbe questa con la classe Man?
Nel caso di extend le classi Man e Woman ereditavano gli stessi metodi e propriet√† dalla classe Human. Nel caso delle interfacce la logica cambia quasi radicalmente. Tutte le classi che implementano una stessa interfaccia devono soddisfare le dichiarazioni fatte nell’interfaccia stessa, devono quindi “riempire” con del codice i “contenitori” definiti nell’interfaccia, tuttavia il codice delle singole classi non √® in alcun modo legato n√® all’interfaccia n√® alle altre classi che la implementano. Questo significa che la funzione “morte” di Man pu√≤ fare cose completamente diverse dalla funzione con lo stesso nome presente in una classe “Woman” che sta implementando la stessa interfaccia.

Combinare Extend Class e Implement Interface
Non va dimenticato che una via non esclude l’altra. Si possono combinare le logiche di interfacce ed estensioni di classe per soddisfare le proprie esigenze.
Ad esempio potrebbe essere opportuno creare un’interfaccia Human implementata dalla classe Man a sua volta estesa dalla classe Boy.
Boy in questo caso avrebbe tutti i metodi presenti in IHuman ed erediterebbe tutte le propriet√† di Man, inoltre sarebbe membro sia dell’interfaccia IHuman che della classe Man e soddisferebbe entrambi i tipi richiesti da un’eventuale funzione.

Uno dei metodi utilizzati per il posizionamento di siti fortemente aggrappati alle tecnologie client √® creare delle “landing pages” che rimandino in qualche modo al sito flash \ ajax \ flex \ ecc.. ma il buon esito non √® certo assicurato, anzi.

Da come ho impostato l’inizio dell’articolo sembra quasi che voglia vendervi un rimedio miracoloso per il seo su siti “client”
invece no, tutto gratuito, ed oltre tutto open source! In Bulgaria c’√® un’aziendina, la “asual“, che si √® inventata l’ SWFAddress, ossia un sistema basato su javascript e fortemente legato a SWFObject che permette il deep linking con flash, ajax e le altre tecnologie lato client.

Come si usa e come è stato fatto
La logica √® quella dell’url rewriting e dei permalink, ma questi vengono creati runtime dagli script residenti sul client.

Le classi per Actionscript 2 e 3 di SWFAddress forniscono delle API al player per interagire con l’oggetto “asual” nella libreria javascript che si andr√† ad includere nella pagina.

Nel codice html della pagina baster√† includere SWFObject e SWFAddress (ricordarsi, prima uno e poi l’altro, altrimenti non funzia)

<script src="swfobject/swfobject.js" type="text/javascript"></script>
<script src="swfaddress/swfaddress.js" type="text/javascript"></script>

Nel codice actionscript bisognerà importare ed istanziare la classe SWFAddress e definire i pattern di navigazione desiderati.
In linea di massima ogni qual volta si “cambier√† sezione” del sito baster√† aggiungere alla funzione qualcosa tipo

SWFAddress.setValue('/nomesezione/');

e nella barra del browser cambier√† l’url.
Per quanto riguarda il processo inverso (ossia forzare una sezione del sito in flash partendo da un url digitato sulla barra del browser) invece √® necessario definire gli stessi pattern all’interno del metodo

SWFAddress.onChange

in modo che venga a crearsi una reciproca corrispondenza tra funzioni flash e url nel browser.

SWFAddress per flash √® basato su “ExternalInterface” disponibile dal flash player 8 (classe dedita all’interazione tra actionscript e javascript).
L’oggetto javascript asual dichiarato nella libreria di SWFAddress definisce varie funzioni che permettono di riscrivere secondo la sintassi desiderata l’url della pagina in permanenza partendo da un url dinamico, di decodificare un URL riscritto precedentemente e addirittura di inserire gli indirizzi codificati a runtime delle pagine nella history del browser.
Il tutto √® reso possibile dalla rivalutazione del token html “#”. Il cancelletto # indica le ancore all’interno di una pagina html, cliccando su un’ancora la pagina si “sposta” focalizzando sul punto visibile pi√π vicino all’ancora ma non viene ricaricata la pagina bench√® l’URL della pagina stessa venga riscritto.

IMHO
Il difetto maggiore di SWFAddress a mio avviso √® la mancanza di link effettivi. Questo “hack delle ancore” (passatemi il termine) non risolve il problema principale in materia SEO di piattaforme RIA come Flash: l’assoluta assenza di collegamenti. Sicuramente SWFAddress √® un passo da giganti per flash, il “novello” flex, e ajax, tanto che aziende affermate come 2advanced sfruttano questo tipo di hack per la navigazione del proprio sito, tuttavia ribadisco che la mancanza di link tra le pagine √® una forte limitazione in termini di ottimizzazione per i motori di ricerca.

Gestire l’onReleaseOutside in actionscript 3 √® per√≤ pi√π facile di quanto si possa credere.
Scaricatevi questo file >> onReleaseOutside actionscript 3

Dentro ci troverete due classi:
la classe interessante √® “Button.as”.

La classe Button estende la classe nativa di actionscript 3 “SimpleButton” e aggiunge semplicemente il gestore dell’evento release outside.

Con as3 √® possibile rilevare l’ onRelease e l’ onRollOut di un SimpleButton tramite i gestori di evento della classe MouseEvent.
Ma come √® possibile combinare questi due eventi per gestire l’ onReleaseOutside?
La logica è la seguente:

1. all’ onRollOut del mouse sul pulsante controlla se il mouse √® ancora premuto
2. se il mouse è ancora premuto aggiungi un event listener sul release del mouse rispetto allo stage

Niente di complesso… diamo un’occhiata al codice:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

//gestore del press
 
internal function onPress(e:MouseEvent):void
 
{
 
 trace("press");
 
}//gestore del release
 
internal function onRelease(e:MouseEvent):void
 
{
 
 trace("release");
 
}
 
//gestore del FAMIGERATO release outside
 
internal function onReleaseOutside(e:MouseEvent):void
 
{
 
 trace("release outside");
 
}
 
//gestore del rollout
 
internal function onRollOut(e:MouseEvent):void
 
{
 
 trace("rollout");
 
 if(e.buttonDown){
 
//QUI AGGIUNGO L'EVENTO PER GESTIRE IL RELEASE OUTSIDE
 
 	e.target.stage.addEventListener(MouseEvent.MOUSE_UP, onReleaseOutside);
 
 }
 
}
 
//gestore del rollover
 
internal function onRollOver(e:MouseEvent):void
 
{
 
 trace("rollover");
 
//al rollover del mouse sul pulsante elimino il releaseoutside
 
 e.target.stage.removeEventListener(MouseEvent.MOUSE_UP, onReleaseOutside);
 
}

Nel file zip allegato trovate il resto della classe Button e una classe flashfuckit (bel nome eh? ) per visualizzare l’esempio.