labs.prasa.sk

Google AuthSub a Picasa Web Data API crossdomain.xml

Je viac ako rok potom, kedy do gdata-issues pribudla žiadosť o pridanie crossdomain.xml pre Google Accounts (http://code.google.com/p/gdata-issues/issues/detail?id=406).

Od apríla tohto roku som mal možnosť ako člen http://groups.google.com/group/authsub-trusted-testers skupiny testovať a ladiť AuthSub autentifikáciu cez Flash Player. Mesiac sme komunikovali, testovali a reportovali problémy. Výsledkom je crossdomain.xml pre Google Accounts http://accounts.googleapis.com/crossdomain.xml

Juch. Zhrniem výsledky do krátkej ukážky Google Accounts AuthSub autentifikácie:

1. Načítať crossdomain.xml

Explicitne musíme povoliť odosielanie requestov na Google Accounts API Security.loadPolicyFile("https://accounts.googleapis.com/crossdomain.xml");

2. Prejsť na stránku “Žiadosť o prístup”

Nasleduje autentifikácia cez prehliadač na strane Google

// create a request to get the token
var variables : URLVariables = new URLVariables();
    variables["scope"] = "http://photos.googleapis.com/data";
    variables["session"] = "1";
    variables["secure"] = "0";
    variables["hd"] = "default";
    variables["next"] = "http://www.prasa.sk/authsub/index.html";

var request: URLRequest = new URLRequest("https://www.google.com/accounts/AuthSubRequest");
    request.data =  variables;

navigateToURL(request, "_top");

3. Google vráti prehliadač späť …

… na našu aplikáciu spolu aj s tokenom. Token sa dá z adresy načítať napríklad cez ExternalInterface.call() http://www.prasa.sk/authsub/index.html?token=CK-...-ezGBg

4. Načítať long-lived session token

Nasledovným volaním vymeníme single-use token za long-lived session token, ktorý možeme použiť na authorizovaný request služieb Google (napr. Picasa Web Data API):

private function getAuthSubSessionToken() : void
{
    // create request to get the session token
    var request : URLRequest = new URLRequest();
        request.url = "https://accounts.googleapis.com/accounts/AuthSubSessionToken";
        request.method = URLRequestMethod.POST;            // we need to use POST method because the headers are NOT sent
        request.data = new URLVariables("test=variable");    // some test varialbe to get the headers working
        // create request headers
        request.requestHeaders.push(new URLRequestHeader("Authorization","AuthSub token=\""+token+"\""));
        request.requestHeaders.push(new URLRequestHeader("Content-type","application/x-www-form-urlencoded"));

    var loader : URLLoader = new URLLoader();
        loader.addEventListener(Event.COMPLETE, loader_result);

    try
    {
        loader.load(request);
    } 
    catch(e : Error)
    {
        throw new Error(e);
    }
}

public function loader_result(evt : Event) : void
{
    var loader : URLLoader = URLLoader(evt.target);
    sessionToken = new URLVariables(loader.data).Token; // store our session token in a instance variable
}

Novinkou v crossdomain.xml aktualizáciách od Google je aj Picasa Web Data API. Do crossdomain.xml súboru pribudla Authorization hlavička a keďže vlastné hlavičky sa nedajú z Flash Player-a poslať ináč ako POST requestom, pribudla aj X-HTTP-Method-Override hlavička pre simuláciu napr. GET requestov. S takýmto crossdomain.xml súborom a long-lived session tokenom už konečne vieme načítať napríklad zoznam privátnych Picasa Web albumov.

1. Explicitne načítať crossdomain.xml

Explicitne musíme povoliť odosielanie requestov na Picasa Web Data API Security.loadPolicyFile("http://photos.googleapis.com/data/crossdomain.xml");

2. Odoslať žiadosť …

… spolu s autorizačným tokenom v hlavičke

private function getPrivateAlbums() : void
{
    // create request to get the session token
    var request : URLRequest = new URLRequest();
        request.url = "http://photos.googleapis.com/data/feed/api/user/default?access=private";
        request.method = URLRequestMethod.POST;            // we need to use POST method because the headers are NOT sent
        request.data = new URLVariables("test=variable");    // some test varialbe to get the headers working
        // create request headers
        request.requestHeaders.push(new URLRequestHeader("Authorization","AuthSub token=\"" + sessionToken + "\""));
        request.requestHeaders.push(new URLRequestHeader("X-HTTP-Method-Override", "GET"));
        request.requestHeaders.push(new URLRequestHeader("Content-type","application/atom+xml"));

    var loader : URLLoader = new URLLoader();
        loader.addEventListener(Event.COMPLETE, privateLoader_result);

    try
    {
        loader.load(request);
    } 
    catch(e : Error)
    {
        throw new Error(e);
    }
}

public function privateLoader_result(evt : Event) : void
{
    var atom_ns : Namespace = new Namespace("http://www.w3.org/2005/Atom");
    var loader : URLLoader = URLLoader(evt.target); 
    var data : XML = new XML(loader.data);

    for each(var album : XML in data.atom_ns::entry)
    {
        trace(album.atom_ns::title.text(), album.atom_ns::summary.text());
    }        
}

Funkčnú aplikáciu hladajte na http://www.prasa.sk/authsub (view-source enabled).

Po dlhom čase sme sa nakoniec dočkali. Som zvedavý na nové aplikácie a možnosti. Má niekto chuť napísať gdata client library v as3?

Začíname s Picasa Web API

Nedávno sa mi prisnilo silné slovné spojenie skutková podstata. Rozmýšľajúc nad jeho významom mi napadol tento blog. Jeden celý dlhý rok bol naložený vo formaldehyde. Počas hybernácie blogu som pozabudol nato, aký bol dôvod jeho vzniku. A práve skutková podstata mi pripomenula, že Picasa Web Albums a súvisiaca Flash/Flex knižnica bola tá pohnútka. Aby som začal túto skutkovú podstatu napĺňať, skúsim spraviť prvý krok a rozbehnúť sa niekam. Kam dobehneme sám ešte neviem. Dúfam len, že to nebude šprint na 100 metrov, ale poriadny maratón.

Čo je to Picasa Web Albums Data API?

Pod týmto označením sa skrýva rozhranie, ktoré umožňuje integrovať službu Picasa Web Albums (ďalej len PWA) do vašich webov a aplikácií. Rozhranie umožňuje vytvárať albumy, zasielať a sťahovať obrázky, komentáre k obrázkom a tisíc ďalších vecí.

Niektoré z mála vecí, ktoré využívajú PWA Data API:

• Aplikácie na jednoduché uploadovanie obrázkov zo zariadení, desktopových aplikácií a ostatných webových služieb
• Mobilný klienti na prezeranie a uploadovanie obrázkov do PWA
• Integrácia PWA s blogovacími nástrojmi k jednoduchému zdielaniu obrázkov na vašich blogoch
• Digitálne foto rámiky
• …

Pre stručný prehľad je k dispozícii video:

Domovská stránka PWA Data API: http://code.google.com/apis/picasaweb/

A čo je to Picasa Flash API?

Pod týmto názvom sa skrýva klientské rozhranie, ktoré umožňuje čo najjednoduchšie pristupovať priamo k PWA pomocou Flash Player-a. Picasa Flash API (ďalej len PFA) je read-only Actionscript 3 rozhranie k Picasa Web Albums. Umožňuje listovať v používateľských albumoch, obrázkoch, komentároch, tagoch alebo vyhľadávať obrázky v Picasa komunite.

Domovská stránka Picasa Flash API: http://code.google.com/p/picasaflashapi/

Aký je teda rozdiel?

• Picasa Web Albums Data API je rozhranie k službe Picasa Web Albums od Google.
• Picasa Flash API je Flash/Flex knižnica.
• Pomocou Picasa Flash API posielate requesty z Flash Player-a na Picasa Web Albums Data API rozhranie.
• Picasa Web Albums Data API žije na serverovej strane Google, Picasa Flash API beží u klienta.

Ako s tým súvisí Picasa?

Výborná otázka. Picasa je desktopový klient pre Mac, Linux alebo Windows. Picasa slúži na jednoduchú a rýchlu organizáciu, úpravu a odovzdávanie vašich fotografií na web. Áno, Picasa je tiež len klient (a naviac výkonný), ktorý okrem iných vlastností, možností a funkcií taktiež využíva Picasa Web Albums Data API napr. k odovzdávaniu obrázkov na web.

Prezeranie a vyhľadávanie

Poďme si to hneď všetko vyskúšať :). Každý url request smerom na PWA má nasledovnú schému:

http://<api_url>/<collection_type>/<projection_type>/<context>?<parameters>

Začnime s jednoduchým receptom - zoznamom používateľových albumov. Nato aby sme získali tento zoznam potrebujeme nasledovné ingrediencie:

1. Adresa Picasa Web Albums Data API:

Môžeme použiť adresu “http://picasaweb.google.com/data” alebo jej alias “http://photos.googleapis.com/data”. Ja radšej používam tú druhú. Dôvodom je crossdomain.xml súbor, ktorý musí byť načítaný do Flash Player-a pred akýmkoľvek iným requestom smerom na PWA (knižnica to spraví automaticky za vás). Týmto si zabezpečíme, že PWA neodmietne našeho klienta a Flash Player spracuje PWA odpoveď. Viac k tejto téme je popísané tu. A keďže crossdomain.xml súbor sa nachádza na http://photos.googleapis.com/data/crossdomain.xml, používam radšej ten druhý tvar. Ak by sme pristupovali k PWA cez prvú adresu, môžeme listovať pomocou PFA aj privátne albumy v prípade, že sme prihlásený cez browser do google účtu, pretože koláčik obsahuje adresu http://picasaweb.google.com/data a PWA nám vráti aj naše vlastné privátne albumy.

2. Collection type:

Keďže PFA je read-only, budeme používať iba “/feed”. Collection type “/media” by sme využili pri zápise dát z klienta smerom na server, napríklad pri aktualizácii alebo pri odovzdávaní fotografií.

3. Projection type:

Máme opať niekoľko možností. V prípade, že použijeme “/base”, odpoveď z PWA bude základný Atom feed bez akýchkoľvek rozširujúcich elementov. Tento typ projekcie je read-only. My však chceme dostať z PWA aj dodatočné informácie o fotografiách ako napr. ich veľkosť, adresy náhľadov atď. a preto budeme používať Projection type “/api”. Ak by nám Google v budúcnosti umožnil zapisovať do PWA z Flash Player-a, Projection type “/api” je nato pripravené (read-write).

4. Context:

Posledná prísada je hodnota, ktorá definuje aké zdroje chceme na PWA používať. Podľa tohto kontextu rozdeľujeme requesty na:

• User-based feed: /user/<userid>
• Contacts-based feed: /user/<userid>/contacts
• Album-based feed: /user/<userid>/albumid/<albumid>
• Photo-based feed: /user/<userid>/albumid/<albumid>/photoid/<photoid>
• Community search feed: /all
• Featured photos feed: /featured

Po správnom zmiešaní ingrediencií pre zoznam albumov užívateľa dostaneme nasledovné url: http://photos.googleapis.com/data/feed/api/user/thisispinkfu

PWA nám odpovie nasledovne (skrátene kvôli prehľadnosti):

<feed ...>
    <id>http://photos.googleapis.com/data/feed/api/user/thisispinkfu</id>
    <title>thisispinkfu</title>
    ...
    <entry>
            <id>http://photos.googleapis.com/data/entry/api/user/thisispinkfu/albumid/5296410852174025857</id>
        ...
        <category scheme="http://schemas.google.com/g/2005#kind" term="http://schemas.google.com/photos/2007#album"/>
        <title>Pinholes</title>
        <summary>Sharan STD-35 and Diana pinholes</summary>
        .
        .
        .
    </entry>
    <entry>
    ...
    </entry>
    ...
</feed>

Albumy sa vracajú späť v <entry> elementoch, kde každý <entry> element obsahuje metadáta k albumu ako napr. počet fotografií v albume, náhľad albumu, názov atď…

Aby ste nemuseli pracne vytvárať url requesty na PWA a následne parsovať štrúdle odpovedí, pomôže vám Picasa Flash API, ktorá za vás request vytvorí, sparsuje odpoveď a vráti ju zabalenú v pekne otypovanom objekte :)

Zoznam albumov by sme pomocou PFA získali nasledovne: // vytvorime instanciu servisu var service : PicasaService = new PicasaService();

// zavolame servisnu metodu, ktora vrati responder
// responder vysle pri uspesnej odpovedi z PWA data event
var responder : PicasaResponder = service.albums.list("thisispinkfu");
    responder.addEventListener(PicasaDataEvent.DATA, onGetAlbumsComplete);

// po uspesnej odpovedi
function onGetAlbumsComplete(evt : PicasaDataEvent) : void
{
    var item : AlbumEntry;

    // prejdeme vsetky <entry>
    for(var a : int = 0; a < evt.data.entries.length; a++)
    {
        item = evt.data.entries[a] as AlbumEntry;
        // a vypiseme nazov albumy a jeho linku na picasaweb stranku
        trace(item.title.value + " (" + item.links[1].href + ")");
    }
}

Výstupom z funkcie je zoznam albumov s ich názvom a priamou linkou na picasaweb stránku:

(GET) http://photos.googleapis.com/data/feed/api/user/thisispinkfu
Pinholes (http://picasaweb.google.com/thisispinkfu/Pinholes)
Redscale (http://picasaweb.google.com/thisispinkfu/Redscale)
Stockholm (http://picasaweb.google.com/thisispinkfu/Stockholm)
Instants (http://picasaweb.google.com/thisispinkfu/Instants)
...

Ďalšími možnosti PWA je napríklad:

• vyhľadávanie obrázkov s v komunite na základe query a napr. tagov
• použitie geografických hraníc pre obmedzenie výsledkov vyhľadávania na určitú zemepisnú oblasť
• limitovanie vyhľadávania na “obľúbené” fotografie
• …

V stručnosti sme si spravili prehľad čo je to Picasa Web Albums Data API, čo je to Picasa Flash API, načrtli sme ich možnosti a obmedzenia a vytvorili krátky príklad, ako získať zoznam všetkých albumov od Picasaweb používateľa.

Nakoniec už len krátky odkaz na nádherný screen saver, ktorý využíva Picasa Flash API: http://www.inspirit.ru/exchange/ascii_saver/

Flex Live Event

Slovakia Flex User Group (Slovakia FUG) organizuje druhé otvorené stretnutie s názvom “Flex Live Event”. Stretneme sa 5-teho marca 2009 o 15:30 na FEI STU v BC 150-ke.

Počas dvoch hodín prebehnú krátke prezentácie na tému od Flash Lite cez Flex, AIR až po Data Services. Prezentácie sú orientované ako pre začiatočníkov, tak aj pokročilých používateľov so zameraním na konkrétne využitie v praxi (best practices, case studies).

Všetci sú srdečne pozvaní, registrácia na toto podujatie nie je potrebná. Viac informácií sa nachádza na stránke Slovakia FUG

View Larger Map

Creating New Components in Flex 3 and Beyond @ MAX 2008

Speakers: Matt Chotin

Túto prednášku som síce nemal v pláne, ale keďže prednáška “Optimizing Adobe AIR for Code Execution, Memory, and Rendering” bola zrušená, táto padla vhod. Prednáška sa z dvoch tretín venovala Flex 3 komponentom a zvyšná tretina Gumbo komponentom.

Slovník

Životný cyklus Flex komponentu

Životný cyklus Flex komponentu je mechanizmus, ktorý Flex framework využíva na vytvorenie, správu a zánik komponentov a je navrhnutý tak aby z Flash Player-a vyťažil čo najviac.

Halo

Halo je komponentová architektúra použitá pre Flex 3 (framework) a skoršie verzie.

Gumbo/Spark

Gumbo je pracovné označenie novej verzie Flex (framework) a Flex Builder-a. Spark je označenie pre komponentovú a skinning architektúru použitú v Gumbo.

Spark je rozšírením Halo architektúry.

Parts/Časti

Väčšina komponentov sa skladá z menších prvkov, ktoré nazývame Parts/časti. Ak si predstavíme napríklad Scrollbar, tak jeho časťami v tom najjednoduchšom prípade sú thumb a track (posuvník a plocha pod ním). Tieto časti tvoria deti komponentu. Teda nielen kontajnery ako ich poznáme z Flexu ale aj komponenty môžu mať deti.

Vzory Halo architektúry

Koncepty použité v Halo architektúre, sú dôležité pre porozumenie benefitov, ktoré ponúka Spark.

Halo architektúra využíva Invalidation/Validation model. Je to model, ktorý zabezpečuje agregáciu zmien a oddialenie práce do optimálneho času. Znamená to asi toľko, že ak nastavím nejaký parameter komponentu, napr. pozícia tlačidiel video prehrávača, tak zmeny sa neudejú okamžite, ale sú odložené dovtedy, kým nenastane vhodný čas. To ktorý čas to je a kedy nastane (Validation) sa dočítame neskôr v tomto článku.

Ďalším vzorom je Event Interaction Model. Vo Flex-e je všetko o eventoch (udalostiach), čokoľvek čo robíte je riadené udalosťami. Či je to už enterFrame udalosť prichádzajúca s posuvom hlavy prehrávača na každú jednu snímku, sieťová udalosť prichádzajúca s dátami zo servera alebo ako odozva interakcie užívateľa. Udalosť je informáciou, že sa v komponente niečo má stať alebo sa už stalo.

Komponent sa skladá z častí. Tieto časti majú byť konfigurovateľné a parametrizovateľné, ako napr. štýl komponentu, pozícia ovládacích prvkov atď. Dobrým príkladom je aj prispôsobenie zoznamov (List). Bola by teda škoda ak by programátor bol nútený pre prispôsobenie bunky zoznamu dediť triedu komponentu a prepisovať jej metódy. Preto by mali komponenty ponúkať parametre ako itemRenderers a factories a umožniť tak vložiť svoj vlastný look-and-feel bunky listu. Takýto model nazývame kompozícia — umožní vyskladať a prispôsobiť si komponent na svoj vlastný obraz.

Životný cyklus komponentu je rozdelený do troch častí.

1. Inicializácia (Initialization)
   1. Konštrukcia (Construction)
   2. Konfigurácia, (Configuration)
   3. Pripojenie, (Attachment)
   4. Inicializácia, (Initialization)
2. Aktualizácia (Updating)
   1. Komponent odpovedá na zmeny pomocou Invalidation/Validation modelu
3. Zánik (Destruction)
   1. Zíde z očí, zíde z mysle
   2. Odpojenie, Detachment
   3. Garbage collection

1.1 Konštrukcia/Construction

Je to čas, kedy sa rozhodnete, že váš komponent potrebuje existovať. Prvé dôležité rozhodnutie bude, z čoho bude váš komponent odvodený, z ktorej triedy bude dediť. Najnižšia trieda v hierarchii, z ktorej možno vo Flexe dediť komponenty je trieda UIComponent. Obsahuje tie najzákladnejšie vlastnosti a metódy pre Flex komponenty.

V ďalšom na čo by ste mali myslieť je, čo sa stane keď sa komponent inicializuje (instanciuje). Bude vytvorený cez ActionScript pomocou new operátora, alebo bude vytvorený cez MXML? Ak má byť požiadavka aby bol komponent vytváraný cez MXML, nemal by konštruktor obsahovať žiadne povinné atribúty. Je možné použiť voliteľné argumenty ale ako Matt spomenul best practice Flex SDK komponentov je čo najväčší možný počet bez-argumentových konštruktorov.

V konštruktore by sa malo odohrávať čo najmenej práce. Je možné pridávať napríklad event listenery (na vlastný komponent) ako FlexEvent.CREATION_COMPLETE, MouseEvent-y, ktoré bude komponent handlovať, inicializovať konštanty a podobne.

1.2 Konfigurácia/Configuration

Vlastnosti komponentov sú v tejto fáze nastavené interne a čakajú na neskoršie spracovanie, tzn. že hodnoty vlastností sú nastavené ešte predtým než sú do komponentu pridané akékoľvek časti (deti). Vlastnosti teda musia predpokladať, že časti komponentov ešte nemusia existovať. Prakticky sa hodnoty vlastností len uložia (do storage premenných) a spracujú sa neskôr, akonáhle budú deti komponentu existovať. Príkladom takejto konfigurácie môže byť vlastnosť source video prehrávača. Setter pre source uloží hodnoty do premenných a oddiali ďalšiu prácu na vhodný čas. Časť video prehrávača, ktorá zobrazuje video, nemusi v čase, keď setter ukladá hodnoty existovať.

1.3 Pripojenie/Attachment

Je to fáza, kedy je komponent pridaný do display listu. Každý vizuálny objekt, ktorý má byť zobrazený sa stáva dieťaťom display listu niekde v jeho stromovej štruktúre. Komponent je do tejto hierarchie pridaný cez addChild() metódu jeho rodiča. Bez pripojenia do display listu sa životný cyklus komponentu zastaví.

1.4 Inicializácia/Initialization

Poslednou fázou prvej časti životného cyklu komponentu je inicializácia. V tejto fáze sa začína prvý Invalidation/Validation cyklus.

Počas inicializácie prebehne 5 akcií: 1. vyšle sa preinitialize udalosť - hovorí o tom, že komponent bol vytvorený (alias konštruktora ak používate markup), vlastnosti boli nastavené a komponent bol pridaný do display listu (má nastavenú parent vlastnosť resp. má rodiča) 1. zavolá sa createChildren() metóda - je to metóda, v ktorej sa fyzicky vytvárajú časti komponentu 1. vyšle sa initialize udalosť - akonáhle boli vytvorené časti komponentu, vyšle sa initialize event 1. nastane prvý kompletný Invalidation/Validation cyklus 1. vyšle sa creationComplete udalosť

Celá logika komponentu by mala začať fungovať až na FlexEvent.CREATION_COMPLETE event. Preinitialize a initialize udalosti by mali byť určené na spúšťanie základných konfiguračných a špecifických inicializačných procesov vo vašom komponente.

Metóda createChildren()

Metóda, kde komponent vytvára svoje časti, ktoré sú vyžadované počas celého životného cyklu komponentu. Príkladom môže byť display video prehrávača. Display by mal byť viditeľný vždy, na rozdiel napríklad od ovládacích prvkov video prehrávača, ktoré môžu byť voliteľné.

Ak komponent obsahuje dynamicky vytvárané časti, ktoré sa majú zobrazovať napríklad na základe nejakej udalosti alebo vlastnosti, tieto časti sa v createChildren() metóde nevytvárajú a namiesto toho sa použije napríklad commitProperties() metóda. Vytváranie dynamických častí komponentu neskôr odľahčuje túto metódu.

Niektoré pravidlá Halo architektúry:

• UIComponent môže obsahovať čokoľvek (Sprites, Shapes, MovieClips, Video …)
• UIComponent musí mať rodiča UIComponent
• Container môže obsahovať iba UIComponent-y (pridanie napr. Sprite vyhodí runtime exception)

Po createChildren() nasleduje initialize udalosť a prvý a plný Invalidation/Validation cyklus.

Invalidation je fáza, ktorá je popísaná troma metódami:

• invalidateProperties()
• invalidateSize()
• invalidateDisplayList()

Validation je fáza, ktorá je popísaná nasledujúcimi metódami:

• commitProperties()
• measure()
• updateDisplayList()

Volanie invalidačných metóda zabezpečí vývojár a volanie validačných metód zabezpečuje framework, v žiadnom prípade vývojár. Volanie invalidateProperties() volá commitProperties(), volanie invalidateSize() volá measure() a volanie invalidateDisplayList() zabezpečí volanie updateDisplayList() v správny čas. Poradie volania validačných metód zodpovedá poradiu v zozname vyššie.

Po tomto cykle je odoslaná creationComplete udalosť a prvá fáza životného cyklu komponentu (Inicializácia) je ukončená.

2.1 Aktualizácia/Updating

Komponent bol vytvorený, žije svoj príbeh a potrebuje vedieť ako sa aktualizovať. To pre neho zabezpečuje fáza 2.

Aktualizácie nastávajú vtedy ak užívateľ pracuje s komponentom alebo ak iné časti kódu volajú/nastavujú metódy/vlastnosti komponentu. Pre odozvu na zmeny by mal komponent využívať Invalidation/Validation model. Dôvodov je viac.

Jeden z najzásadnejších, si vyžaduje minimálne znalosti fungovania Flash Player-a. Flash ako taký pracuje so snímkami/frames. Flash aplikácie môžu pracovať na 12 snímkov za sekundu, animácie 24-25 snímkov za sekundu atď (extrémne nízky alebo vysoký frame rate je už iná debata). Horná hranica snímkov za sekundu sa dá vo Flash Player-i jednoducho nastaviť a väčšinou je vždy rešpektovaná, avšak určite nie je rešpektovaná ako spodná hranica, a to z dôvodu ako funguje Flash Player elastic racetrack - dráha ktorú prejde Flash Player pri jednom snímku.

(autor: Sean Christmann)

Predstavme si, že sa po dráhe pohybujeme v smere hodinových ručičiek a začiatok dráhy je naspodu. Flash Player je od prírody jedno vláknový (single thread) a všetko čo vie robiť je spúšťať kód alebo renderovať, čiže delí svoj čas na dve časti. V prvej polovici spúšťa kopec kódu, dokončí spúšťanie a v druhej polovici dráhy začne renderovať. Renderovanie nemáme pod kontrolou, riadi ho Flash Player. Rendering je odpoveďou na to, čo sme spravili v našom kóde v predošlej polovici dráhy.

Heavy code execution

Čo sa však stane ak spúšťanie nášho kódu zaberie dlhý čas? Keďže Flash Player je single thread, nepovie počkaj-počkaj, musím renderovať, ale nechá nás dokončiť všetok kód. Ak modrá časť dráhy je príliš veľká, nastane moment výnimky na Script Limit a Flash Player vyhlási, že spúšťanie kódu trvalo príliš dlho. To je signálom, že robíme niečo zle a musíme časť spúšťaného kódu odložiť na neskôr.

Heavy rendering

Ak máme v display liste veľké množstvo display objektov, dráha sa predlžuje v rendering časti. To môžeme jedine ovplyvniť tým, že sa zamyslíme nad tým, prečo máme toľko vecí v display liste a snažíme sa ich zredukovať :)

Životný cyklus Flex komponentu je postavený na základoch tohto frame modelu. Invalidation/validation proces profituje z elastic racetrack modelu a snaží sa spraviť si svoju prácu čo najefektívnejším spôsobom.

Opäť začíname na dráhe od spodu a v smere hodinových ručičiek. Kód je spustený až sa dostane cez celú modrú čiaru až na koniec. Počas tohto času (Invalidation) možeme v komponente zmeniť ľubovoľne veľa vlastností, zavolať ľubovoľne veľa metód, ale snažíme sa oddialiť prácu súvisiacu s renderovaním až na úplný koniec (Validation). Je to z toho dôvodu, že render prebehne len raz - Flash Player sa nedá prinútiť aby renderoval viac krát za snímku alebo skôr.

Toto je základný Invalidation/Validation model. Komponenty sedia v aplikácii, sú šťastné, čakajú na aktualizáciu. Niečo sa stane, prebehne aktualizácia. Počas aktualizačného procesu voláme invalidačné invalidateNiečo() metódy a na konci cyklu prebehne validácia. Po nej začne Flash Player renderovať. Invalidation/Validation model je rozdelený do troch fáz:

1. Aktualizácia vlastností komponentu: invalidateProperties() -> commitProperties()
2. Aktualizácia veľkosti and rozmerov: invalidateSize() -> measure()
3. Aktualizácia pozície a kreslených objektov: invalidateDisplayList() -> updateDisplayList()

1. commitProperties()

Metóda zabezpečuje manažment vlastností (properties) komponentu. Ak sa zmení v komponente čokoľvek čo ovplyvní vlastnosti komponentu, zavoláme invalidateProperties() aby sme komponent označili ako zmenený (dirty) a následne vo Validation fáze sa zavolá commitProperties(). Táto metóda je volaná pred measure() a updateDisplayList() metódami.

Flex Framework využíva na handlovanie vlasností vzor, ktorý nastavuje “dirty” príznaky a storage premenné. Modrú časť elastic racetrack sa snažíme udržať tenkú a rýchlu, ako je to len možné. “Dirty” príznaky nám umožnia filtrovať prácu v komponente na takú, ktorá skutočne musí byť vykonaná, čiže sa odstráni opakovanie spúšťania kódu.

Metoda commitProperties() poskytuje je skvelý čas na add/remove detí, ktoré NIE sú vyžadované počas celého životného cyklu komponentu. Všetky dynamické časti, ktoré sa majú pridať alebo ubrať na základe zmeny vlastností sa pridávajú a uberajú práve v commitProperties() na rozdiel od statických častí, ktoré sú vytvárané v createChildren().

// ...
// default hodnota
private var _volume : Number = 4;
// dirty flag
private var volumenChanged : Boolean;
[Bindable("volumeChanged")]
public function get volume() : Number
{
    return _volume;
}

public function set volume(value : Number) : void
{
    // iba v pripade ak sa hodnota lisi od uz nastavenej
    if(_volume != value)
    {
        // nastav
        _volume = value;
        // oznac ako dirty
        volumeChanged = true;
        // invaliduj
        invalidateProperties();
        // dispatch bindable event
        dispatchEvent(new Event("volumeChanged"));
    }
}

// invalidateProperties zavola ...
override protected function commitProperties() : void
{
    // vzdy volame super, aby sa aj nas rodic dozvedel o validacii
    super.commitProperties();

    // ak je premenna dirty
    if(volumeChanged)
    {
        // validuj
        _soundTransform.volume = _volume/10;
        netStream.soundTransform = _soundTransform;
        volumeTrack.value = _volume;
        // nezabudni vycistit dirty priznak!!!
        volumeChanged = false;
    }

    // ...

}

2. measure()

Metóda measure() je volaná vo fáze validácie a je určená zmene veľkosti komponentu, resp. jej prepočítaniu. Je to čas, kedy komponent vypočíta svoju prirodzenú veľkosť, založenú na obsahu a layout pravidlách. Je to veľkosť, ktorú komponent preferuje mať. Využíva informácie o veľkosti svojich detí, layout pravidlá, layout contstrains atď. nato aby zistil svoju požadovanú veľkosť.

Meranie veľkosti prebieha zospodu nahor.

<mx:Application>
    <mx:HBox>
        <mx:Button/>
    </mx:HBox>
</mx:Application>

Button povie svojmu rodičovi (HBox) aký veľký chce byť. V ďalšom povie HBox svojmu rodičovi (Application) aký veľký chce byť. Keďže measure() prebieha odspodu navrch, nie je nutné volať measure() na každom dieťati zvlášť, pretože v čase ako sa volá measure() na komponente, measure() dieťaťa bola už dávno zavolaná.

“Measure is kind of curious piece.”

Framework optimalizuje volania measure() na tie najnutnejšie. Povedzme, že máme nastavenú explicitnú veľkosť komponentu - measure() sa nikdy nezavolá, pretože frameworku postačuje explicitné nastavenie veľkosti nato aby určil aký veľký komponent má byť. measure() sa tiež nemusí zavolať ak sa použivajú iné layout pravidlá, layout constrains a podobne.

Pre nás ako tvorcov komponentov to znamená - nikdy nedávať závislý kód do measure() metódy, pretože sa môže ľahko stať, že sa metóda nikdy nezavolá.

measure() metóda nastavuje štyri vlastnosti:

• measureWidth, measureHeight

• measureMinWidth, measureMinHeight

  override protected function measure() : void { // nezabudnime volat super() super.measure();

  var placement : String = getStyle('controlBarPlacement');
  
  if(!placement)
  {
      placement = "bottom";
  }
  
  var bm : EdgeMetrics  = borderMetrics;
  
  if(placement == "bottom" || placement == "top")
  {
      measuredWidth = Math.max(video.width, controlBar.getExplicitOrMeasuredWidth()) + bm.left;
      measuredHeight = bm.top + video.height + controlBar.getExplicitOrMeasuredHeight();
  } else if(placement == "left" || placement == "right")
  {
      measuredWidth = controlBar.getExplicitOrMeasuredWidth() + video.width;
      measuredHeight = Math.max(controlBar.getExplicitOrMeasuredHeight(), video.height) + bm.top;
  }
  
  // bezne je nastavit minima na zmerane hodnoty
  measuredMinWidth = measuredWidth;
  measuredMinHeight = measuredHeight;
  

  }

getExplicitOrMeasuredWidth/Height() sa volá na UIComponente pre zistenie jeho veľkosti, pretože môže byť nastavená explicitne alebo ju bude treba predtým než sa vráti zmerať.

3. updateDisplayList()

Ak skončila validačná measure() metóda, prechádzame na ďalšiu validačnú metódu updateDisplayList(). Účelom tejto metódy, je rozloženie obsahu komponentu a dodatočné kreslenie, inými slovami - ideme ukladať a dokreslovať deti.

Rozloženie a nastavenie pozície častí komponentu prebieha naopak ako ich meranie - Zhora nadol.

<mx:Application>
    <mx:HBox>
        <mx:Button />
    </mx:HBox>
</mx:Application>

Funguje to asi tak, že Application umiestni svoje deti (HBox) a HBox umiestni svoje deti (Button). V metóde updateDisplayList() je treba umiestniť a veľkostne prispôsobiť každú jednu časť komponentu.

Platia tu isté pravidlá:

• ak dieťa, ktoré idem zväčšiť/zmenšiť a/alebo umiestniť je UIComponent, použijem setActualSize() pre zmenu veľkosti a move() pre zmenu pozície. Je to z toho dôvodu, že keď nastavujeme width, height, x a y na UIComponent-e, tak sa dispatčujú move a resize eventy, ktoré sú postupne zachytené a vykonané za sebou. Namiesto toho sa používajú tieto dve metódy, ktoré agregujú move a/alebo resize eventy a vysielajú ich naraz.
• ak dieťa nie je UIComponent, nastavujeme width, height, x a y priamo cez vlastnosti.

“updateDisplayList() je ideálne miesto pre použitie Flash Player Drawing API.”

Style support

Podpora štýlov je pripravená priamo v UIComponent-e. Našou požiadavkou je, aby sme užívateľovi nášho komponentu umožnili inline zmenu štýlov a vlastností súvisiacich so štýlmi. Na to aby sme mohli nastaviť štýl inline v MXML ako atribút, je nutné zadefinovať metadáta pre komponent, ktoré dekorujú triedu a dajú kompileru a IDE informácie o tomto štýle:

[Style(name="textSelectedColor", type="uint", format="Color", inherit="yes")]

Default hodnotu stýlu nastavíme priamo v komponente alebo v default.css súbore. Štýly sa môžu meniť run-time. Ak chceme komponent začleniť do run-time styling mechanizmu, musíme prepisať styleChanged() metódu a zadefinovať, ako má komponent reagovať na zmenu štýlu. Táto metóda skontroluje, ktorý štýl sa zmenil a nastaví správnu invalidáciu.

override public function styleChanged(styleProp : String) : void
{
    super.styleChanged(styleProp);

    if(styleProp == "controlBarPlacement")
    {
        invalidateSize();
        invalidateDisplayList();
    }
}

Hint: Aké vlastnosti komponentu naprogramovať ako štýl?:

• ak daná zamýšlaná vlastnosť má viac dočinenia s prezentáciou, mal by to byť štýl,
• ak máme konštantu, ktorá má dočinenia s prezentáciou, mal by to byť štýl.

Udalosti vo Flex-e

Každý komponent by mal byť schopný počúvať na a vysielať udalosti. Ak potrebujeme mať udalosť nastaviteľnú a dostupnú inline z MXML, musíme opäť použiť metadáta pre event:

[Event(name="ready", type="mx.events.VideoEvent")]

Metadáta hovoria o tom, ako sa udalosť, ktorá je vysielaná volá a taktiež aký ma typ. Výhodou je používať vlastné triedy udalostí rozšírené napríklad od mx.events.Event. V takejto triede možeme ďalej definovať statické premenné ako názvy udalostí a tým dosiahnúť compile-time kontrolu na typy eventov. Pomocou rozšírených event tried vieme definovať ďalšie dodatočné informácie/vlastnosti vhodné pre event handlery.

Hint: používajte desktriptívne názvy udalostí.

3. Destroying the component!

Príde čas kedy aj váš komponent bude zapísaný do čiernej kroniky. Prvá vec, ktorá sa vykoná je detachment, alebo odparentovanie :) Komponent sa odstráni z display listu cez removeChild() volanie. To spôsobí, že komponent nie je validovaný alebo prekreslovaný resp. Invalidation/Validation a draw metódy nefungujú! removeChild() vracia referenciu na odstránený dokument, ktorú môžeme uschovať pre jeho reinkarnáciu (komponent nebude odstránený z pamäti cez garbage collector) ako napr. adopcia iným rodičom alebo niečo ako znovu-vytvorenie. Takýto spôsob znovu-využívania komponentov je oveľa lacnejší ako vytvorenie kompletne nového komponentu. Flex framework je plný takýchto príkladov (viď Datagrid). O kompletné odstránenie komponentu z pamäti sa stará Garbage Collector (gc). Gc zoberie spolu so sebou do večných lovíšť celý komponent len v prípade, že sa na komponent neviažu žiadne referencie. Takýmito referenciami sa myslia napríklad event listenery, dictionaries (slovniky) alebo Timers.

Hint:

• používajte parameter useWeakReferences s hodnotou “true” pre addEventListener metódu, potom ak jediná referencia na objekt je event listener samotný, tak bude objekt bude vymazaný z pamäte.

this.addEventListener(FlexEvent.CREATION_COMPLETE, creationComplete_Handler, false, 0, true);

• takisto pre Dictionary plati, že slovníky môžu byť vytvorené s parametrom useWeakReferences, potom ak jediná referencia na objekt je kľúč slovnika tak bude vymazaný z pamäte.

dict = new Dictionary(true);

Touto vetou končí aj popis životného cyklu komponentu vytvoreného na Halo architektúre.

Z Halo do Spark

Ako sme povedali na začiatku, komponentová architektúra Halo používa nasledovné vzory:

• Invalidation/Validation Model
• Event Driven Interaction Model
• Composition

Tieto vzory stále existujú v komponentovej architektúre Spark. Spark však pridáva svoje vlastné vzory. Jeden z nich je “separácia komponentovej logiky od jej vizuálu”.

Komponenty majú vlastnú “triedu komponentu”, v ktorej je zadefinovaná logika a funkcionalita celého komponentu, ktorá nemá nič spoločné s vizuálom komponentu. V tejto triede neexistuje žiadna logika, ktorá diktuje vizuál a look-and-feel komponentu. Namiesto toho má komponent pridelenú “skin triedu”, ktorá obsahuje všetky informácie pre layout a look-and-feel komponentu - čokoľvek vizuálne sa nachádza v tejto “skin triede”. Tieto dve triedy navzájom komunikujú, ale sú od seba galvanicky oddelené. Trieda komponentu je napisaná v čistom ActionScript-e, a skin trieda je napisané v MXML.

Ďalšou vlastnosťou okrem toho, že logika je od prezentácie úplne separovaná je kompozícia funkcionality. V Halo ak mal napríklad List komponent List single selection, mal aj multiple selection. Keď sme multiple selection nepotrebovali, nemali sme možnosť ju odstrániť z komponentu, iba vypnúť (resp. nezapnúť). Spark to vnima celkom ináč. List komponent má single seleciton vloženú “by default” a ak by sme chceli použiť multiple selection, tak by sme si ju museli osobitne pridať do komponentu. To umožňuje postaviť komponent na mieru, tak aby bol dostatočne malý a rýchly.

Vzor, ktorý je vraj pravdepodobne najdôležitejším vzorom v Spark je “dizajnér-developer” kontrakt udržiavaný cez dáta, časti a stavy (data, parts, states) komponentu. Dáta, časti a stavy sú nám už viac menej jasné, jedine dodať, že stavy ako boli definované v Halo sa používajú rovnako aj teraz avšak všade tam, kde to je možné. Predstavme si napríklad tlačidlo, ktoré môže mať up-state, down-state a over-state. To všetko sa deje v triede komponentu (component class) a táto trieda je zodpovedná za to, že nastaví skin triedu (skin class) do požadovaného stavu, takže je jednoduché editovať vizuál komponentu v jeho jednotlivych stavoch. Komponent sa nestará o to ako sám vyzerá, pretože za všetko je zodpovedná skin trieda a takisto skin trieda sa zase nemusí odvolávať na žiadny kód v komponente aby zmenila svoj vizuál a layout.

Switchujeme na Gumbo

1. Posaďte sa a popremýšlajte - pre mňa vždy najdôležitejšia časť kódovania. Zalejem si kávu, vyhodím zvyšky slaniny z klávesnice a premyslím si čo je základnou funkcionalitou môjho komponentu, čo je dôvodom jeho života - to bude to, čo vložíme do našej komponentovej triedy. Ostatné vlastnosti, možnosti a funkcionality budú nabaľované na triedu neskôr. Napríklad pre video prehrávač platí, že jeho základnou funkcionalitou je prehrávanie videa, resp. video display. Ak niekto bude chcieť play button, bude mať play button ako dodatočnú funkcionalitu.
2. Spíšte časti (deti) skinu - treba identifikovať všetky časti skinu, tak aby sa dali v ďalej upravovať. Rozdelíme skin na dve časti:
   1. prvá čast obsahuje skutočne potrebné časti, ktoré budu existovať po celý život komponentu (napr. video display)
   2. druhá čast obsahuje voliteľné časti ako napríklad play button, pause buton, volume slider a ostatné ovládacie prvky, ktoré sú dynamické a môžu existovať len určitú dobu
3. Pridajte Spark-špecifický kód - ako prvé si zvolím správnu základnú triedu od ktorej budem dediť. Gumbo obsahuje množstvo nových tried, ktoré majú zapúzdrené nové funkcionality. Implementujte partAdded() a partRemoved() metódy, ktoré sú kľúčové metódy životného cyklu komponentu. Tieto metódy sú volané práve vtedy, keď sú časti komponentu pridávané alebo uberané. Tieto metódy handlujú vytváranie častí, pridávanie a odoberanie event listenerov a pod. V ďalšom je nutné dohodnúť sa na správnych stavoch. Ak viem, že môj komponent bude obsahovať viac stavov ako tie čo zdelil od rodičovskej triedy, identifikujem ich a dopíšem. Následne vytvoríme skins, to je kreatívna časť, kedy deklaratívne píšeme naše skin triedy, v hojnej miere aplikujeme markup a nové MXML graphics tagy. MXML graphics je množina tagov uvedená v Gumbo, ktoré obalujú renderovacie možnosti Flash Player-a. Sú to Graphics tags a Graphics primitives ako <Rect>, <Fills>, <Stroke>, Blend módy a všetky tie nádherné veci, ktoré Player dokáže. Takže máme komponent triedu, máme skin triedu, ako ich galvanicky previažem? - jednoducho, cez css.
4. Ak ste si mysleli, že už nič zaújimavšie vás nečaká, tak v tento krok je prekvapenie - vyhodíme kopec kódu :) V Gumbo svete, nepotrebujem viac createChildren(), pretože metódy partAdded() a partRemoved() handlujú tvorbu a zrušenie častí komponentu. measure() a updateDisplayList() sú nám na dve veci, pretože od teraz všetko handluje skin. Skin meria ako veľký chce byť, skin umiestňuje svoje časti.

Zhrnutie

Od prednášky som očakával veľa, a veľa som aj dostal. Autorka prezentácie, dala k dispozícii zdrojové kódy z prednášky a taktiež je k dispozícii aj záznam prednášky.

Flash Player Elastic Track - Learn it, love it, live it - dôležitý koncept, s ktorým je nutné sa skamarátiť. Snažíme sa udržať dráhu čo najokrúhlejšiu a čo najkratšiu. Ako to dosiahneme? Využijeme Invalidation/Validation model (all the cool kids doing it). Komponent dokáže byť s týmto modelom rýchlejší a chytrejší. Najlepšiu referenciu kódu životného cyklu komponentov máte priamo pred sebou - kód Flex framework-u.

Zdroje: http://iamdeepa.com/blog/?p=39 http://tv.adobe.com/#vi+f15384v1002 http://opensource.adobe.com/wiki/display/flexsdk/Gumbo http://opensource.adobe.com/wiki/display/flexsdk/Gumbo+Component+Architecture

Introducing to Thermo and Next Generation of Flex @ MAX 2008

Speakers: Ryan Stewart, Steven Heintz

Po Opening General Session to bola prvá prednáška, ktorú som absolvoval. Ubehol rok od prezentácii Thermo na MAX 2007 a ja som bol zvedavý ako ďaleko Thermo resp. dnes už Flash Catalyst je a kedy si ho budem môcť skúsiť naživo.

FXG ako univerzálny formát

Špecifikácia FXG (1.0) popisuje univerzálny grafický XML formát pre Flash Platform-u. FXG obsahuje vysoko-úrovňové grafické a textové objekty, ktoré sa využívajú na vytvorenie, združenie, transfomáciu a vizuálnu modifikáciu základných vektorových a rastrových tvarov. Renderovací model FXG sa približuje renderovaciemu modelu Flash Player-a 10 a ponúka všetky grafické možnosti Flash Platform-i spolu s podporou pre budúce možnosti Flash Player-a.

FXG ako podmnožina MXML definuje výmenný formát pre Flash Catalyst. FXG je podporovaný v Creative Suite 4 a to Photoshop, Illustrator a Fireworks CS4.

Zdroj: http://opensource.adobe.com/wiki/display/flexsdk/FXG+1.0+Specification

Flash Catalyst

Flash Catalyst je to, čo sme všetci predtým poznali ako Thermo. Je to nový profesionálny dizajnérsky nástroj na tvorbu vzhľadu aplikácií a interaktívneho obsahu bez nutnosti programovania, čo môže siahať od interaktívnych reklám, cez produktové príručky a portfóliá až po užívateľské rozhrania pre aplikácie. Flash Catalyst umožňuje dizajnérom začať pri statických kompozíciách vytvorených v Adobe Photoshop CS4, Illustrator CS4 alebo Fireworks CS4 a skonvertovať vytvorenú predlohu do aplikácie s interaktívnom obsahom.

Zdroj: http://labs.adobe.com/technologies/flashcatalyst/

Myšlienka, ktorá sa skrýva za Catalyst-om je orientovaná na dizajnérov a umožňuje im vytvoriť skôr kompletné zážitky ako len “témy” a “skiny” v spolupráci paralelne s vývojármi.

Preview verzia Flash Catalyst (Mac verzia) bola dostupná na Adobe MAX 2008 pre všetkých a bola distribuovaná na jednom DVD spolu s Gumbo-m (Mac aj Win verzia).

Ryan Stewart po krátkom úvode spravil malé demo. Vychádzal z dizajnu vytvoreného vo Photoshop-e, ktorý ako *.psd importoval do Catalyst-u.

Catalyst umožňuje import aj z aplikácií ako Adobe Illustrator alebo Adobe Fireworks.

Počas importu *.psd dizajnu do aplikácie sa na pozadí generuje “well formed” kód v *.fxg formáte. Pridávanie stavov, prechodov a efektov je veľmi jednoduché vďaka dizajn módu.

Časová os umožňuje presne nastaviť dĺžku trvania prechodov v čase pomocou drag-n-drop.

Ryan nakoniec vytvoril jednoduchý interaktívny element, kde cez dva kliky nadefinoval onClick akciu, ktorá nastaví run-time stav aplikácie. Nakoniec otvoril uloženú aplikáciu v novom Gumbo-vi, bohužial renderovanie v dizajn móde máličko zlyhalo.

Snažil som sa vytvoriť si jednoduchú slideshow aplikáciu cez Catalyst a Gumbo. Dizajn som vytvoril cez Photoshop a následne importoval do Catalyst-u. Výsledok nebol moc uspokojivý, poloha objektov bola odlišná od originálu, väčšinou sa prvky nachádzali na pozícii 0, 0. Niektoré vektorové vrstvy boli úplne rozbité, bolo nutné ich rasterizovať vo Photoshop-e pred importom. Konverzia objektov na interaktívne elementy prebiehala hladko. Avšak pri náhľade projektu sa mi compiler ohlásil asi s 30-timi chybami. Na dnes som to nechal tak, ale v testovaní budem pokračovať :)

Edit: Chyba zrejme nebude v podkladoch ako som sa domnieval. Použil som pre import podklady z http://thermoteamblog.com/ a aplikácia sa zachovala rovnako — objekty sú posunuté, rozbité a nepoužiteľné. Skúsim sa obrátiť na Thermo Team o pomoc, dúfam že sa problém vyrieši. Nerád by som odkladal zamýšlané články až k oficiálnemu vydaniu :)

Gumbo a Spark

Gumbo je názov pre novú verziu Flex Builder-a a Spark je označenie skin a komponentovej architektúry použitej pre Gumbo. Zásadnou novinkou je okrem nových vlastností samozrejme vyššie popísané FXG, ktoré obsahuje základné grafické a textové elementy, skupinové elementy a možnosti základných transformácií. FXG obsahuje tagy pre tvorbu základných tvarov ako napr. , a , tagy a atribúty pre výplne a obrysy týchto základných tvarov s rôznymi farbami, prechodmi alebo rastrami ako aj podporu pre filtre, masky, priehladnosti a blend módy na FXG elementoch.

Heidi Bauer-Williams z Flex Builder tímu predstavila ďalšie zásadné novinky pre Gumbo.

Package explorer — zlepšuje prehladnosť štruktúry kódu a umožňuje dokonca zobraziť už aj štruktúru swc knižníc

Templates — možnosť vytvorenia šablón pre rôzne typy súborov

Zobrazovanie ASDoc dokumentácie v tooltipoch

Automatické generovanie getter-ov/setter-ov pre akúkoľvek premmennú v triede

Automatické generovanie event handlerov

Skok na riadok v debugger-i po dosiahnutí breakpoint-u

Výskyt breakpoint-ov na základe podmienok — vhodné napr. pre debugging slučiek

Network monitor — sledovanie sieťového trafiku z/do aplikácie, podpora HTTP a AMF protokolu. (bez náhľadu)

Move refactoring — refaktoring na základe presunu v rámci package štruktúry. Konečne, lebo väčšinou si zvyknem umiestnenie triedy rozmyslieť vtedy, keď je takmer celá trieda dopísaná a dvakrát podedená.

Bola zvýšená rýchlosť compiler-a ako aj znížená spotreba pamäte celej aplikácie. Bola pridaná podpora pre FlexUnit a jednoduchá integrácia PixelBender efektov.

Práca s Flex Builderom je opäť o niečo jednoduchšia a príjemnejšia, avšak stále je čo zlepšovať. Závery si nedovolím robiť, pretože aplikácia nie je finálna a Adobe môže ešte všeličím prekvapiť. Koniec koncov, opísané “nové feature” sú bežnou vecou konkurenčných nástrojov. Dúfam len, že Adobe sa ich bude snažiť predbehnúť :)

Ciao Italia

Niektoré veci sa dejú úplne náhodne a sú o to príjemnejšie, že prídu práve vtedy, keď to nečakáte. Počul som z rozprávania o Adobe MAX udalosti, že sa tam dejú veľké veci, len som tomu nevenoval veľkú pozornosť lebo sa nedúfal, že raz sa takejto udalosti zúčastním aj ja sám.

Tom vystrelil z motyky, môj zamestnávateľ to odobril a ani som sa nenazdal a 30-teho Novembra, deň pred Adobe MAX 2008 bol tu. Ďakujem!

Šesť ráno. Vstávame Michal. Kávička, raňajky u Dašky, hopsa šupsa na letisko, ešte že to bratislavské nie je hodinu ďaleko. Na checkin som prišiel posledný, s hŕstkou nevyspaných talianov prechádzam cez rentgen. Akurát pristálo naše lietadlo, dofúkajú gumy a fičíme. Sedím nakonci lietadla, vedľa dievka žmolí sáček, v duchu ju počujem modliť sa aby nešplechlo vedľa.

Pristávame v Bergamo, u hipíka kupujem return ticket na Mailand central station. Hodinka a sme tam. Vyhodili nás priamo za hlavnou stanicou. Očkom idem kuknúť ako to tam vnútri vyzerá. Napodiv stanica nie je ošťatá, nevidím žiadnych pľuvajúcich počerných pred vchodom, nič čo by sa dalo porovnať s bratislavskou hlavnou stanicou. Vnútri to vyzerá ako iný svet, kilometrové stropy, milión ľudí, tristo koľají, v strede točiaci sa bilboard baťa. Idem do preč. Smer Via Mac Mahon. Po hodinovej prechádzke nachádzam hotel. Vnútri jeden Ind ako recepčná a majiteľ v ošúchanej žltej bunde. Majiteľ ani slovo po anglicky, a Ind mi lámane vysvetlil že mám počkať, “d rum iz klining”.

Počkám, pravda. Chalaň spravil kávičku, a po otázke či majú internet access začal koktať. Leták píše, že v lobby by mal aspoň jeden byť. Problém je, že tu nemajú lobby. Pol hodinka a som na izbe. Skúsim wifi, nie, wifi tu nebýva. Sranda začala keď som chcel použiť elektrickú zásuvku. Nie, zásuvka sa nedá použiť. Tri dierky pod sebou, ktoré boli užšie ako vidlica od nabíjačky. Skúsil som silnejšie pritlačiť, že reku možno prejde cez ten plast. Nie, neprešlo. Pobalil som sa a odišiel na registráciu. Na recepcii som ešte spomenul svoj problém so zástrčkou, ukázal som mu koncovku a chalaň bez slova vytiahol redukciu, usmial sa, ja som sa usmial ešte viac.

Milano Convention Centre je čo by kameňom dohodil. Reklamných predmetov mám plný batoh, je pol tretej a vyrážam do mesta pozrieť kam chodia celebrity. Po hodinke som prišiel k Duomo. Čierny pouličný predavač zo Senegalu mi núti cvernové náramky.

“Aj tag jú maj bradr, for Afrika, and jú giv mí som many”. Podávam mu dve eurá, nech mám pokoj, nie nestačí. “Tú? Jú giv mí fajf, aj ken čejnďz jú”.

Ruku nato a idem do preč, smer la scala. Pred ňou ešte väčšia šóra ako pred Duomo. Fakt dlhá. Stmieva sa. Fičím na hotel. Cestou Crispy McBacon v čínskom mekdonalde. Pekný deň za nami.

Hello Flex World

Úvodník k poznámkovému bloku. Počiatočné fakty a fikcie. Prvá časť 356 dielnej argentínsko-brazílskej telenovely. Vitajte.

Ahoj! Volám sa Michal Gron. Som absolvent Fakulty elektrotechniky a informatiky STU v Bratislave v odbore Elektronika so špecializáciou na Mikroelektroniku.

Počas štúdia na Katedre Mikroelektroniky som spolupracoval na vývoji komplexného elektronického vzdelávacieho prostredia určeného pre študentov so špecializáciou na elektronické systémy.

Od roku 2006 do roku 2008 som pôsobil v spoločnosti e-learnmedia, s.r.o. na vývoji elektronického vzdelávacieho obsahu. Od roku 2008 pracujem ako Flex/AIR developer v spoločnosti uptime Slovakia, spol. s r.o.

Toto miesto slúži na moje postrehy, nápady a poznámky z Flex/AIR sveta, poznámky z riešení Flex a AIR špecifických problémov súvisiacich s mojou pracovnou náplňou a taktiež poznámky z mojich osobných open-source projektov ako napr. PicasaFlashAPI. Dúfam, že tieto poznámky niekomu pomôžu, niekoho pobavia a že nikoho neurazia. Frekvencia bude skôr nižšia a nepravidelná :).