Du er alle satt opp til å sende dine egne hendelser. Nå, hva skal du sende? Det finnes noen alternativer å vurdere:

Bare gjenbruke en hendelse objekt og hendelsestypen allerede gitt av Flash Player

Gjenbruk av en eksisterende hendelse objekt, men gir en tilpasset hendelsestype

Re-Dispatch en eksisterende hendelse

Opprett en egendefinert hendelse objekt

Push vs pull


Denne første alternativet vi har allerede sett på våre tidligere eksempler. Vi har behov for å sende en hendelse relatert til ferdigstillelse av noen prosess, og når det skjer Flash gir en hendelse type (KOMPLETT) knyttet til en hendelse objekt (Hendelse) som passer våre kriterier. Vi har ikke behov for å gi ytterligere data med arrangementet. Utsending en Event.COMPLETE arrangement er alt vi trenger


Vi vil utforske disse andre alternativer i de kommende trinnene


---

Trinn 7:.. Tilpassede Hendelsestyper


Som antydet på tilbake i "Dispatch" skritt, hendelsestyper er rett og slett String identifikatorer. De kan teknisk sett være noen streng du vil. Det er vanligvis tilstrekkelig til å gjøre det et enkelt ord (som "komplett" eller "klikk") eller svært kort setning (som "ioError" eller "keyFocusChange"); det bare må være unikt innenfor en gitt hendelse sentralen rike av tilgjengelige arrangementer.


I tillegg tilstelninger objekter (inkludert underklasser, som MouseEvent eller ProgressEvent) har egentlig ikke bryr seg hva hendelsestypen de får når instansiert. En EventDispatcher vil gjerne sende arrangementer av enhver type identifikator og i enhver klasse (så lenge det er hendelses klasse eller en underklasse).


Det endelige utfallet av dette er at du kan gjøre opp din egen hendelsestype
String, sende den, og sette opp lyttere med den, og alt vil bli bra. Dette er nyttig når du ønsker å sende en hendelse, men kan ikke nødvendigvis finne en god representasjon av arten av hendelsen i de innebygde klasser.


Som et eksempel, du kan ha en klasse som fungerer som koordinator for flere ting på en gang: laste noen XML, laste noen bilder basert på XML-data, og lage et oppsett basert på de belastede bildenes størrelser, klar for en innledende animasjon, på hvilket punkt du ønsker å sende en hendelse . Mens COMPLETE hendelse kan være egnet, kan du føle at en "klar" event innkapsler mer hensiktsmessig meningen.


Dette er så enkelt som å bestemme på String å bruke, og deretter bruke den. Bruk den både når du legger lyttere, og ved forsendelse av hendelsen. Hvis String kamper, vil hendelsen komme til der det er behov for å gå. For eksempel er dette en delvis oversikt over en hypotetisk Klasse:
public class MyClass strekker EventDispatcher {//... En haug med andre ting som ikke er vist. privat funksjon determineReadiness (): void {if (everythingIsReady) {dispatchEvent (ny hendelse ("klar")); }}}

Og kode fra et annet sted i samme program:
Var myObject: MyClass = nye MyClass (); myObject.addEventListener ("ready", onObjectReady), funksjon onObjectReady (e: Hendelses): void {//Gjør ting nå som det er klart.}

Og det ville fungere.


Men er det verdt å nevne mens vi her at å skrive i matchende Strings over alt er ikke en god praksis. Muligheten for feil er høy, og arrangementet systemet vil ikke fortelle deg at du har skrevet "raedy" i stedet for "klar". Det faktum at arrangementet Systemet er fleksibelt og enkelt å bruke - bare gi det noen gamle String for hendelsen type - er også noe av en svakhet. Din sentralen vil gjerne imot en lytter for noe
, enda en "raedy" event. Det gjør egentlig ikke forsone hva hendelsen typer er registrert mot hva hendelsen typene er faktisk sendes.


For å unngå dette, er det standard tilnærming å bare sette String du vil bruke i en statisk konstant et sted, og deretter aldri bruke det bokstave String igjen
. Bare bruker den konstant. Selvfølgelig, er muligheten for skrivefeil bare en stor som før, men hvis du bruker en KLAR konstant og ikke "klar" bokstavelig String, vil en feilstaver utløse en kompilator advarsel. Du vil være i stand til å korrigere feilen raskt og enkelt. En feilstaver med den bokstave Strings gir ingen kompilator feil, heller ikke produsere det en kjøretidsfeil. Det eneste som skjer er at SWF ser ikke ut til å fungere skikkelig, fordi hendelsen lytteren ikke utløses.


Med dette i tankene, er det mest vanlig å lagre disse konstantene på den relaterte arrangement klassen. Vi får til tilpassede tilstelninger klasser i bare noen få trinn. Men i situasjonen skissert i denne
trinn (dvs. vi gjenbruk av en hendelse klasse, men ikke en hendelse type), finner jeg det mer praktisk å bare lagre som konstant på sentralen klasse. Så vi kan velge å gjøre dette:
public class MyClass strekker EventDispatcher {public static konst KLAR: String = "klar"; //Etc. privat funksjon determineReadiness (): void {if (everythingIsReady) {dispatchEvent (ny hendelse (KLAR)); }}}

Og:
Var myObject: MyClass = new MyClass (); myObject.addEventListener (KLAR, onObjectReady), funksjon onObjectReady (e: Hendelses):. Void {//Gjør ting nå som det er klart}

Dette gir oss trygghet til å lagre hendelsestyper i konstanter, mens ikke tvinge bryet med å lage en hel hendelse klasse som vi ikke trenger. Jeg må understreke at dette er et stilistisk valg, og du kan gjerne bruke denne teknikken eller ikke. Jeg følte det garantert forklaring, slik at du kan lage din egen avgjørelse. I begge hensyn, bør du definitivt lagre dine tilpassede hendelsestypen Strings i statiske konstanter. Hvor de statiske konstanter er definert er opp til deg


---

Trinn 8:. Re-Dispatching Hendelser


Det er flere ganger når en klasse (la oss kalle det ClassX) eier en eiendom som er skrevet som en annen klasse (vi kaller at en stilig), mens selv å være eid av en tredje klasse (hva med ClassZ?). ClassX lytter etter en hendelse fra stilig, men ikke bare ønsker vi å ha ClassX svare på arrangementet, ønsker vi også å tenke på at ClassX bør sende en lignende (eller samme) hendelse slik at ClassZ kan også ta ytterligere tiltak.


Som et mer konkret eksempel, har vi en klasse (dette vil være "ClassX") som er en slags data manager. Den laster et XML-dokument, analyserer den, og lagrer data fra XML i egne eiendommer. Så det har en URLLoader objekt (dette ville være "classy"), og lytter etter den Event.COMPLETE arrangement for når XML-dokumentet er lastet.


Da har vi et hoveddokument klasse som eier data manager ( dokumentet klassen er "ClassZ"). Det er å koordinere data lasting med andre UI elementer, slik at den ønsker å vite når dataene er lastet og klar, slik at den kan fortsette å lage og layout UI elementer basert på dataene.
Public class DataManager strekker EventDispatcher {private Var _xmlLoader : URLLoader; offentlig funksjon DataManager () {_xmlLoader = new URLLoader (ny URLRequest ("some.xml")); _xmlLoader.addEventListener (Event.COMPLETE, onLoadComplete); } //... En haug med andre ting privat funksjon onLoadComplete (e: Hendelses): void {//... XML parsing //Med XML analysert, vil vi gjerne sende en annen hendelse for å signal blir gjort. }}

Vi kan gjøre dette:
dispatchEvent (ny hendelse (Event.COMPLETE));

Men vi kan også gjøre dette:
dispatchEvent (e);

Her er vi rett og slett re- ekspedere den eksisterende hendelse. Ikke bare har vi gjenbruke hendelsestype og hendelsesklassen, men vi er faktisk gjenbruke hele arrangementet protestere
som det ble vedtatt i vår egen lytteren.


Det er ikke rakettforskning, men det er en hendig liten teknikk som er overraskende ikke så opplagt.


"Men vent," du må tenke, "hvis vi redispatched en hendelse som stammer fra URLLoader objekt, ville ikke målet for hendelsen fortsatt være _xmlLoader når det blir ut igjen til dokumentet klassen? " Og du vil ha en veldig god og gjennomtenkt poeng, og jeg vil være stolt av deg for å tenke så flittig, men du ville være galt.


En ganske magisk ting skjer når redispatching hendelser. Målet eiendom blir satt til den aktuelle sentralen. Du kan finne en fungerende eksempel på koden i dette trinnet i nedlastingspakken, rett redispatch.


Egentlig er det ikke alle som magisk. Når du ringer dispatchEvent, hvis hendelses objekt som er vedtatt i allerede har satt som mål, deretter klone metoden kalles på Event, skaper en identisk, men diskret kopi av den opprinnelige Event, med unntak av verdien i mål.


---

Trinn 9: Custom Hendelses Objekter


Alt nevnt så langt er noe du vil ønske å vite. Men det vil komme et punkt når den beste tingen å gjøre er å sende dine egne arrangement. Ikke bare en tilpasset hendelsestype, men en hel tilpasset hendelsesklassen.


Prosessen for å gjøre dette er grei, du trenger bare å følge noen få trinn. Vi vil diskutere disse etter hvert. Legg merke til at mye av dette er platt kode, og du kan enkelt lage en mal for en hendelse underklasse og endre bare et par viktige brikker og være av og kjører. De generelle trinn, i forkortet-som-hvis-du-visste-hva-jeg-var-snakker-om form:



Subclass Hendelses

Ring super (...)

typer Butikk hendelses i offentlige statiske konstanter

Erklærer private eiendommer for å holde egendefinerte data

Opprett offentlige getters å gi skrivebeskyttet tilgang til den tilpassede info

(valgfritt) Styr klonen metoden

(valgfritt) Styr toString metode


For å forklare disse prosessen dypere, vil vi få en start på vår slider prosjektet og lag den SliderEvent vi trenger for det. Så vi trenger for å starte prosjektet vårt før vi kan skrive noen kode, så en rask avledning i neste trinn, så får vi begynne å skrive en egendefinert hendelse klasse


---

Trinn 10:. Lag prosjektstrukturen


Vi vil holde ting ganske enkelt for dette, men vi vil likevel lage pakker for våre klasser.


Start med å lage en mappe for hele prosjektet. Gruven vil bli kalt slider


Inne i dette, lage en com-mappen, og på innsiden av det, en activetuts mappe


Nå opprette to mapper på innsiden av activetuts:.. Hendelser og ui. Den endelige mappestrukturen skal se omtrent slik ut this:


slider

com

activetuts

events

slider









Now tilbake til vårt arrangement klasse


---

Trinn 11:. Subclass Hendelses


Først oppretter du en ny tekstfil i glidebryteren /com /activetuts /hendelser mappe, og kaller det SliderEvent.as. Vi vil pop i standardteksten for alle klasser først:
pakke com.activetuts.events {public class SliderEvent {offentlig funksjon SliderEvent () {}}}

Det bør være noe overraskende her, og hvis du har Action maler for en teksteditor, bør du ikke engang å skrive så mye i.


Nå vil vi endre dette, slik at den strekker seg Event.
pakke com.activetuts.events {import flash. events.Event; public class SliderEvent strekker Hendelses {offentlig funksjon SliderEvent () {}}}

Som du ser, vi bare importere hendelsesklassen, legge strekker Hendelses til klassen definisjonen


---

Trinn 12:. Ring super


Vår super kan håndtere mye for oss, og det er flott, men vi må sørge for at vi initialsuper skikkelig når vi initial vår underklasse. Vi må sette opp konstruktøren med argumenter matchende de som finnes på Event konstruktør, og passerer dem sammen med en oppfordring til super
pakke com.activetuts.events {import flash.events.Event.; public class SliderEvent strekker Hendelses {offentlig funksjon SliderEvent (type: String, bobler: Boolean = false, cancelable: boolske = true) {super (type, bobler, kansellerbare); }}}

Dette er, så langt, grunnleggende subclassing teknikker. Faktisk, avhengig av redaktørens dyktighet med maler, kan du være i stand til å spesifisere en super klasse når du oppretter filen og har alt dette gjort for deg. Flash Builder, for eksempel, er i stand til å gjøre dette


---

Trinn 13:. Oppbevares Hendelsestyper i Public Static konstanter


Antagelig vil det være en eller flere typer arrangement i forbindelse med denne hendelsen klassen. Akkurat som COMPLETE hendelsen er knyttet til hendelsesklassen, og CLICK selv med MouseEvent klassen, vil vår custom event klasse sannsynlig har typer tilpasset hendelses.


Dette er så enkelt som å skrive en linje som følgende for hvert arrangement typen du ønsker å legge til:
public static konst EVENT_TYPE: String = "Event";

La oss gjøre det nå for SliderEvent klasse
pakke com.activetuts.events {import flash.events.. Hendelse; public class SliderEvent strekker Hendelses {public static konst CHANGE: String = "sliderChange"; offentlig funksjon SliderEvent (type: String, bobler: Boolean = false, cancelable: Boolean = true) {super (type, bobler, cancelable); }}}

Vi kan i teorien bruke vår klasse nå. Vi kan bruke SliderEvent i dispatchEvent, og lytte etter og opprette hendelser med SliderEvent.CHANGE hendelsestype.


Men vi vil ikke stoppe der. Det er mer å vurdere. Men før vi gjør mer kode-skriving, må vi ta en annen avstikker inn teori


---

Trinn 14:. Push vs Pull


Når en hendelse er sendt, noen ganger er det nok å bare vite at hendelsen har inntruffet. For eksempel, de fleste ganger at du er interessert i Event.ENTER_FRAME, Event.COMPLETE, eller TimeEvent.TIMER hendelser, har du sannsynligvis bare ønsker å vite at hendelsen skjedde. Det er andre tider, men når du sannsynligvis vil vite mer. Når du lytter til MouseEvent.CLICK, er du kanskje interessert i om Shift-tasten ble holdt nede, eller koordinatene til musen på tidspunktet for klikket. Hvis du lytter til ProgressEvent.PROGRESS, vil du mest sannsynlig ønsker å vite den faktiske fremdriften av lasten; det vil si hvor mange byte har lastet og hvor mange det er å laste totalt.


Forskjellen mellom disse to metoder er kjent som "push" og "pull". Disse begrepene refererer til hvordan arrangementet lytteren
henter data relatert til hendelsen. Hvis dataene er "presset" så er det data som er lagret i hendelsen objekt, og for å få data lytteren trenger bare å bruke egenskapene på arrangementet objektet. Dersom data skal "trukket", men generelt arrangementet objektet har svært lite informasjon som finnes - bare nødvendigheter: type, målet, etc. Dette målet, men er uunnværlig, da det gir tilgang til hendelsen < em> sentralen
til hendelsen lytteren
at lytteren
å få dataene den trenger fra sentralen
.


I andre ord, kan du enten trykke på en haug med data til lytteren inne arrangementet objektet, eller du kan kreve lytteren til å trekke data ut av sentralen etter behov.


De fordeler og ulemper med hver teknikk er noe balansert, etter min mening, og den banen du velger for ditt arrangement objekt avhenger av situasjonen på hånden, og ikke litt på personlige preferanser


Exhibit A:.
Pros Anmeldelser Cons
Push

Data er lett tilgjengelig i tilfelle objektet

Du kan skyve data som er unødvendige. Oppblåsthet arrangementet objektet med en haug med data som brukes sjelden kan føre til minne og /eller ytelsesproblemer.
Trekk

Veldig lett å skrive. Du trenger sannsynligvis ikke en egendefinert hendelse klasse til å utføre en pull arrangement.


1. Veldig enkel å bruke. Hvis det er bare en hendelse klasse, er den eneste obligatoriske argument hendelsestype.
   
2. Hvis data ofte trukket ut av sentralen er dyrt å beregne og tilbake, du kan ta en hit på ytelse ved å kreve at sentralen kontinuerlig dele ut denne informasjonen.
   
   Noen data kan være vanskelig å trekke, f.eks den KeyboardEvent har en nøkkelkode eiendom på detaljer nøkkelen som ble presset til å utløse hendelsen
   

   Dette kan være en god diskusjon for kommentarer.; Jeg er sikker på at mange av dere som leser har lidenskapelige følelser om hvilken metode er bedre. Personlig prøver jeg å finne den metoden som fungerer best for situasjonen.
   

   Når det er sagt, er det verdt å merke seg at til dette punktet vår SliderEvent klassen er heller "pull-ish." For å få til illustrasjon, og fordi det ikke er en forferdelig idé (selv om jeg kom opp med flere av dem), vil vi fortsette med å gjøre dette til en begivenhet som skyver data sammen med det; nemlig verdien av glideren da det ble endret
   

   ---

   Trinn 15:. Erklærer private eiendommer til Hold Custom data
   

   For å gjennomføre en push hendelse, må vi ha et sted å lagre dataene blir presset. Vi vil legge til en privat eiendom for det formålet.
   

   Du bør likevel ha SliderEvent åpen (hvis ikke ... hva venter du på?). Legg den markerte linjen:
   pakke com.activetuts.events {import flash.events.Event; public class SliderEvent strekker Hendelses {public static konst CHANGE: String = "sliderChange"; private Var _sliderValue: Number; offentlig funksjon SliderEvent (type: String, bobler: Boolean = false, cancelable: Boolean = true) {super (type, bobler, cancelable); }}}

   Neste vi vil endre konstruktøren slik at vi kan godta en verdi parameter, og sette den private eiendom med at:
   offentlig funksjon SliderEvent (type: String, sliderValue: Number, bobler: Boolean = false , cancelable: Boolean = true) {_sliderValue = sliderValue; super (type, bobler, kansellerbare);}

   På denne måten kan vi enkelt lage SliderEvent og sette opp sine push-data i én linje
   

   Hvorfor bruke private eiendommer.? I dette tilfellet, vi ønsker å beskytte dataene. Etter min mening data relatert til en hendelse er uforanderlig, så lenge det er forbundet med arrangementet. Å kunne endre data til en hendelse objekt er som redigerer en historie lærebok. For å være rettferdig, dette er min mening og standard som brukes av Adobe med sine innebygde klasser er å bruke skrivbare egenskaper (teknisk de bruker private eiendommer og offentlige kundeskaffere og settere, men sluttresultatet er det samme).
   < hr> Trinn 16: Lag Offentlige Getters for Custom data
   

   Så neste skritt vil være å sørge for at vi får tilgang til dataene blir presset. En privat egenskap i seg selv ikke er nyttig for dette formål. Derfor trenger vi å skrive en offentlig getter for _sliderValue eiendommen. Vi vil velge å ikke skrive en setter, slik at eiendommen blir skrivebeskyttet (som diskutert i det siste trinnet)
   

   Legg denne metoden til klassen.
   Offentlig funksjon får sliderValue (): Antall {return _sliderValue;}

   Dette legger et getter slik at vi kan få tilgang til sliderValue i eiendom-aktig måte. Jeg velger ikke å legge den matchende setter. Du kan legge til en hvis du føler det er verdt
   

   ---

   Trinn 17:. Styr klone metoden
   

   Jeg nevnte klone metoden en liten stund siden. Du vil sannsynligvis ikke kalle klone mye selv, men det er ikke en dårlig idé å overstyre klone metode, slik at den tilpassede arrangement spiller pent med arrangementet system
   

   Legg denne metoden til klassen din.
   Overstyring offentlig funksjon klone (): Hendelses {return new SliderEvent (type, sliderValue, bobler, cancelable);}

   Først merke signaturen til denne metoden. Vi bruker overstyring fordi denne metoden er deklarert i Event, og vi arve den. Den returnerer også et objekt av typen Event. Sørg for, når du skriver din klone overstyring, at du setter riktig returtype i. Det er lett å glemme og sette den type klassen der, men det vil føre til en inkompatibel overstyring feil, fordi avkastnings typer trenger å matche.
   

   Alt vi egentlig gjør i kjøtt av arrangementet er å skape en ny SliderEvent og bestått i de samme verdiene som vi har lagret i den aktuelle hendelsen objektet. Dette skaper en identisk, men diskret kopi:.. En klone
   

   Dette er et valgfritt trinn, men det er en rask seier og sikrer at den tilpassede arrangement spiller godt sammen med resten av arrangementet system
   

   ---

   Trinn 18: Overstyr toString metode
   

   En siste ting, og igjen dette er valgfritt. Men det er også svært nyttig som en debug verktøy, slik det vanligvis betaler seg selv i løpet av noen få bruker.
   

   I tilfelle du ikke har fått beskjed ennå, toString metode eksisterer på alle objekter (det er erklært og definert i objekt, über-klassen som alle andre klasser arver, enten du liker det eller ikke). Det kan kalles eksplisitt, men hendig ting er at det blir kalt automatisk i en rekke saker. For eksempel, når du passerer objektet til trace funksjon, enhver gjenstand som ikke allerede er en String vil ha toString kalt på den for å sørge for at det er formatert pent for utdatapanelet. Det enda blir kalt når du arbeider med objekter sammen med Strings, som med sammensetning. For eksempel, hvis du skriver dette:
   «Svaret på livet, universet og alt er" + 42;

   Action er smart nok til å konvertere 42 inn i en String representasjon av Number før concatenating String. Prøver å legge en streng og et nummer er dårlige nyheter, men å konvertere et nummer til en streng og deretter sette sammen den med en annen String er bare fint.
   

   Så når du skriver dine egne klasser, kan du gi en toString metode , som tar ingen argumenter og returnerer en String, og returnere hva String du vil.
   

   Når det gjelder tilstelninger objekter, Adobe gir fully en formatToString metode for å hjelpe alle arrangementer ligne når spores. Vi skal bruke det i metoden vi er i ferd med å legge til klassen vår:
   styre offentlig funksjon toString (): String {return formatToString ("SliderValue", "type", "sliderValue");}

   Først oppmerksom metoden signatur. Igjen, det er en overstyring, slik at vi har dette søkeordet. Det er offentlig, det tar ingen parametere, og returnerer en String (som burde være opplagt).
   

   Neste, merk én linje i metoden kroppen. Vi kaller formatToString, som er definert i Event, så det er enkelt å bruke. Det første argumentet vi passere til det er den String navnet på klassen. Etter at argumentene er åpent. Du kan passere i ett, 15, eller ingen. Vi kjører i to. Uansett hvor mange du passerer i, de skal alle være strenger, og de bør matche egenskapsnavnene på din klasse. "type" er definert av Event, men "sliderValue" er definert av vår egen klasse. Uansett hva som skjer er at navnet på eiendommen er skrevet ut, etterfulgt av et likhetstegn, som etterfølges av den faktiske verdien av denne eiendommen. Kort sagt, vil det ende opp som ser slik ut: product: [language = "text"] [SliderValue type = "sliderChange" sliderValue = 0,34146341463414637]

   Dette er helt ikke-fungerende, men veldig nyttig. Det kan gi et raskt innblikk i tilfelle når ting ikke fungerer slik du tror de burde
   

   ---

   Trinn 19:. Bygge Slider
   

   På dette punktet, vi har vært gjennom nøkkelbegrep i denne opplæringen: å skrive en egendefinert hendelse klasse. Men vi virkelig trenger å sette den på prøve. Vi skal tilbringe resten av vår tid å bygge den enkle skyve søknaden som ble forhåndsvist i begynnelsen av opplæringen
   

   Vi har allerede et prosjekt mappestruktur.; Vi trenger bare noen flere filer. Vi begynner med den FLA filen.
   

   Opprett en ny Flash-fil (Actionscript 3.0, selvfølgelig), og lagre det som ActiveSlider.fla i roten av prosjektmappen. Jeg kommer til å anta at du ikke trenger steg-for-steg detaljer om hvordan å sette denne enkle FLA sammen, og i stedet vil jeg legge ut de viktigste elementene. Du kan bruke FLA fil funnet i starten mappe med nedlastingspakken for referanse, også, eller bare kopiere det FLA til prosjektmappen og kaller dette trinnet gjort.
   

   Det er tre hoved objekter på stadium.
   

   
   Den glidespor. Dette er en lang, smal stripe som viser til hvor glideren kan flyttes. Glideren beveger seg "i" sporet.
   
   1. Må være et Movie Clip
      
      For enklest matte, bør ha kunstverk arrangert slik at registreringspunktet er øverst i venstre hjørne
      < li> Name it track_mc
      
      Sted i øvre sentrum; import flash.events. *; import flash.events. *; import flash.events. *; import flash.events. *; import flash.events. *;
      
      
      
      Previous:Fantastiske premier på spill i Tuts + Survey!
      Next Page:AS3 101: OOP Introduksjon - Basix