Iframe ál-ajax

a legősibb ajax-szerű aszinkron adatcsere, mivel az iframekre is vonatkozik a same-origin szabály, a terheléselosztás ugyanúgy problémás lehet, nem is beszélve pár böngészpő iframe specifikus bugjairól

Ajax pollozás

periódikusan kiszólunk egy szervernek, hogy van-e új üzenet. Előnye hogy kb mindenben működhet, hátránya, hogy a böngészők same-origin szabálya miatt csak azt a szervert hivogathatjuk, ami az oldalt is kiszolgálja, így nehezebb elosztani a terhelést, valamint, amíg nincs új üzenet, feleslegesen ütögeti a szervert

Ajax jsonp poll

már hívhat akármilyen szervert, de ugyanúgy a kliens futtat időzítőket, ráadásul a kéréssel érdemes elküldeni valami időpontot hogy mikortól akarjuk a friss üzeneteket, azt szerveroldalon le kell kezelni külön logikával, plusz terhelést okozhat

Egy ideális világban

• más domaineket is hívhassunk aszinkron GET kérésekkel, biztonságosan
• ne fusson feleslegesen időzített kérések hada a kliensen
• a friss üzenetek idejével se kelljen foglalkozni, külön

Ebben a a posztban efelé az álomvilág felé próbálok haladni.

Mi az a CORS?

A böngészőinkből eddig nem rángathattunk AJAX segítségével csak úgy, tetszőleges URL-eket az interneten, köszönhetően az úgynevezett “Same-Origin policy” -nak, azaz annak a szabálynak, hogy a hívott URL csak azonos protokollon, azonos domainen és porton lehet. Ezen probléma feloldására találták ki a JSONP-t, annak számos hátrányával, pl:

• a választ egy javacript függvénybe kell csomagolni a küldőnek
• nem XHR alapú, egy script taget tesz az oldalba minden hívásnál, nem érhetjük el a küldő/fogadó http fejléceket

Erre találták ki 2010 körül a Cross-Origin Resource Sharing (CORS) protokollt, amit ma már az újabb böngészők támogatnak (IE8+, Firefox 3.5+, Safari 4+ és a Chrome). A teljes leírását a W3C oldalán olvashatjátok, tömören arról van szó, hogy a kliens és a szerver extra http fejlécek segítségével “ismerkedik össze” és döntik el, hogy a kérést lehet e teljesíteni vagy sem.

A kliens többek között küld egy Origin fejlécet, azzal a hosztnévvel ahonnan a kérés indul, a szervernek a válaszban ezt egy Access-Control-Allow-Origin fejléccel nyugtáznia kell, azaz visszaküldi a hosztnevet ahonnan elérhető a kért adat. Ha más fejléceket is küldünk, azokat egy vesszővel elválasztott listában a szervernek szintén nyugtáznia kell egy Access-Control-Allow-Headers válasz fejlécben. Mindezeket a webszerver intézi nekünk, esetünkben az Nginx.

Firefox esetében az első POST kérést megelőzi egy OPTIONS kérés, aminek válasza eldönti, hogy a böngésző folytathatja e, ez az ún. preflighted kérés. Az OPTIONS-re válaszban érkezik egy Access-Control-Max-Age fejléc, ami azt mondja meg a böngészőnek, hogy meddig nem kell újra küldenie az OPTIONS ellenőrzést.

A témában ajánlott Zakas cikke a CORS-ról.

Mi az az Nginx?

Az Nginx egy relatíve új webszerver, fő ereje, hogy spórol az erőforrásokkal, 2010 áprilisában a net legforgalmasabb oldalainak 4%-át szolgálta ki. Egyszerű összerakni, beállítani, de pl PHP-t nem kezel úgy modulként mint az Apache, fastCGI kell hozzá, vagy a PHP 5.3.3-ba csomagolt PHP-FPM szerver.

A jelenlegi megoldásban a fejlécek módosítása miatt szükség lesz a ngx_headers_more modulra, valamint az nginx_http_push modulra, ami Comet szerverré emeli az egészet.

Comet, és hogy miért jó mindez

Eddig, ha egy szerver akart a kliensnek üzenetet küldeni egy böngészőben, akkor a kliensnek kellett kéregetnie a szervert (polling), hogy van e új adat. A comet (vagy ajax-push, http server push) megoldás lényege az az, hogy a kliens hívja a szervert, egy egyszerű GET hívással. A szerver nem ad azonnal választ rá, nyitvatartja kapcsolatot, viszont ha új üzenet kerül a csatornába, azt azonnal visszaküldi a kliensnek, ami a választ feldolgozza és azonnal újranyitja a GET hívást. Így lényegében a kliens akkor kapja meg az üzenetet amikor a szerver akarja.

Ez persze működik JSONP-vel is, ha a GET paraméterekben küldünk pontos időket, hogy mikortól kérjük az üzeneteket, hogy a régieket ne kapjuk meg, talán ez a legböngészőfüggetlenebb megoldás, már ha sikerül olyan comet szervert találni amivel ez lehetséges.

Amúgy itt egy beállítás Nginx-hez, hogy szépen válaszoljon JSONP kérésekre, egy Http_Echo_Module nevű nginx modul kell hozzá:

location /subscribe {
set $jsonp_callback $arg_callback; # ?callback= GET parametert varja
echo_before_body "$jsonp_callback(";
echo_after_body ");";
}

Jelen esetben nem jsonp-t használtam, ezért erre most nem lesz szükség.

Az nginx_http_push modul

A modul használat szempontjából rém egyszerű, alapvetően nem igényel semmilyen speciális programnyelvet. Két elérési pontot definiál a webszerveren, az egyik, amin a csatornákba küldhetünk, és a másik, amire a kliensek felcsatlakoznak az csatornákon szórt üzenetekre. Az előbbit érdemes priváttá tenni, korlátozni a hozzáférést, az utóbbit fogja a javascriptünk rángatni. Az üzenetek csatornába küldése sima POST kérésekkel történik, magyarul küldhet bele bármi, ami képes HTTP POST küldésre, szerveroldalon a programunk lehet php, ruby, javascript, stb. Itt egy eléggé jó cikk a működéséről, és egy példa ruby-val.

Az Nginx Comet konfiguráció

# belso, privat eleresi pont az uzenetek bekuldesehez
location /publisher_endpoint {
    set $push_channel_id $arg_id;       #/?id=_CHANNELID_ pl.
    push_publisher;

    push_store_messages on;            # üzenet tárolás, korábbi üzenetekre
    push_message_timeout 2h;           # két óráig tárol egy üzenetet
    push_max_message_buffer_length 30; # max ennyi üzentet tárol egyszerre a csatorna
}

# nyilvanos ajax GET eleresi pont
location /activity {

    push_subscriber;
    push_subscriber_concurrency broadcast;

    set $push_channel_id $arg_id;
    set $orig $http_origin;

    if ($request_method = OPTIONS) {
        more_set_headers "Access-Control-Max-Age: 1728000";
        echo "";
    }

    # a CORS működéséhez szükséges konfiguráció
    more_set_headers "Access-Control-Allow-Credentials: true";
    more_set_headers "Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, If-None-Match, X-File-Name, Cache-Control";
    more_set_headers "Access-Control-Allow-Methods: PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST";
    more_set_headers "Access-Control-Expose-Headers: Etag";
    more_set_headers "Access-Control-Allow-Origin: $orig";

    more_set_headers "Vary: Accept-Encoding";

    types         { }
    default_type application/json;

    more_set_headers "Content-Type: application/json";
}

Kicsit bővebb leírás a válaszban küldött fejlécekről:

Access-Control-Allow-Credentials

Amennyiben a kliens ajax kérésében megadjuk parameternek a withCredentials true értéket, a válasznak tartalmaznia kell ezt a fejlécet, különben a böngésző nem adja tovább a választ a javascriptnek.

Access-Control-Allow-Headers

Amennyiben bármilyen, nem általános fejlécet küldünk a kéréssel, annak szerepelnie kell ebben a listában, különben nem engedélyezett az adatcsere. Esetünkben ez a comet szervernek szükséges If-Modified-Since és If-None-Match fejlécek, de érdemes felkészülni többel is.

Access-Control-Allow-Methods

Kérés típusok, szigoríthatjuk csak GET elfogadására is.

Access-Control-Expose-Headers

Ha a szerver a válaszban küld valami nem általános fejlécet, ezzel a listával tudja azokat olvashatóvá tenni a kliens számára a válaszban.

Access-Control-Allow-Origin

Ezzel a fejléccel biztosítjuk, hogy a válasz csak olyan kérésnek szól, aminek az Origin fejlécében található hoszt név ezzel megegyezik. Az egész CORS alapja talán.

Access-Control-Max-Age

Előellenőrzés, vagyis preflighted kérés esetén a következő ellenőrzésig tartó idő.

Probléma – az időzítés, üzenet ütközés

Problémás eset lehet, ha egyenként, a küldött sorrendben pakolásszuk az üzeneteket a Comet csatornába. Mivel az If-Modified-Since header maximum másodpercekben gondolkozik, nincs microtime, ha két üzenet között nincs egy másodpercnyi eltelt idő, gondot okozhat a sorrendiség, vagy ha – pl esetünkben – nem férünk hozzá az ETag fejléchez, el is szállhat az egész egy, ugyanazt az üzenetet kapó végtelen ciklussal. (Belefutottam párszor…)

Megoldás, message queue, demon

Vegyük el a kliensektől a – php POST-on keresztüli, de – közvetlen hozzáférést a Comet csatornától, helyette az ajax POST üzenetküldések pakolásszanak egy adatbázisba, esetünkben egy MySQL táblába. (Ezzel később az üzenetek archiválása is megoldott lesz) A mentés során az üzenetek a php-tól microtime pontosságú időt kapnak, majd ebből a táblából egy rendszerszinten futó démon másodpercenként kiszedegeti az időközben bekerült üzeneteket. A démon az éppen összegyűjtött üzeneteket egy json enkódolt tömbként küldi tovább a comet csatornára, ami kiszórja majd a klienseknek.

Amiért ez jó:

• szabályozhatjuk az üzenetek beérkezését, szűrés, feldolgozás, stb
• nem kérdés, hogy melyik üzenet volt elől
• másodpercenként több üzenet is jöhet így
• skálázhatóság, a démonnak csak meg kell adni a többi, csatasorba tett nginx szervert, hogy küldje nekik is az üzeneteket
• a démon figyelheti az üzenet csatornában található üzenetek mennyiségét, és hogy mennyi feliratkozó van épp a csatornán
• ha a push_message_timeout miatt kiürül a csatorna, a démon visszatöltheti az adatbázisból az utolsó néhány üzenetet

Működő példa, Firefox 3.6+, Chrome és Safari böngészőkben. iOS-en nem működik, IE8/9 -ben elméletileg van rá megoldás, utánajárok. Majd.

PHP démon írásához most már PEAR modul ad segítséget, én ezt vettem alapul. A példában használt fileokat itt letölthetitek.

Konklúzió

Ahogy minden lassan terjedő szabvány, ez is fájdalmas, már ami az IE-t illeti. A megoldás elvileg az Etag fejléccel pontosítaná az üzenetlistát, de azt nem adták vissza CORS használatakor a böngészők, emiatt kellett a démonos megoldás. A nem általános fejlécek miatt sok vállalati tűzfalon elbukhat a dolog, ez is hátráltató tényező.

A démont lehet le fogom lőni a jövőben, ha érdekel a demó, de nem akarod te feltenni magadhoz, írj emailt.

A következő próbálkozással egy másik comet modult, a nginx-push-stream-module -t próbálom ki, ebben az friss üzenetek eléréséről egy GET paraméterben adott microtime unix timestamp segítségével gondoskodik a szerver, ha jsonp-vel megoldható, akkor az válasz lehet a böngészőfüggetlenségre.

Itt a blogon, és máshol is előszeretettel alkalmaztam egy flash alapú font megjelenítő megoldást, ami véletlenül sem a sIFR volt. Azzal kapcsolatban régóta több fenntartásom is volt, kényelmesebb volt a saját megoldásom használni, ismerve annak limitációit.

Nemrég viszont elémkerült a cufón, egy tisztán JS alapú megoldás, ami egészen zseniális.

Működése eléggé komplex, mivel a betűtípusok grafikáit kénytelen a böngésző saját eszközeivel megrajzolni. Ehhez a canvas elemet, Explorer alatt pedig annak natív VML támogatását használja ki.

A használni kívánt betűtípusból egy online generátor segítségével SVG alapú fontfile készül, amit a cufón számára VML görbékké számol át. Ezekkel már képes canvas elemre rajzolni, vagy vml elemeket készíteni.

A generátornál – a flashez hasonlóan – megadhatjuk mely karakterkészleteket akarjuk beemelni, ezzel optimalizálva a kapott font állomány méretét. A fontfile-t rögzíthetjük egy domainhez, ilyenkor az elkészült javascript “font” kódolásába bevonja az adott domaint, ezzel is védve a megvásárolt fontokat.

Ha nem bízunk a generátorban, saját dárga betűkészleteinket, vagy az ügyfél által készítetett teljesen egyedi TrueType fontot féltve, letölthetjük a generátor forrását, és azt saját fejlesztői szerveren futtatva, elkészíthetjük a font javascript megfelelőjét.

Ha kész a font, csak be kell emelni a html kódunkba, magával a cufón scripttel együtt, és amikor szükség van rá, javascriptben ráereszteni a kívánt css selector-ra.

<script src="/js/cufon.js" type="text/javascript"><!--mce:0--></script>
<script src="/js/myfont.js" type="text/javascript"><!--mce:1--></script>
<script type="text/javascript"><!--mce:2--></script>

Az összes elterjedt böngészőben használható de előtte legyünk tisztában a korlátaival, nem igényel külön plugint, és érdemes egy pillantást vetni pár tesztoldalra vele.

backGround animation

A segítségével háttérképet mozgathatunk, majdnem a megszokott sílus attribútummal az .animate() metódus paraméterei között. 

$('#myId').animate({backgroundPosition: '(150px 250px)'}); // ide
$('#myId').animate({backgroundPosition: '(-75px -50px)'}); // vagy oda

Érdemes odafigyelni a paraméterek körüli zárójelekre.

A plugin itt érhető el , használatára példa pl itt a menüben.

color animation

Ez a plugin lehetne talán igazán része a teljes csomagnak, pláne hogy John Resig írta – aki a jQuery-t magát is. Segítségével betűszínt, keretszínt és háttérszínt animálhatunk egy értékre.

$('.box')
	.animate({ backgroundColor: "blue" }, 'slow') // elobb legyen kek
	.animate({ backgroundColor: "#ff9900" }, 'slow') // aztan narancs

Itt a plugin oldala, példát pedig itt találhattok.

jQuery easing

Kicsit zavarbaejtő a jQuery dokumentációja az animate esetén:

animate( params, [duration], [easing], [callback] )

Az easing nincs túlságosan kifejtve, sokszor nem is használjuk emiatt. Ez a plugin rengeteg animációs effektet ad, amivel feldobhatjuk alkalmazásunkat.

$('.box').animate({
	width: '+=250',
	height: '+=200',
	left: 100,
	top: 200
},'slow','easeOutBack');

A plugin oldala, a mozgásokra az összes példa demó ugyamott, némi funkcionális játszadozás pedig itt látható.

Titkosított helyi adatbázis

Ha eddig – valahol joggal – óczkodtál nagyobb üzleti alkalmazás AIR re portolásától, mert nem tartottad elég biztonságosnak, akkor most már közelebb állhat hozzád az AIR, mivel lehetőség van titkosított adatbázisok - Encrypted Local Store (ELS) -  használatára, melyekbe nagyobb mennyiségű adat is belepakolható.

Flash Player 10

Az Adobe Flash legújabb üdvöskéje mostmár futhat AIRben is, a 10es verzióval azt remélik, hogy 3D-s flash alkalmazások serege jelenhet meg ebben a környezetben is.

WebKit update

Frissítették a beépített webkit motort, legfontosabb itt a Squirrelfish JS motor beemelése, amit a Safarival már megtettek. A tesztek során az Adobenál átlagosan 35%-os sebességnövekedést mértek a fejlesztők, kíváncsian várjuk.

Az AIR futtatókörnyezet tartalmaz egy SQLite adatbázis kezelő osztálycsomagot, melyet nyugodtan használhatunk adatok tárolására, kezelésére és szinkonizálására.  Annak, aki nem ismeri, erről az adatbázis rendszerről talán a legfontosabb amit érdemes nagy vonalakban elmondani, az az, hogy komplex file és memória struktúrák helyett egyetlen bináris file-ban tárolja az adatbázist. Mivel egy file és bináris, ezt a filet hordozhatjuk bármilyen rendszerre, ahol szintén használható, már ha létezik az adott rendszerre SQLite verzió.

Ennek köszönhető, hogy már rengeteg alkalmazás és operációs rendszer él ezzel a minimalista, de rendes relációs adatbázisrendszerrel, mint pl a Skype vagy a Firefox illetve a Mac OSX, jópár Symbian alapú mobiltelefon és minden iPhone vagy iPod Touch.

AIRben az adatbázishoz JavaScript segítségével férünk hozzá, mely elsőre szürreális élmény lehet azoknak, akik eddig csak rendes szerveroldali nyelvekben tettek hasonlókat.

Szinkron – aszinkron műveletek

Mint JS-ben rengeteg minden, az adatbázis műveleteink is lehetnek szinkron folyamatok, illetve eseményfüggők, így aszinkron lefutású kódok. Mindkettőnek van előnye ill. hátránya, a szinkron műveletek kódolás szempontjából egyszerűbbek, nem kell eseménykezelőkkel babrálni, de amíg lefut, a programunk malmozik/homokórázik használhatatlan csendben. Nem is ajánlott, csak nagyon kicsi adatbázisokkal, kevés adattal használni.

Az aszinkron műveletekre már készülni kell a kódunkban, eseményeket kell elkapni, adatokat mozgatni, de cserébe folyamatos marad a felhasználói élmény, meg valahogy ez közelebb is áll ahhoz a fejlesztési stílushoz, amit manapság az AJAX-al teletűzdelt weboldalak, alkalmazások megkívánnak tőlünk.

Csatlakozás az adatbázishoz

Lássuk az elejét, vegye elő alkalmazásunk az adatbázist.

1
2
3

var dbFile = new air.File("app:/db/database.db");
var db = new air.SQLConnection();
db.open(dbFile);

Meghatározunk egy File pointert ami az SQLite adatbázis filera mutat, az app:/ relatív elérési útvonal az alkalmazásunk telepített helye a fájlrendszeren. Majd létrehozzuk a kapcsolatot az adatbázishoz és megnyitjuk azt, SQLite esetén ez az a file amit megadunk neki, egy file – egy adatbázis.

Létrehozunk egy SQLConnection objektumot, majd megnyitjuk vele az adatbázist. Az SQLConnection-nek van sok eseménye, amit érdemes figyelni, leginkább talán az air.SQLErrorEvent.ERROR -t, ha hiba van. Az adatbázis megnyitása történhet az open metódussal, ha szinkron, és az openAsync metódussal, ha aszinkron műveletekkel szeretnénk dolgozni.

Aszinkron műveletek során minden lefuttatott kérést figyeltetni kell majd egy air.SQLEvent.RESULT eseményre, de most időhiányában nem térek ki az aszinkron műveletekre.

SQL műveletek

Miután alkalmazásunk csatlakozott az adatbázishoz, az SQL műveletek nagy része már nem sokban különbözik a más nyelvekben megszokott módoktól. Létrehozunk egy SQLStatement objektumot, megadjuk neki melyik adatbázist használja, és hogy mi a művelet.

4
5
6

var statement = new air.SQLStatement(); 
statement.sqlConnection = db; // az adatbázis
statement.text = "SELECT name, value FROM options"; // a művelet

7
8
9
10
11
12
13
14
15

statement.execute(); 
var results = statement.getResult(); // eredmények kiolvasása az SQLStatement objektumból
var numResults = results.data.length; 
for (i = 0; i < numResults; i++) 
{
    var row = result.data[i];
    row.name; // a mezőértékek asszociatív tömbben
    row.value;
}

Aszinkron műveletek során egy air.SQLEvent.RESULT eseményt kell figyeltetni az SQLStatement objektumon, de az eseménykezelőben a kód már ugyanez.
 
INSERT, UPDATE és DELETE műveleteknél nincs különbség, ha a statement.execute(); lefut, illetve van
air.SQLEvent.RESULT esemény, akkor volt sikeres a művelet.

Hibakezelés

Aszinkron műveleteknél az air.SQLErrorEvent.ERROR esemény figyelésekor kapott esemény-objektum hordozza a hibaüzenetet, szinkron műveletek esetén használjuk a try-catch szerkezetet, az elkapott kivétel tartalmazza majd a hiba okát.

Tippek, optimalizálás

AUTOINCREMENT - ilyen típusu oszlopoknál INSERT után az eredményobjektum lastInsertRowID paramétere hordozza az új ID-t

Paraméterezett műveletek – az AIR minden SQL műveletet alacsonyabb szintű műveleti kódra fordít, és úgy tárol, amíg nem változik a művelet szerkezete. Sok, hasonló szerkezetű művelet esetén ezt érdemes kihasználni a művelet paraméterezésével.

Ilyenkor az SQL művelet kódját felkészítjük változók fogadására, s azokat később adhatjuk hozzá vagy módosíthatjuk ahelyett, hogy újraírnánk vagy újra példányosítanánk egy SQLStatement objektumot.

17
18
19
20

statement.text = "INSERT INTO options(name, value)" + 
                 "VALUES (:optionName, :optionValue)"; 
statement.parameters[":optionName"] = "title";
statement.parameters[":optionValue"] = "Adobe AIR #6 SQLite JavaScriptből";

Később, ha ugyanerre a műveletere van szükség, csak a már példányosított SQLStatement objektumot kell újra elővenni, és módosítani a paramétereket az execute() előtt. Ennek a módszernek előnye az erőforrás kímélésen és a műveletek gyorsaságán kívül az, hogy védelmet nyújt az esetleges sql-injection sebezhetőségek ellen.

Tranzakciók – sok, logikailag valamilyen szinten összetartozó műveletet (írás/olvasás) érdemes egy tranzakcióba helyezni, összességében gyorsabb lesz a művelet.

Tranzakciókat az air.SQLConnection.begin() – .commit() – illetve .rollback() metódusaival tudunk kezelni.

Előre csomagolt adatbázisok, külső segédeszközök

Természetesen nem kell minden adatbázist helyben elkészíteni és kezdeti adatokkal, struktúrával feltölteni, lehetséges előre csomagolni az adatbázis állományt a letöltött AIR csomaggal. Csak ügyeljünk arra, hogy updatek esetén ne legyen gond esetleges felülírásból.

Az adatbázis kezeléséhez érdemes valami SQLmanager programot szerezni, vannak kifejezetten SQLitehoz kiadott programok, illetve AIRben is írtak már ilyen eszközt.

Nekem az SQLite Maestro nevű vállt be, igaz csak 30napos verziót néztem, de egész használhatónak bizonyult.

Eddig az Adobe AIR-ről:

• Eval(); Adobe AIR-ben
• #5 Natív menükezelés
• #4 Drag’n’Drop és Filefeltöltés
• #3 Események
• #2 Ablakkezelés
• #1 Az alapok

Nézzük a megoldást, de előbb az okokat, amiért így lett kialakítva a futtatókörnyezet.

Valamit valamiért, avagy amiért nincs eval().

MIt csinál az eval()? Végrehajt egy string formában megadott javascript kódsort, minden előztetes cécó nélkül.

Az AIRből pedig kivették azt a biztonsági szigorítást, hogy AJAX kérések csak azon a domainen futhatnak, ahol az oldal amit látogatunk. Bárhonnan fogadhatunk akármilyen javascript kódokat, akár fileszinten is betáplálva az alkalmazásunkba.

Ez eléggé hasznos, révén így igazi, online forrásokra támaszkodó, nyitott API-kat nyújtó webszolgáltatásokat kihasználó alkalmazást alkothatunk. De veszélyeket is rejt, révén az AIR alkalmazásunk hozzáfér a kliens filerendszeréhez. Nem lenne túl jó, ha egy pl egy chatprogram evalozott JSON stringjeiben tudatlanul kiadnánk személyesebb adatokat tartalmazó fájljainkat.

Az alkalmazásunk egy izolált környezetben fut, angol nevén ez a sandbox. Ezen belül vezették be az Adobe fejlesztői az alábbi szigorításokat:

• eval() futtatások csak az onLoad előtt működnek
• szinkron XMLHttpRequests kérések onLoad előtt nem adnak választ, aszinkron XMLHttpRequests kéréseket el lehet küldeni onLoad előtt, de azok válasza csak onLoad után érkezhet meg
• onLoad után a document.write() és a document.writeln() függvények nem kerülnek lefutásra
• htmlből hivatkozva scripteket nem lehet betölteni a sandbox-on kívülről
• dinamikusan létrehozott <script> elemek nem kerülnek lefutásra.

 
Karantén, avagy a non-application sandbox

Lehetőségünk van több ilyen sandbox-ot létrehozni, hogy ne akadjanak össze esetleg a használt rendszerek. Ezekben a “karanténokban” ismét visszakapjuk az eval()-t, újra megvan a domainre vonatkozó szigor, de semmit se láthatunk magából az AIR futtatókörnyezetből.

Ezeket például IFRAME -ek segítségével valósíthatjuk meg, az alkalmazás html kódjába helyezve valami hasonlót:

	<iframe 
		id="frameId"
		sandboxRoot="http://plurk.com/" 
		documentRoot="app:/" 
		src="nonapp_sandbox.html" 
		frameborder="0" 
		height="0" 
		width="0"></iframe>

ID – amivel majd DOMon keresztül hivatkozunk rá
sandboxRoot – az a domain amire a karanténon belül szűkítjük a lekéréseket
documentRoot – amennyiben ez “app:/”, akkor kapunk megfelelő non-application sandbox -ot
src – a html amit betöltünk majd az IFRAME-be

Most, hogy van egy szeparált környezetünk, ahol működik az eval(), már csak össze kell kötni a két sandbox-ot. Ezt az AIR egy childSandboxBridge nevű interfészen keresztül tudja megvalósítani.

Az IFRAME-be dugott htmlben hozzunk létre pár függvényt. Először definiálni kell mit akarunk az IFRAME-en kívülre adni a childSandboxBridge-en keresztül.

1
2
3
4

	/* nonapp_sandbox.html */
	window.onLoad = function(){		    
		window.childSandboxBridge = {'myEval': myEval};			
	}

Majd definiáljuk magát a függvényt amit átadunk.

4
5
6
7

	/* nonapp_sandbox.html */
	function myEval(str){
		return eval(str);
	}

Tehát maga az eval() ebben a zárt környezetben fut le, a végeredményt adja át az alkalmazásnak. Bármi ártalmas kód ami itt végrehajtódik, próbálhozhat, nem fér hozzá az AIR környezethez, s azon keresztül a rendszerhez.

Az alkalmazásunkban onLoad eseménykor definiáljuk a childSandboxBridge interfészen át kapott függvényt.

1
2
3
4

	/* application.html */
	window.onLoad = function(){
		window.myEval = document.getElementById('frameId').contentWindow.childSandboxBridge.myEval;		
	}

És ennyi, most már használhatjuk eval helyett ezt a saját függvényt. Még kényelmesebb, ha pl az általunk használt javascript keretrendszer érzékenyebb részeit módosítjuk úgy, hogy működjenek ezen az interfészen keresztül, és akkor későbbiekben már észre se vesszük ezt a problémát.

10
11

	/* application.html */
	var evaledCode = window.myEval( code_string );

Eddig az Adobe AIR-ről:

• #6 SQLite JavaScriptből
• #5 Natív menükezelés
• #4 Drag’n’Drop és Filefeltöltés
• #3 Események
• #2 Ablakkezelés
• #1 Az alapok

Erősen béta, alapfunkciókat tud már, a többi meg majd szépen fejlődik,
nyáriszünet után.

Augusztus végén folytköv.

Ő lesz az, hamarosan lehet bétateszelni.

N új játék, WASD vagy nyilak (nálam az előbbi jobban bevált) az irányítás, ENTER kiteszi egy nagyobb canvas elembe.

Mivel az AIR segítségével írt alkalmazás asztali alkalmazás, rendelkezik az alatta található oprendszer egykét képességével. Egyik ezek közül a natív menükezelés. Nem kell a designra, viselkedésre, különböző böngészőkre időt vesztegetni, használjuk azt a GUI kinézetet menüinkre amit az adott rendszer hagy nekünk.

air.NativeMenu

Egy egyszerű menü létrehozásával kezdjük, azt, hogy ez hol jelenik majd meg, majd később döntjük el.

function createFileMenu(menuType){
var temp;
var menu = new air.NativeMenu();
 
temp = menu.addItem(new air.NativeMenuItem("Új"));
temp.keyEquivalent = 'n';
temp.data = 'new';
 
temp = menu.addItem(new air.NativeMenuItem("Megnyitás"));
temp.keyEquivalent = 'o';
temp.data = 'open';
 
temp = menu.addItem(new air.NativeMenuItem("Mentés"));
temp.keyEquivalent = 's';
temp.data = 'save';
 
menu.addItem(new air.NativeMenuItem("",true)); //szeparátor
 
temp = menu.addItem(new air.NativeMenuItem("Kilépés"));
temp.keyEquivalent = 'q';
temp.data = 'quit';
 
for (var item = 0; item < menu.items.length; item++){
menu.items[item].addEventListener(air.Event.SELECT, menuItemSelectHandler );
}
return menu;
}
 
var menu = new air.NativeMenu();
menu.addSubmenu(createFileMenu(),"File");

Menüt tehát az air.NativeMenu példányosításával készíthetünk és utána lehet almenüt és/vagy funkciót hozzákötni. A példában látszik hogy még a menü struktúrálására is lehetőség van, szeparátorokkal.

Az air.NativeMenuItem még további lehetőségeket ad amit elvárhatunk egy menütől pl.:

• aktív / inaktív menü
• pipálható menü
• billentyű vezérlés

Ezek mellett kell még egy metódus, ami figyeli a menü eseményeket, egyelőre elég ha csak konzolon jelez, onnan már látható milyen adatokat hordoz az esemény.

function itemSelected(event){
var message = "Kiválasztott menü: \"" + event.target.label + "\" adat: " + event.target.data + ".";
air.Introspector.Console.dump(message);
}

Most már csak a menüt kell elérhetővé tenni. Itt kell figyelembe venni, hogy milyen rendszeren fut az alkalmazásunk. Windows alatt a hagyományos rendszermenük az ablakhoz kapcsolódnak, OSX alatt az alkalmazás menüje a menüsorba kerül az asztal tetején. Ezt a futtatókörnyezet képességeivel tesztelhetjük mielőtt megjelenítenénk a menüt.

if(air.NativeApplication.supportsMenu){ // OSX
    air.NativeApplication.nativeApplication.menu = menu;
}
 
if(air.NativeWindow.supportsMenu){ // windows
    window.nativeWindow.menu = menu;
}

Ne felejtsük el, hogy windows alatt a transparent és chrome mentes ablakokra nem lehetséges igy menüt csatolni – révén az ablak láthatatlan. Ami lehetőség marad ilyenkor az az ikonra helyezett menü, vagy a context menü, melyekre amúgy is szükség lehet. Az ikonra helyezett menü ismét az oprendszer tesztelésére kényszerít minket, erre a környezet az air.NativeApplication.supportsDockIcon és az air.NativeApplication.supportsSystemTrayIcon vizsgálatát teszi lehetővé.

Context menü esetén ilyenekre nincs szükség, ott a menü előhívásának az eseményét kell kezelnünk. Mivel használattól függően szükség lehet tetszőleges elemekre, kontrollokra saját menüt kötni, az eseményt ezeken a HTML elemeken kell figyeltetni. Ezt egy e célra fenntartott contextmenu esemény jelzi nekünk.

document.getElementById('hasContextMenu').addEventListener( 'contextmenu' ,function(event) {
    menu.display(window.nativeWindow.stage, event.clientX, event.clientY);
});

Ennyi a pozícionálás, és megjelenítés. A kívánt menü kiválasztásakor eltűnik.

Következő alkalommal az AIR-be épített SQLite adatbázist veszem elő.

Update: menük egyenesen XMLből és JSONból

Úgynézki gondoltak a komplexebb alkalmazásokra, és lehetséges XML és JSON adatformátumokból is menüket generálni. Dokumentációt érdekes módon nem találtam rá, de példát igen, a kipróbálás még hátravan.

Az XML (textContextMenu.xml):

<xml version="1.0" encoding="utf-8" ?> 
<root> 
    <menuitem label="Első menü"/> 
    <menuitem label="Második menü" type="check" toggled="true"/> 
    <menuitem label="Harmadik menü" enabled="false"/> 
    <menuitem type="separator"/> 
    <menuitem label="Negyedik menü"> 
        <menuitem label="Almenu 1, 4"/> 
        <menuitem label="Almenu 2, 4"/> 
        <menuitem label="Almenu 3, 4"/> 
    </menuitem> 
</root>

És a beemelése:

            var textMenu = air.ui.Menu.createFromXML("textContextMenu.xml"); 
            air.ui.Menu.setAsContextMenu(textMenu, "contextEnabledText"); 
 
            // az alapértelmezett context menü kikapcsolása
            air.ui.Menu.setAsContextMenu(null);

Eddig az Adobe AIR-ről:

• Eval(); Adobe AIR-ben
• #6 SQLite JavaScriptből
• #4 Drag’n’Drop és Filefeltöltés
• #3 Események
• #2 Ablakkezelés
• #1 Az alapok