Ezt a plugint csak az Aptana erőlteti, néküle ugyan nem válik használhatatlanná, de az update/plugin kezelése és a css/js fileok zökkenőmentes szerkesztése sajnos nem megy e nélkül. Ma reggel rövid hajtépés után visszapakoltam 32bites Java-t és Eclipse-t, de továbbra is 64bites windows-on a memória miatt.

Azt még értem, hogy sokminden nincs még 64bitre elkészítve, mert a hétköznapi felhasználók között nincs ennyire elterjedve, de a fejlesztők között azért gyorsabban terjed, ha más nem, az Aptana kiadhatna egy saját fordítású XULrunner plugint 64bitre az Aptana stúdióhoz.

Bárkinek van hasznos tanácsa, szívesen fogadom.

Viszont vannak dolgok, amikhez még kép se kell.

Navigációnál és UI kezelőfelületeknél gyakran láthatunk kicsi, egyszerű háromszögekből álló nyilakat. Ezeket elkészíthetjük képpel, esetleg valamely UTF8 karakterrel a html kódban. Előbbi megoldás minden színvariációra és állapotra külön képet igényel, utóbbival pozícinálási gondok lehetnek más-más böngészőkben, és megzavarhatja a felolvasó programokat – nem valami akadálymentes megoldás.

Mi más lehetőség marad? Ma már lehet vektorosan canvas illetve VML elemekre rajzolni, színezni, tetszőleges módon scriptelni különböző állapotokra, hogy nézzen ki az elem… de ez már érezhetően aránytalanul nagy ráfordítás ekkora feladatra.

Egy lehetőség maradt, amivel egyszerű, színes poligonokat rajzolhatunk és nem kell hozzá plugin, kép, de még javasript se: a css keret.

A böngészők egy elemet körbevevő, vastag keretet, azok találkozásánál egy sima, ferde egyenes mentén illesztik, ezzel elkerülve azt a problémás kérdést, hogy melyik keret hol lógjon túl az elem szélén és mennyire. A html és css vízszintes és függőleges világában ezek a ferde vonalak eléggé meglepően hatnak, ritkán is fordulnak elő, mivel csak eltérő színű és esetleg vastagságú kereteknél válnak láthatóvá.

Ha egy ilyen elemen a magasságot és a szélességet nullára vesszük, négy “nyilat” kapunk. Innen már csak a nemkívánatos kereteket kell áttetszővé állítani, és marad egy.

Apróságokra persze oda kell figyelni,pl. a pozicionálásnál, a html elem ilyenkor mindíg a nyíl csúcsa.

Előjött egy IE6 bug és annak körüljárása is, úgyfest IE6 nem kezeli rendesen a transzparens kereteket, kivéve, ha solid stílus helyett dotted -re állítjuk. Mivel ez a keret amúgy se látszik, tökmindegy mire állítjuk, és ha ezzel a trükkel az összes böngészőben jó, akkor miért ne.

Végül a css kód ennyi:

span.arrow {
	display: block;
	width: 0px;
	height: 0px;
 
	overflow: hidden;
 
	border-top: 20px dotted transparent;	
	border-right: 0px dotted transparent;
	border-bottom: 20px dotted transparent;	
	border-left: 20px solid green;
}

Ezáltal egy jól használható, testreszabható kis elemet kapunk, amit a mai egyszerű weboldalak és html alapú alkalmazások jól használhatnak.

Demo, és pár példa itt látható
Tesztelve: IE6, 7, 8, chrome, ff3, safari 4.

Előnyök:

• html-css, nincs plusz kép, kevesebb http lekérés
• gyors megjelenítés
• testreszabhatóbb
• mouseover adott a DOM-ból

Hátrányok:

• kicsit nagyobb html kód (vagy js futásidő, ha utólag teszed a DOM-ba, de ez elkerülhető)
• nem teljes a testreszabhatóság, pl nem lehet neki keretet rajzolni
• talán valahol megtöri a rétegszemléletet, plusz html kód a design-hoz
• IE alatt pixelesedés előfordulhat, ezt a nyil méretein finoman korrigálva javíthatjuk

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.

Majd 5 év után eljött az ideje a lépésnek, s búcsút intettem a Carnation Zrt. csapatának, és április vége óta a ustream.tv kis hazai csapatát segítem – reményeink szerint – előrébb.

A carnát csak ajánlani tudom bárkinek aki a webfejlesztésben szeretne elhelyezkedni, remek csapat, jó hely, jó infrastruktúra és sokat lehet tanulni ezen szakma különböző aspektusairól. Ha gondolod, tedd magad próbára.

Ahogy Hitch mondaná, “hajrá előre”.

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