Romanian Flex User Group

Flexibilitate şi asincronicitatea sunt virtuţile pe care programarea orientată pe obiecte şi eveniment le accentuează. Limbajele în care se programează interfeţe grafice dau posibilitatea de a gestiona evenimentele, asemenea sistemelor de operare - programe dirijate de evenimente pe cel puţin două nivele. La cel mai de jos nivel, întreruperile se comportă ca nişte handlere de evenimente hardware, cu procesorul în rol de dispecer. Coordonarea proceselor se face transmiţând către procese utilizator date şi facilitând accesul la întreruperile software. În general, handlerele de eveniment sunt apelate ca răspuns la stimuli externi, spre exemplu mouse-ul sau tastatura. Tot handlerele de evenimente folosesc o coadă a evenimentelor folosind structuri de tipul primul intrat primul ieşit (FIFO) pentru a reţine evenimentele care nu au fost procesate.
Flex nu face excepţie de la regulile de bază ale programării orientate pe obiect şi eveniment, astfel că evenimentele reprezintă o parte esenţială a dezvoltării de aplicaţii. Modelul evenimentelor Flex este bazat pe DOM (Document Object Model) de nivel 3, prin care W3C defineşte o platformă generică şi un sistem de evenimente independent de limbaj ce permite adăugarea handlerelor de eveniment, descrie structura în model arborescent şi defineşte informaţiile contextuale pentru fiecare eveniment (detalii folosite în gestionarea evenimentului respectiv).
Componentele au definite evenimente native care pot fi generate şi totodată ascultă alte evenimente. Într-o aplicaţie Flex, evenimentele sunt gestionate cu ActionScript, scris bineînţeles în tag sau în clasele care sunt instanţiate. Toate controalele şi containerele Flex sunt subclase ale DisplayObject şi sunt dispuse într-o ierarhie de obiecte vizibile cunoscute ca display list. Această listă conţine toate elementele pe care playerul le va desena pe ecran - obiectele dispuse arborescent corespund nodurilor din structura DOM şi sunt parcurse de evenimente generate de player. Atunci când un eveniment este creat, există trei faze pe care Flex le foloseşte pentru a determina dacă există ascultători : faza de capturare, în care playerul verifică fiecare nod începând de la nodul rădăcină până la părintele direct al nodului ţintă pentru a vedea dacă este înregistrat un ascultător pentru a trata evenimentul ; faza ţintă, în care evenimentul este trimis nodului ţintă ; faza bulelor, în care playerul verifică în ordinea inversă fazei de capturare - începe de la părintele direct al nodului ţintă şi sfârşeste la nodul rădăcină, căutând ascultători.
Evenimentele se clasifică astfel: evenimente de sistem, care se propagă atunci când codul este executat şi evenimente propagate de utilizator - care apar în momentul în care utilizatorul interacţionează cu aplicaţia (butoane, elementele formelor, etc). Gestionarea evenimentelor de sistem presupune ascultarea evenimentelor la execuţia codului, fără a fi necesară aşteptarea interacţiunii utilizatorului cu aplicaţia. Trei dintre cele mai importante evenimente de sistem, moştenite de orice obiect care reprezintă o subclasă a UIObject sunt creationComplete, initialize şi show.
Să parcurgem următorul exemplu:

Exemplu se foloseşte de evenimentele de sistem creationComplete (atunci când un constructorul unui obiect, subclasă a lui UIObject, şi-a terminat execuţia şi acesta este "desenat" pe ecran) şi de initialize (momentul în care un obiect, subclasă a lui UIObject, şi-a terminat execuţia constructorului, dar obiectul nu este desenat pe ecran). Aceleaşi evenimente pot fi capturate şi pentru componenta Panel:

Exemplul se foloseşte de scrierea codului ActionScript în maniera numită inline, adică nu definim un handler de eveniment care să includă codul ActionScript întrucât operaţiunile pe care le facem sunt simple. În momentul execuţiei codului de mai sus, putem observa că ierarhia evenimentelor de sistem face în aşa fel încât evenimentele aplicaţiei sunt întotdeauna lansate ultimele - logica fiind simplă : aplicaţia este ultima care anunţă evenimentele de sistem, întrucât obiectele pe care le conţine trebuie să anunţe primele aceste evenimente, ele făcând parte din aplicaţie.
Din acest motiv, creationComplete şi initialize ale aplicaţiei, pot fi folosite pentru a întreprinde acţiuni cum ar fi cereri de date către server.
Să ne ocupăm şi de evenimentele care provin din acţiunile utilizatorului, handlerul de eveniment va fi scris în interiorul tag-ului întrucât

După cum se poate observa, fiecare dintre butoane are handler-ul lui de eveniment, care este chemat în momentul în care utilizatorul întreprinde acţiunea de a apăsa butonul stânga al mouse-ului deasupra butonului în cauză. Este de la sine înţeles că putem folosi un handler unificat, să zicem pentru toate butoanele dintr-un panel, iar în funcţie de identificarea acestora să tratăm evenimentele.
Clasa flash.events.Event conţine informaţii despre evenimentul apărut - de fiecare dată când un eveniment apare, clasa generează automat un obiect care conţine informaţii despre eveniment şi care poate fi folosit în handler. Handler-ul trebuie să aibă drept parametru un astfel de obiect făcând astfel posibil să accesăm proprietăţile în cadrul lui. Câteva dintre proprietăţile obiectelor eveniment sunt comune diverselor tipuri de evenimente, aşa cum unele proprietăţi sunt specifice respectivului eveniment.
Proprietăţile comune sunt: type de tip String - conţine numele evenimentului apărut ; target de tip Event - conţine instanţa componentei care a propagat evenimentul ; target.id de tip String - conţine numele instanţei (definit prin proprietatea id) şi care poate fi folosit atunci când definim un handler comun, aşa cum am menţionat anterior.
Parametrul handler-ului poate fi în general obiect al clasei flash.event.Event sau se poate folosi o subclasă specifică evenimentului respectiv, aşa cum sunt MouseEvent şi DataEvent. Reţineţi că pentru a putea folosi aceste subclase, este necesar să le importaţi înainte de folosire : import flash.events.MouseEvent; clasa flash.event.Event este implicit inclusă în aplicaţie, din acest motiv ea nu trebuie importată înainte de folosire.

Vom modifica exemplul de mai sus pentru a folosi cele prezentate, înlocuind eticheta myLabel cu o componentă TextArea (myTA) care să ne permită să vizualizăm detalii despre evenimentul apărut:

Aşa cum am menţionat anterior, putem folosi o subclasă a clasei Event, modificând codul handler-elor după cum urmează:

De această dată, am folosit clasa MouseEvent pentru că este strict specifică evenimentelor apărute ca urmare a interacţiunii utilizatorului prin intermediul mouse-ului. Tipurile stricte asigură programatorul că în momentul compilării, proprietăţile care nu fac parte din clasa respectivă vor atrage după sine un mesaj de eroare şi totodată, imbunătăţeşte performanţele aplicaţiei.

Următorul pas pe care îl vom face este acela de a crea un ascultător pentru un anumit eveniment, folosind direct limbajul ActionScript. Obiectelor li se pot "ataşa" ascultători de evenimente folosind metoda addEventListener() care face parte din clasa EventDispatcher. Înregistrarea unui handler pe această cale permite controlul avansat al gestiunii de evenimente, permiţând spre exemplu să gestionăm evenimente pentru mai multe componente (crescând flexibilitatea codului) sau să adăugăm mai mulţi ascultători aceleiaşi componente.
Sintaxa generală pentru a adăuga un ascultător este : numele_instanţei.addEventListener(tipEveniment:String, numeAscultător:Function, foloseşteFazaCapture:Boolean, prioritate:int, referinţăSlabă:Boolean) - în care parametrii sunt tipul evenimentului, numele funcţiei ascultător (chemată atunci când evenimentul pe care-l ascultăm apare), foloseşteFazaCapture arată dacă ascultătorul va intra în acţiune în faza de capturare (descrisă mai sus) sau în faza ţintă/bulelor. Valoarea implicită a acestui parametru este false indicând că ascultătorii funcţionează corect în fazele ţintă şi bulelor - montarea unui ascultător pentru faza de capturare fiind folositoare pentru evenimente de tip low-level, doar atunci când se defineşte o componentă ce gestionează astfel de evenimente.
Parametrul prioritate indică prioritatea pe care o are ascultătorul şi se foloseşte pentru cazul în care montăm mai mulţi ascultători pentru acelaşi eveniment, aceleiaşi componente - stabilind astfel ordinea în care ascultătorii sunt chemaţi în cazul apariţiei evenimentului în cauză. Valoarea implicită este 0. Parametrul referinţăSlabă stabileşte dacă ascultătorul va fi colectat de garbage-collector sau nu (referinţăSlabă, implicit false indică faptul că ascultătorul nu va fi colectat).

Despre garbage-collector, în câteva cuvinte : este acel proces responsabil pentru dealocărea memoriei utilizate de obiecte care nu mai sunt folosite de aplicaţie. Dacă celelalte obiecte active nu au referinţă spre un terţ obiect, acesta din urmă va fi considerat inactiv şi în consecinţă el va ajunge în garbage-collector. O explicaţie mai bună ar fi că atunci când lucrăm cu obiecte ce au tipuri care nu sunt primitive (altele decât Boolean, String, uint, int, Number) vom folosi întotdeauna referinţa către obiecte şi nu obiectele însele - astfel încât atunci când ştergem o "variabilă" de fapt ştergem referinţa către un obiect, nu obiectul în sine. Exemplu:

PLAIN TEXT

Actionscript:

1. // facem o referinţă a unui nou obiect
2. var referinta:Object = {proprietate:"o valoare"}
3. // copiem referinţa creată
4. var copieReferinta:Object = a;
5. // acum ştergem referinţa
6. delete(referinta);
7. // verificăm dacă obiectul este încă referinţă în copia referinţei
8. trace(copieReferinta.proprietate);

Aşa cum veţi observa, copia referinţei va întoarce valoarea proprietăţii ("o valoare"), ca dovadă a faptului că obiectul pe care prima referinţă îl indica nu a fost şters, chiar dacă referinţa a fost ştearsă. Acest obiect va ajunge în garbage-collector odată ce nu va mai exista nici o referinţă către el.
Este foarte important ca în faza de dezvoltare a unei aplicaţii, programatorul să definească obiectele cât mai inerte cu putinţă, întrucât nu există nici un control asupra garbage-collector-ului, fapt care atrage după sine comportamente nedorite ale aplicaţiei în momentul în care nu există nici o referinţă către un anume obiect. Mai multe informaţii despre strategii de gestiune a resurselor puteţi citi aici (articol în limba engleză).

Revenind la evenimente, să aplicăm ceea ce-am prezentat:

După cum se observă cu uşurinţă, prin folosirea metodei addEventListener() s-au separat complet partea VIEW de partea CONTROLLER ale aplicaţiei. Termenii VIEW şi CONTROLLER fac referire la modelul de dezvoltare (design-pattern) MVC : Model-View-Controller. În aplicaţii complexe care lucrează cu cantităţi apreciabile de date, este de preferat să separăm datele (model) de interfaţa cu utilizatorul (view) astfel încât schimbările aduse interfeţei să nu interfereze cu schimbările datelor, totodată reorganizarea datelor să nu afecteze interfaţa. MVC rezolvă această problemă prin separea accesului la date şi logistica organizării datelor de nivelul în care se prezintă datele utilizatorului şi interacţiunea pe care interfaţa trebuie să o asigure, legătura dintre acestea fiind ţinută printr-un intermediar : controller-ul.
Modul în care Flex gestionează modelele de date se bazează pe MVC.

În continuare, vom descrie o clasă ActionScript externă care defineşte metode ce pot funcţiona ca şi ascultători - chiar dacă clasele ActionScript nu se pot comporta ca ascultători, metodele pe care o clasă le defineşte pot fi folosite în acest scop. Este suficient să creăm o clasă simplă, cu un constructor vid dar care importă flash.events.Event şi defineşte metodele pe care le vom folosi pe post de ascultători.

Considerăm cunoscute toate noţiunile ce sunt necesare pentru declararea pachetului şi clasei în cauză (vezi tutorialul I). Folosindu-ne de codul de mai sus, vom crea aplicaţia bazată pe exemplul anterior:

Aşadar, avand metodaHandler() definită static aceasta poate fi invocată fără a instanţia clasa în ActionScript.

În etapa de dezvoltare a unei aplicaţii Flex, una dintre cele mai importante şi mai des utilizate tehnici este data binding – procesul prin care un obiect ce conţine date este „legat” de o componentă. În acest fel se asigură independenţa operaţiunilor cu date de reactualizarea informaţiilor afişate de componentă – concret, atunci când datele din obiectul legat se schimbă, componenta actualizează informaţiile pe care le afişează din acel obiect, lăsându-i programatorului libertatea de a se concentra exclusiv pe prelucrarea datelor. Data binding în Flex deţine puterea: pe lângă legături între obiecte simple, putem crea şi legături între funcţii şi expresii ActionScript – binding reprezentând „rigidizarea” elementelor „flexibile”.

 

În Flex sunt trei posibilităţi de a crea o astfel de legătură: utilizând acoladele {}, folosind tag-ul <mx:Binding> sau folosind ActionScript şi packet-ul BindingUtils. Nu folosim termenul metodă (în locul lui posibilitate) în mod intenţionat, deoarece prezentarea în contextul programării orientate pe obiecte ne obligă la acest lucru.

Cea mai simplă şi mai utilizată manieră, folosind parantezele acoladă ({}), permite legături rapide între proprietăţile obiectelor, spre exemplu :

<mx:Label id="myLabel" text="Hello World"/>

<mx:Label text="{myLabel.text}" />

După cum puteţi observa, componenta sursă trebuie să aibă o denumire (id=”myLabel”) pentru a-i putea accesa proprietăţile, în cazul nostru proprietatea text – pe care o legăm în componenta destinaţie. Ori de câte ori proprietatea text a componentei sursă myLabel se va schimba şi cea de-a doua componentă (destinaţie) va prelua în proprietatea ei (text) valoarea modificată.

A doua manieră, folosind tag-ul MXML <mx:Binding>, exprimă mult mai clar legătura descrisă mai sus, întrucât proprietăţile tag-ului fac referire directă şi în limbaj natural la sursă, respectiv destinaţie:

<mx:Label id="myLabel" text="Hello World"/>

<mx:Label id=”myLabelDest” text="{myLabel.text}" />

<mx:Binding source=" myLabel.text" destination=" myLabelDest.text"/>

De reţinut că această manieră obligă programatorul să denumească ambele componente pentru a le putea accesa. Ca o informaţie suplimentară, toate componentele sunt denumite automat de către compilator, în cazul în care programatorul a omis să-i atribuie un identificator (id).

Ultima dintre posibilităţi poate fi folosită în ActionScript, utilizând clasa mx.binding.utils.BindingUtils : BindingUtils.bindProperty(myLabel, "text", myLabelDest, "text");

Clasa foloseşte o metodă statică (bindProperty) pentru a crea legătura dintre proprietăţi implementate ca variabile sau o metodă specifică setter-getter-elor (bindSetter) dacă este vorba despre proprietăţi implemetate prin intermediul getter-setter. De reţinut : metodele statice acţionează la nivelul clasei în care este definită, pe când metodele în general acţionează la nivelul instanţei clasei.

 

Să pornim un nou proiect, în care să inserăm un ArrayCollection (care este în fapt, un array complex) :

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

<mx:ArrayCollection id="myAC">

<mx:source>

<mx:Object siteURL="http://www.adobe.com" siteNume="Adobe"/>

<mx:Object siteURL="http://www.google.com" siteNume="Google"/>

<mx:Object siteURL="http://www.yahoo.com" siteNume="Yahoo"/>

<mx:Object siteURL="http://flex.akademia.ro" siteNume="ROFUG"/>

<mx:Object siteURL="http://www.badu.ro" siteNume="Badu"/>

</mx:source>

</mx:ArrayCollection>

</mx:Application>

ArrayCollection-ul nostru conţine obiecte care au fiecare definite proprietăţile siteURL şi siteNume. Vom defini o legătură între ArrayCollection şi o etichetă care afişează numărul de elemente pe care le are acesta. Într-un panel, definim eticheta în cauză:

<mx:Panel title="Tutorial II – DataBinding" width="50%" height="50%">

<mx:Label text="Numărul de elemente definite : {myAC.length}" />

</mx:Panel>

Putem observa cu uşurinţă că pe lângă binding-ul definit de noi între proprietatea length a ArrayCollection-ului, eticheta conţine şi text – proprietatea text a etichetei este compusă din concatenarea rezultatului de binding cu o valoare statică, introdusă de noi, rezultatul rulării aplicaţiei fiind eticheta cu textul „Numărul de elemente definite : 5”.

În acelaşi proiect, vom defini o a doua legătură, utilizând maniera tag MXML : între o nouă etichetă şi primul element al ArrayCollection-ului.

Noua etichetă (definită în tag-ul panel-ului):

<mx:Label id="myLabelDest" text="test" />

şi legătura, definită în tag-ul aplicaţiei (dacă am defini-o în tag-ul panel-ului, ar rezulta eroare):

<mx:Binding source="myAC.getItemAt(0).siteURL" destination="myLabelDest.text"/>

Aşa cum puteţi găsi şi în documentaţie, metoda getItemAt întoarce elementul al cărui index este indicat drept parametru, în cazul nostru fiind vorba despre primul element (numărătoarea elementelor în array-uri începe de la 0). Binding-ul citeşte proprietatea siteURL a primului element al ArrayCollection-ului şi îl leagă de proprietatea text a etichetei nou definite – cu riscul de a repeta, modificarea proprietăţii siteURL a elementului în cauză, atrage după sine modificarea conţinutului proprietăţii text a etichetei.

 

Pentru a ne folosi şi de cea de a treia manieră de a crea legături, vom insera cod ActionScript în proiectul nostru, după cum urmează:

 

<mx:Script>

<![CDATA[

 

import mx.binding.utils.BindingUtils;

 

public function facLegatura ():void{

BindingUtils.bindProperty(my_TI, "text", myAC.getItemAt(0), "siteNume");

}

 

]]>

</mx:Script>

 

Bineînţeles, este necesar să adaugăm în cadrul Panel-ului şi următoarele tag-uri, la care codul ActionScript face referire:

 

<mx:TextInput id="my_TI" text=""/>

<mx:Button label="Legătură" click="facLegatura()" />

 

În linii mari, în momentul în care vom face click pe butonul cu eticheta „Legătură”, invocarea metodei facLegatura crează legătura dintre proprietatea siteNume a primului element al ArrayCollection-ului şi proprietatea text a noului TextInput definit. Puteţi observa că în maniera tag <mx:Binding> am făcut legătura accesând direct proprietatea primului element, pe când în cazul legăturii folosind ActionScript, am indicat sursa ca fiind primul element, indicând conform sintaxei, imediat după sursă proprietatea la care facem referire – siteNume.

 

În concluzie, puteţi observa cu uşurinţă că maniera de declarare folosind <mx:Binding> poate ajuta la separarea clară între interfaţă şi nivelul model (cel care se ocupă cu declararea şi procesarea datelor) şi poate crea legături între diverse surse şi aceeaşi destinaţie. Utilizarea clasei BindingUtils ajută la crearea şi gestionarea de legături, dar care poate fi aplicată oriunde într-un proiect complex.

Maniera pe care o veţi folosi va depinde întotdeauna de situaţie: reţineţi că atunci când urmăriţi obţinerea unui rezultat care întârzie să apară (spre exemplu, aveţi în aplicaţie o eroare pe care n-o puteţi depăşi uşor) puteţi schimba oricând maniera de realizare a legăturilor - data binding-ul a fost creat ca să vă ajute, nu să vă încurce.