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

AIR alkalmazásunknak lehetősége van más alkalmazásokból különböző adatok fogadására, a GUI-ban megszokott egyszerű drag’n'drop műveletekkel. Míg művelet végrehajtása a felhasználónak könnyű, a háttérben jópár komplexebb dologra kell figyelni. Habár böngészőkben is használható javascript alapokon, webes fejlesztőknek ez eléggé új terület lehet, így előbb nézzük meg a művelet sajátosságait a konkrét példa előtt.

Események

A drag’n'drop műveletnek minimum két résztvevője van, ahonnan indul a drag és ahol végetér, közben pedig azok az elemek is reagálhatnak, melyekkel érintkezésbe kerül a mozgatott adat. A művelet során lényegében csak eseményekre hagyatkozhatunk, ezekkel zajlik az adathordozás.

Eseményszinten nézve ezt az alábbiak alkotják:
a forrás az adatmozgatás eredete

• dragstart – a művelet kezdetén
• drag – folyamatosan a mozgatás ideje alatt
• dragend – az adat “elengedésekor”

a forrás a mozgatás célpontja illetve lehetséges célpontjai

• dragover – folyamatosan küldi, mikor a mozgatott adat az elem fölött van
• dragenter – mikor a mozgatott adat belép az elem fölé
• dragleave – mikor a mozgatott adat elhagyja az elemet
• drop – mikor a felhasználó az elemre ejti a mozgatott adatot

Ezekre az eseményekre figyelve kezelhetjük a műveletet illetve vezethetjük a felhasználót, hogy hova mit mozgathat, ügyelve a felhasználóbarát kezelésre.

Az eseményen belül innentől a dataTransfer objektumra koncentrálunk, ez tartalmazza a művelet során érkező adatokat.

Adat típusok

A böngészők nagy általánosságban az alábbi típusokat kezelik le a művelet során:
text, html, url, file. Ez utóbbi böngészőgyártótól függően még lebontható képre, helyi file-ra, stb.

Fontos megjegyezni. hogy a típust mindíg az adatmozgatás eredete állítja be, az esemény hordozza magával, a fogadó ellenőrizheti. Pl ha a címsorunkból kijelöljük a linket és azt mozgatjuk, az AIR szöveget fog látni. De ha pl az RSS feed ikonját mozgatjuk, már URL-nek látja. Itt a böngésző a forrás, az állítja be a típust.

Az AIR mozgatható adattípusai a következőek:

• Text – sima szöveg
  (“text/plain”)
• HTML – html struktúrált szöveg
  (“text/html”)
• URL – egy vagy több link
  (“text/uri-list”)
• Bitmap – bittérkép, kép adat
  (“image/x-vnd.adobe.air.bitmap”)
• File list – file lista, egy vagy több helyi file-t tartalmaz
  (“application/x-vnd.adobe.air.file-list”)

Ezek a flash képességeire emlékeztethet egyeseket, ami nem csoda, hisz az AIR esetében javascriptből félig flashbe lóg a lábunk. Az adattípust a dataTransfer.types tömb tartalmazza egyszerre többet is hordozhat, hisz pl egy html kódrészlet alapjában véve szöveg, de tartalmazhat linkeket és amúgy html formázott szöveg, így lehet akár három típusa is. Hogy ezeket miként használjuk fel, majd az adatok kinyerésénél megézzük.

Most – miután látjuk mikor és mit mozgathat a felhasználó – jön az, hogy mit kezdhet illetve kezdjen az adattal.

effectAllowed, dropEffect

Az adat forrása a mozgatás kezdetekor meghatározhatja milyen lehetőségek vannak az adat elhelyezését illetően. Az adatokat fogadó alkalmazás pedig kikötheti, hogy ő mit akar végrehajtani ezek közül. Ez a két paraméter az eseményben az dataTransfer.effectAllowed és a fogadónál a dataTransfer.dropEffect. Értékei a következők lehetnek:

• none – nincs/nem draggelhető adat, vagy az adott adattípust nem fogadja az elem
• copy – másolás
• move – mozgatás
• link – linkelés
• copyLink – másolás vagy linkelés
• copyMove – másolás vagy mozgatás
• linkMove – linkelés vagy mozgatás
• all – mindegyik

Az első négy művelet egyenként megfelel az adott rendszer szabvány kurzorainak, amit felvesz az egérkurzor a művelet során. Pl ha intézőből mozgatunk file-t, az ‘all’ értékkel jön, mi pedig jelezhetjük egy file feltöltésnél hogy ez csak ‘copy’ azaz másolás lesz a lehetséges műveletek közül, ekkor az egérkurzor jelzi ezt nekünk.

Drop

A művelet vége a drop esemény, ekkor kezdhetjük meg a feldolgozását az adatnak amit kaptunk. Az eseményből a dataTransfer.getData( string mimetype ) metódussal nyerhetjük ki azt az adatot, amire típus alapján szükségünk van. A mimetype paraméter a fent ismertetett típusok egyike.

Sajnos ez így még korántsem tökéletes, próbálkozásaim során reprodukálható volt az a jelenség, hogy képet böngészőből mozgatva próbáltam elfogadtatni vagy vizsgáltatni AIRben, nagyokat fagyott a futtatókörnyezet. Gyakorlatban inkább a filelistával és feltöltéssel mutatom be a fentieket.

Példa: filefeltöltés drag’n'drop -ra

A tanulmányozás során négy zónát raktam le htmlbe ahova huzogathatok adatokat:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

	<div class="target link">
		<h1>Linkeket ide</h1>
		Ez csak linkeket fogad.
	</div>
	<div class="target text">
		<h1>Szövegelj ide</h1>
		Ez csak szöveget fogad.
	</div>
	<div class="target file">
		<h1>Fileok jöhetnek</h1>
		Ez csak fileokat fogad.
	</div>
	<div class="target image">
		<h1>Képes vagyok</h1>
		Ez csak képeket fogad.
	</div>

Majd oldalbetöltéskor meghatároztam az események lekezelését. Itt jegyezném meg, hogy bár kényelmes használni, sajnos a jQuery .bind eseménykezélese egyelőre erre nem jó, mert a továbbított Event objektum nem tartalmazza a dataTransfer objektumot.

19
20
21
22
23

	$('div.target').each(function(i,s){
		s.addEventListener("dragenter", dragEnterOver)
		s.addEventListener("dragover", dragEnterOver)
		s.addEventListener("drop", dragDrop)
	});

Aztán jöhetnek az eseménykezelők. Az elsőben (dragEnterOver) válogatom le, melyik mezőbe melyik elemet engedem.

24
25
26
27
28
29
30
31
32
33
34
35
36
37

    function dragEnterOver(event){
		event.preventDefault();
		if( $(event.target).hasClass('link') && event.dataTransfer.types.indexOf("text/uri-list") > -1 ){
			event.dataTransfer.dropEffect = "link";
		} else if( $(event.target).hasClass('text') && event.dataTransfer.types.indexOf("text/plain") > -1){
			event.dataTransfer.dropEffect = "copy";
		} else if( $(event.target).hasClass('file') && event.dataTransfer.types.indexOf("application/x-vnd.adobe.air.file-list") > -1 ){
			event.dataTransfer.dropEffect = "copy";
		} else if( $(event.target).hasClass('image') && event.dataTransfer.types.indexOf("image/x-vnd.adobe.air.bitmap") > -1 ){
			event.dataTransfer.dropEffect = "copy";
		} else {
			event.dataTransfer.dropEffect = "none";			
		}        
    }

Mivel a statikus HTML elemek alapból nem támogatják a drag’n'drop-ot, azzal kezdjük, hogy az megakadályozzuk az alapértelmezett reakciót. Majd a zónák osztálynevei és a hordozott adat alapján leválogatjuk, hogy fogadjuk-e, és ha igen, miként fogadjuk az adatot.

Végül a drop esemény lekezelése, kinyerjük az adatot. Ezt most röviden összekötjük egy filelista feltöltéssel HTTP-n keresztül, javascriptből, röviden mert meglepően egyszerű.

38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

    function dragDrop(event){
 
		var list = event.dataTransfer.getData("application/x-vnd.adobe.air.file-list")
 
		if( typeof list != "undefined"){
			var request = new air.URLRequest("http://valami.tavoli.domain.hu/upload.php");
			for (var i in list ){
				list[i].upload(
					request,
					'filefile'
				);
				// örömünkben írjuk ki a fileok neveit
				air.Introspector.Console.log(list[i].name);
			}
		}
	}

A getData és a mime-type használatával kinyerjük a fileokat (40.), ez minden esetben egy file lista, melynet tagjai File objektumok. Ha megnézzük a doksiban, látható, hogy van egy upload metódusa, amit a FileReference objektumból örököl, ami már egy flash objektum. De a js, hála a script összemosásnak, látja ezt a metódust és ha meghívja őket egyenként (44.-51.) egy URLRequest társaságában, fel is tölti őket.

Mára ennyi fért bele, jó kísérletezést, bónusz, vagy házifeladat a copy-paste és a clipboard használatának utánajárni, hasonló ezekhez. Következő részben az AIR alkalmazás natív rendszerszintű menükezelését nézzük meg.

Eddig az Adobe AIR-ről:

• Eval(); Adobe AIR-ben
• #6 SQLite JavaScriptből
• #5 Natív menükezelés
• #3 Események
• #2 Ablakkezelés
• #1 Az alapok