Adobe AIR este un runtime cros-platformă pentru desktop, creat de Adobe, ce permite programatorilor-web utilizarea tehnologiilor web pentru a crea aplicaţii RIA şi aplicaţii web pentru desktop.

Pentru a înţelege mai bine ce oferă Adobe AIR, precum şi problemele pe care le abordează, ar fi util de a arunca o privire asupra istoriei (relativ scurte) a aplicaţiilor Web.

O scurtă istorie a aplicatiilor Web

Pe parcursul ultimilor ani, s-o observat o modă accelerată a aplicaţiilor ce migrează de pe desktop spre browserul web. Acest lucru a fost determinat de factori multipli, printre care:

• Dezvoltarea Internetului ca mediu de comunicare
• Implementarea relativ uşoară a aplicaţiilor web
• Posibilitatea de a ţinti mai multe sisteme de operare via browser
• Maturitea tehnologiilor client de nivel înalt, cum ar fi browserul, framework-uri JavaScript şi runtime-ul Flash Player

La început aplicaţiile web erau construite în primă etapă cu HTML şi JavaScript, care se bazau mult pe interacţiunile client-server şi reîcărcare paginilor. Modelul cu reîncărcare era consistent cu metafora pe bază de document pentru care browserul a fost iniţial dezvoltat, însă oferea o experienţă relativ slabă pentru client la rularea aplicaţiilor.

Odată cu maturizarea runtime-ului Flash Player, şi cu recenta adăugare a funcţionalităţilor tip AJAX, a devenit tot mai uşor pentru programatori de a se debarasa de modelul flux-de-pagini. Programatorii au început să ofere o ofere o experienţă mai bogată în aplicaţiile din browser. Într-o prezentare din martie 2002, Macromedia a formulat termenul „Aplicaţie Internet Bogată” (Rich Internet Application) pentru a desemna acest tip de noi aplicaţii-în-browser, care „combină conţinut, logica aplicaţiei şi comunicarea pentru... a face Internetul mai utilizabil şi mai plăcut”.

Aceste aplicaţii ofereau experienţe mai bogate, similare celor de pe desktop, totodată menţinând natura cros-platformă a Webului:

Aplicaţiile web sunt în esenţă - acces, pentru că webul este conţinut şi aplicaţii oriunde, indiferent de platformă sau calculator. Aplicaţiile RIA trebuie să cuprindă şi să susţină toate sistemele de operare populare, precum şi cea mai largă gamă de dispozitive şi platforme emergente cum ar fi smart-phonurile, PDA-urile, set-top boxes, consolele, şi altele.

Prezentarea conţine mai multe caracteristici ce definesc aplicaţiile RIA:

• Să ofere un runtime eficient, performant pentru executarea codului, conţinut şi comunicare
• Să integreze conţinut, comunicare şi interfeţe de aplicaţie într-un mediu comun
• Să ofere modele puternice şi extensibile de interactivitate
• Să permită dezvoltarea rapidă a aplicaţiilor cu ajutorul componentelor şi reutilizabilităţii
• Să facă uz de web şi servicii de date oferite de serverele de aplicaţii
• Să lucreze atât pentru clienţii conectaţi cât şi pentru cei deconectaţi
• Să ofere un mod facil de implementare pe platforme şi dispozitive multiple

Mişcarea spre oferirea unor experienţe bogate în browser (iniţial oferite de Flash Player, ulterior şi de JavaScript şi AJAX) au dus la o explozie de aplicaţii web.

Webul acum s-a stabilit ferm ca o platformă de dezvoltare a aplicaţiilor ce oferă beneficii atât programatorilor cât şi utilizatorului final. Unele din aceste beneficii includ posibilităţi ca:

• Ţintirea platformelor şi sistemelor de operare multiple
• Dezvoltarea în limgaje de programare şi layout de nivel relativ înalt
• Posibilitatea pentru utilizatorii finali de a accesa aplicaţiile din practic orice colţ al lumii conectat la Internet
• Aducerea relativ simplă la zi a aplicaţiilor

Creşterea aplicaţiilor web poate fi observată atât în trendul Web 2.0, care constă în întregime din aplicaţii şi API-uri bazate pe Web, cât şi adopţia aplicaţiilor web ca business model de bază de către marile companii şi organizaţii.

Probleme ale aplicaţiilor via Browser

Odată cu creşterea complexităţii aplicaţiilor, ele au început a forţa atât capacităţile browserului cât şi uzabilitatea lor în sine. Cu creşterea popularităţii aceste probleme devin tot mai evidente şi importante, subliniind faptul că mai sunt o serie de impedimente atât pentru programatori cât şi pentru utilizatori.

Browserul web a fost iniţial dezvoltat pentru a transmite şi reprezenta documente HTML. Şi dizainul de bază a browserului nu s-a schimbat semnificativ în această privinţă. Conflictul între funcţionalităţile orientate document şi cele aplicaţie crează o serie de probleme la crearea aplicaţiilor pentru browser.

Conflicte de UI (Interfaţă Om-Maşină)

Aplicaţiile dezvoltate pentru browser au propria interfaţă care adesea e în conflict cu interfaţa browserului. Modelul aplicaţie-în-aplicaţie adesea rezultă în interfeţe ce conflictează şi se contrazic între ele. În cele mai bune cazuri aceasta duce la inducerea în eroare, confuzarea utilizatorului, iar în cele mai rele la eşecul rulării aplicaţiei. Exemplul clasic este butonul „Înapoi” din browser. Acest buton are sens la navigarea prin documentelor, dar nu întotdeauna are sens în contextul unei aplicaţii. Deşi sunt o serie de soluţii pentru a rezolva această problemă, ele sunt aplicate incosistent şi utilizatorii adesea nu ştiu dacă o aplicaţie suportă butonul „Înapoi” sau apăsarea lui va descărca aplicaţia (trecând la alt document), cauzând pierderi de stare şi date.

Depărtare faţă de Desktop

În mare parte datorită modelului de securitate Web (care restricţionează accesul la calculatorul utilizatorului), aplicaţiile din browser adesea nu oferă tipuri de interacţiuni cu sistemul de operare, pe care utilizatorii le aşteaptă de la aplicaţii. De exemplu, nu poţi face drag la un fişier într-o aplicaţie din browser pentru ca aplicaţia să interacţioneze cu fişierul de pe calculatorul utilizatorului.

Aplicaţii RIA au încercat să îmbunătăţească starea lucrurilor prin crearea interefeţelor mai „bogate”, mai asemănătoare desktopului, însă ele n-au rezolvat limitările şi separarea fundamentală a browserului de desktop.

Deşi sunt proiecte în curs de desfăşurare (cum ar fi Google Gears, Yahoo BrowserPlus, şi noi API-uri şi adăugiri de funcţionalitate în browsere) cu scopul de a reduce separarea dintre browser şi desktop, totuşi sunt în stadiu incipient, fără nici un clar câştigător sau standart emergent. Nu numai că nu se poate de bazat pe astfel de funcţionalităţi, dar şi disponibilitatea implementărilor şi soluţiilor multiple ameninţă să fragmenteze în continuare experienţa de dezvoltare pentru browser.

Experienţe în primul rând Online

Deoarece aplicaţiile web sunt livrate de pe server şi nu pe calculatorul utilizatorului, aplicaţiile web sunt în primul rând o experienţă online. Deşi se întreprind încercări de a crea aplicaţii web offline (cu ajutorul pluginurilor şi HTML 5), ele nu oferă un model consistent de dezvoltare şi nu reuşesc să funcţioneze în diferite browsere, sau adesea necesită instalarea extensiilor adiţionale în browser. Mai mult decât atât, ele adesea necesită interacţiunea utilizatorului pentru managementul aplicaţiei şi browserului în moduri neaşteptate şi complexe. Totuşi acesta pare a fi un domeniu în care browserele vor înregistra progrese în următorii câţiva ani.

Cel mai mic numitor comun

În fine, odată cu „îmbogăţirea” şi mărirea complexităţii aplicaţiilor, acestea împingând limitele JavaScript şi DHTML, programatorii sunt puşi în faţa diferenţelor de funcţionalitate a browserelor şi implementării API-urilor. Deşi aceste probleme pot fi adesea rezolvate cu script specific browserului, în ultimă instanţă aceasta duce la cod care: a) este dificil de menţinut şi scalat; şi b) ia timp util din dezvoltarea funcţionalităţilor.

Deşi frameworkurile JavaScript sunt o modalitate populară de soluţiona acest tip de probleme, acestea oferă doar funcţionaliatea implicită a browserului şi adesea acestea se bazează pe cel mai mic numitor comun al funţionalităţilor browserelor pentru a uşura modelul de dezvoltare. Rezultatul aplicaţiilor JavaScript sau DHTML sunt modele de interacţiune şi experienţe-utilizator asemenea la cel mic numitor comun, dar duc şi la costuri mărite în dezvotare, testare şi implementare.

Odată cu maturizarea browserelor cel mai mic numitor comun se îmbunătăţeşte, însă acest proces ia mult timp (adesea ani) odată cu lansarea browserelor noi.

Totuşi realitatea că aplicaţiile web au emers în ciuda acestor neajunsuri, reprezintă un argument forte pentru necesitatea de a avea o platformă cu un model calitativ de dezvoltare care are capacitatea de a produce aplicaţii pentru sisteme de operare multiple. O platformă care să ofere accesibilitatea modelului de dezvoltare pentru btowser, totodată oferind funcţionalităţi de aplicaţie desktop ar lua ce-i mai bun din ambele lumi. Anume asta înceară să ofere Adobe AIR.

Introducând Adobe AIR

Şi totuşi ce este Adobe AIR şi cum poate el să completeze dezvoltarea aplicaţiilor web?

Adobe AIR este un runtime cross-platformă dezvoltat de Adobe, ce permite programatorilor web să utilizeze cunoştinţele lor (cum ar fi Flash, Flex, HTML, Java-Script şi PDF) pentru a dezvolta şi implementa aplicaţii RIA pe desktop.

În esenţă, Adobe AIR e o platformă între desktop şi browser, combinând accesibilitatea şi uşurinţa modelului web cu funcţionalitatea şi bogăţia modelului desktop.

De asemenea e foarte important să subliniem ce NU este Adobe AIR. Adobe AIR nu este un runtime general pentru desktop, creat pentru a face competiţie cu runtime-uri de aplicaţii de nivel jos. Adobe AIR vine din web pe desktop şi ţinteşte spre programatorii web. Iar primul său scop e să ofere posibilitatea funcţionării aplicaţiilor web şi RIA pe desktop. Distincţa deşi subtilă este foarte importantă, pentru că anume acest lucru este principala ţintă a creării Adobe AIR şi dictează direct funcţionalităţile acestuia din urmă.

În nucleu, Adobe AIR este bazat pe tehnologii web, ceea ce permite programatorilor de a folosi aceleaşi tehnologii şi modele de dezvoltare pe care le folosesc la crea aplicaţiilor pentru web.

Tehnologii Primare Adobe AIR

Adobe AIR conţine trei tehnologii primare, care fac parte din două categorii: tehnologii-aplicaţie şi tehnologii-document.

Tehnologii-aplicaţie Primare

Tehnologiile de aplicaţie sunt tehnologiile care pot fi folosite ca bază a unei aplicaţii în Adobe AIR. AIR conţine două tehnologii-aplicaţie primare: HTML şi Flash, ambele putând fi folosite pentru crearea aplicaţiilor.

Adobe Flash

Prima tehnologie de bază pe care e construit Adobe AIR e Adobe Flash Player, în speţă pe versiunea Adobe Flash Player 9 care include limbajul baza pe ECMAscript, dar şi maşina virtuală Tamarin (cu surse publice, care va fi folosită pentru interpretarea JavaScript în versiunile viitoare ale Firefox).

Toate API-urile Flash Player sunt accesibile din Adobe AIR, mai mult decât atât, acestea au fost extinse şi/sau îmbunătăţite. Câteva din funcţionalităţile oferide de Flash Player sunt::

• Motorul de ActionScript Interpretat Just-in-time pentru performanţa şi rapiditatea executării aplicaţiilor
• Stiva completă de reţea, inclusiv HTTP şi RTMP, dar şi socketuri binare şi XML
• Motorul de randare bazat pe vectori şi API-uri de desenare
• Suport extensiv multimedia, inclusiv bitmapuri, vectori, audio şi video

Desigur că frameworkul Adobe Flex 3 pentru RIA este construit pe baza ActionScript 3, şi deci puteţi să faceţi uz de toate funcţionalităţile oferite de Flex pentru a crea aplicaţii Adobe AIR.

HTML/JavaScript

A doua tehnologie de bază din Adobe AIR este HTML şi JavaScript. Aceasta include un motor complet de randare HTML, care are suport pentru:

• HTML
• JavaScript
• CSS
• XHTML
• Document Object Model (DOM)

Acelaşi motor de randare WebKit este folosit în toate versiunile Adobe AIR indiferent de platforma pe care rulează. Acest lucru are o serie de implicaţii. În primul rând, atunci când dezvoltaţi conţinut HTML şi JavaScript nu trebuie să vă faceţi griji privind probleme de compatibilitate în implementările din diferite browsere. În al doilea rând, puteţi face uz de funcţionalităţile avansate HTML, JavaScript şi CSS disponibile în WebKit fără a vă face griji privint prezenţa acestora în diferite versiuni de browser.

Da, într-adevăr. Nu sunteţi obligaţi să folosiţi Adobe Flash pentru a crea aplicaţii Adobe AIR. Puteţi construi aplicaţii cu funcţionalităţi extinse doar folosind HTML şi JavaScript. Acest lucru de obicei nedumereşte programatorii care cred că se axează doar pe Flash.

Totuşi, în esenţă, Adobe AIR e un runtime focusat pe dezvoltatorii web care folosesc tehnologii web - şi care sunt cele mai „web” tehnologii dacă nu HTML şi JavaScript?

Motorul HTML folosit în Adobe AIR este motorul cu sursă deschisă WebKit. Acesta-i motorul din spatele mai multor browsere, inclusiv KHTML pe KDE şi Safari pe Mac OS X.

De Ce WebKit?

Adobe a studiat mult timp problema care HTML să fie folosit în Adobe AIR şi a folosit o serie de criterii care în ultimă instanţă au forţat alegerea WebKit.

Proiect deschis.

De la bun început Adobe a ştiut că nu doreşte să creeze şi să menţină propriul motor de randare HTML. Acest lucru ar implica nu doar un volum imens de lucru, dar şi dificultăţi pentru programatori, care vor trebui să se familiarizeze cu mofturile încă unui motor HTML.

WebKit oferă runtime-ului AIR un motor de randare HTML cu funcţionalităţi complete, fiind în dezvoltare continuă de către o comuniate robustă de dezvoltare care include atât programatori individuali, cât şi companii precum Nokia sau Apple. Acest lucru permite companiei Adobe să se axeze pe corectări de erori şi dezvoltări de noi funcţionalităţi, şi pe deasupra înseamnă contribuţie activă în proiectul WebKit, totodată folosind avantajul contribuţiilor din partea altor membri ai proiectului.

Tehnologie cunoscută de programatorii web

După cum am scris mai sus, una din cele mai complexe în dezvoltarea aplicaţiilor web este asigurarea lucrului consistent în browsere diferite. Ceva poate lucra perfect în Firefox pe Mac, însă poate eşua lamentabil în Internet Explorer pe Windows. Din această cauză testarea şi corectarea erorilor din cauza browserului pot face zile fripte.

Adobe a dorit să asigure faptul ca programatorii să fie familiarizaţi cu motorul HTML folosit în Adobe AIR, şi să nu fie nevoiţi să înveţe din nou toate şiretlicurile şi erorile unui nou motor. Programatorii trebuie să fie bine cunoscuţi cu WebKitul, deoarece Safari (browserul construit pe baza lui) e browserul standart pe sistemele Mac.

Efect minim asupra mărimii runtime-ului

Codul de bază al WebKit a fost bine scris şi organizat şi a avut un impact minim asupra mărimii finale a runtime-ului Adobe AIR.

Capacitate demonstrată de a rula pe dispozitive mobile

Deşi prima versiune Adobe AIR rulează doar pe calculatoare personale, viziunea pe termen lung e de a extinde runtime-ul de pe desktop pe telefoanele mobile şi alte dispozitive. WebKit a demonstrat în practică capacitatea de a rula pe astfel de dispozitive şi a fost portat pentru telefoane mobile de Nokia şi Apple.

Tehnologii-document Primare

Tehnologiile-document din Adobe AIR se referă la tehnologiile ce pot fi utilizate pentru randarea şi interacţionarea cu documente electronice.

Tehnologiile-document primare din Adobe AIR sunt PDF şi HTML.

PDF

Formatul de Document Portabil (PDF) e standartul web pentru răspândirea şi randarea documentelor electronice pe web.

Funcţionalităţile PDF necesită ca Adobe Reader Version 8.1 să fie instalat pe calculatorul utilizatorului. Dacă Adobe Reader 8.1 e instalat, aplicaţiile Adobe AIR vor putea face uz din plin de toate funcţionalităţile oferite de Adobe Reader expuse de acest în browser.

HTML

La origini HTML a fost creat ca tehnologie-document, şi astăzi oferă control extins şi robust asupra conţinului, aranjării şi stilării acestuia. HTML poate fi utilizat ca tehnologie-document în Adobe AIR atât într-o aplicaţie HTML cât şi în aplicaţii Flash.

Ce conţine o aplicaţie Adobe AIR?

După ce am enumerat tehnologiile accesibile pentru aplicaţii ce rulează în Adobe AIR (vezi Figura 1-1), haideţi să tragem o privire asupra modului prin care aceste tehnologii pot fi combinate pentru a crea o aplicaţie Adobe AIR.

[IMAGE] Figura 1-1 Structura Aplicaţiei Adobe AIR

Aplicaţiile pot consta din următoarele combinaţii de tehnologii::

• Doar Flash (inclusiv Flex)
• Pe bază de Flash cu conţinut HTML
• Doar HTML/JavaScript
• Pe bază de HTML/JavaScript cu conţinut Flash
• Toate combinaţiile pot asimila conţinut PDF

Integrarea Tehnologiilor şi Puntea între Scripturi

WebKit şi Adobe Flash Player sunt integrate între ele la nivel foarte jos datorită faptului că ambele fac parte din runtime. De exemplu atunci când includem HTML în conţinutul Flash, acesta este randat prin rutinele de afişare ale Flash-ului, ceea ce înseamnă că orice poate fi făcut cu un bitmap în Flash Player (blur, rotire, transformare etc.) poate fi făcut şi cu HTML-ul.

Integrarea la nivel jos se referă şi la motoarele de scripting din Adobe AIR, care rulează ActionScript şi JavaScript. Adobe AIR permite creare unei punţi între cele două limbaje şi medii, ce permite următoarele lucruri:

• Codul JavaScript poate rula API-uri Adobe AIR, Flash Player, şi ActionScript.
• Codul ActionScript poate rula API-uri JavaScript.
• Codul ActionScript poate manipula direct DOM-ul HTML-ului.
• Înregistrarea evenimententelor poate avea loc în ambele direcţii între Java-Script şi ActionScript.

Luaţi aminte că puntea între scripturi înseamnă „pasarea referinţei”. Deci la trimiterea unei instanţe a unui obiect din JavaScript în ActionScript (sau invers), schimbările aplicate acestei instanţe o vor afecta şi în celălalt mediu. Acest lucru face posibilă instanţierea şi utilizarea API-urilor Flash Player din JavaScript, sau înregistrarea şi observarea evenimentelor.

Această punte de nivel jos permite crearea aplicaţiilor care combină extensiv atât HTML cât şi Flash.

În concluzie - dacă sunteţi programator web, deja aveţi toate cunoştinţele necesare pentru a dezvolta aplicaţii AIR.

Funcţionlităţi Adobe AIR

Dacă Adobe AIR nu ar fi oferit funcţionalităţi şi API-uri suplimentare şi doar ar fi permis aplicaţiilor web să ruleze pe desktop, aacest lucuru n-ar fi însemnat mult. Din fericire însă, Adobe AIR oferă un set extins de API-uri programabile şi integrare cu desktopul ce permite programatorilor să creeze aplicaţii ce profită din plin de faptul că acestea rulează pe desktopul utilizatorului.

API-uri Adobe AIR

Plus la toate funcţionalităţile şi API-urile deja oferite de Flash Player şi motorul WebKit, Adobe AIR oferă funcţionalităţi şi API-uri suplimentare.

Câteva din aceste funcţionalităţi includ::

• API complet intrare/ieşire pentru fişiere
• API complet pentru lucrul cu ferestrele native
• API complet pentru lucrul cu meniurile native
• API-uri online/offline pentru determinarea stării conectării serviciilor
• Control complet asupra aparenţei ferestrelor aplicaţiei (chrome)
• API de stocare local
• API de aducere la zi
• Stocare criptată locală
• Bază de date SQLite încorporată

Funcţionalităţile pot fi implementate direct în runtime sau la nivelul frameworkului (în Flex şi JavaScript), sau folosind o combinaţie a ambelor.

Integrarea Adobe AIR cu desktopul

După cum am scris mai devreme, aplicaţiile destinate pentru browsere nu pot oferi aceleaşi interacţiuni pentru utilizatori ca şi aplicaţiile desktop. Acest lucru duce la aplicaţii cu care este dificil de interacţionat, deoarece ele nu oferă funcţionalităţi cu care utilizatorii sunt deja obişnuiţi.

În schimb o aplicaţie Adobe AIR (fiind aplicaţie desktop) poate oferi setul de interacţiuni şi experienţe pe care utilizatorii sunt obişnuiţi să le vadă într-o aplicaţie. Acestea includ printre altele:

• Mecanism normal de instalare/dezinstalare
• Puncte de contact pe desktop (cum ar fi shortcut-urile)
• Suport extensiv drag-and-drop:
• Între sistemul de operare şi aplicaţiile AIR
• Între aplicaţiile AIR
• Între aplicaţii native şi aplicaţii AIR
• Suport extensiv pentru clipboard
• Notificări de sistem
• Iconiţe native
• Posibilitatea de a primi argumente prin linia de comandă

Odată instalată, o aplicaţie AIR e ca şi orice aplicaţie nativă, ceea ce implică faptul că sistemul de operare şi utilizatorii pot interacţiona cu ea la fel ca şi cu oricare altă aplicaţie.

Scopul atins e ca utilizatorul final să nu aibă nevoie să ştie că el rulează o aplicaţie AIR pentru a o putea folosi. El trebuie să poată interacţiona cu ea în aceeaşi manieră cum interacţionează cu oricare altă aplicaţie desktop.

Modelul de Securitate

După toate discuţiile referitor la API-uri şi funcţionalităţi, evident urmează o întrebare importantă: cum rămâne cu securitatea? N-ar putea oare aplicaţiile AIR să facă ceva nociv sistemului pe care ruleaza, având acces la resurse locale?

În primul rând trebuie să subliniem că Adobe AIR rulează deasupra layerului de securitate a sistemului. El nu oferă nici o posibilitate de a omite sau compromite această securitate. Aplicaţiile AIR pot lucra doar cu permisiunile oferite de sistemul de operare şi se va conforma oricăror schimbări de securitate care vor fi implementate de sistemul de operare.

Pentru a rula o aplicaţie Adobe AIR utilizatorul trebuie să o descarce pe desktop, să parcurgă un ritual de instalare şi ulterior să o lanseze. Experienţa este similară descărcării şi instalării oricărei alte aplicaţii de desktop, iar similaritatea nu este întâmplătoare. Aplicaţiile Adobe AIR rulează într-un mediu de securitate fundamental diferit faţă de aplicaţiile ce rulează în browser. E un context de securitate mai apropiat aplicaţiilor native decât web aplicaţiilor.

Prezentare Succintă a Modelului de Securitate a Browserului

Pentru a oferi un mediu sigur de navigare, modelul de securitate a browserului limitează toate abilităţile intrare/ieşire a aplicaţiilor web. E limitat accesul la resursele locale, resursele de reţea şi sunt restricţii de interfaţă-utilizator. Browserul permite doar conectarea la surse de date asociate (de obicei) cu un server de pe un singur domeniu web. Browserul oferă o interfaţă obişnuită utilizatorilor pentru ca aceştea să ştie originea aplicaţiei şi să controleze stările ei. Acest model e sufient pentru aplicaţii conectate la un singur furnizor de servicii web şi se bazează pe aceste servicii pentru sincronizare şi stocare de date.

Unii programatori au extins modelul de securitate a browserului integrând surse multiple de date şi/sau experimentând cu interfeţe inconsistete aparenţei browserului. Astfel, unele din aceste aplicaţii necesită pluginuri pentru browser cu funcţionalităţi care nu sunt oferite de browser. Altele fac uz de funcţionalităţi a browserului precum notificarea utilizatorilor sau configurări de securitate perzonalizate pentru a permite o protecţie mai mare sau redusă a unor aplicaţii de pe domenii specifice. Mecanisme de acest tip permit programatorilor să dezvolte aplicaţii mai complexe însă acestea forţează modelul de securitate a browserului.

Implicaţiile Modelului de Securitate Adobe AIR

În loc să încerce să extindă funcţionalităţile browserului ca acesta să funcţioneze atăt ca browser cât şi ca un runtime flexibil pentru aplicaţii, Adobe AIR în schimb oferă un runtime flexibil pentru dezvoltarea aplicaţiilor folosind tehnologii web. AIR permite programatorilor să dezvolte aplicaţii ce includ surse multiple de date, oferă utilizatorilor control asupra locului şi modului de stocare a datelor lor şi oferă experienţe imposibil de reprodus într-o interfaţă browser. Aplicaţiile Adobe AIR pot să-şi îndeplinească funcţiile în siguranţă deoarece ele necesită preventiv acceptul utilizatorului care la rândul trebuie să ştie ce instalează şi să aibă încredere în aplicaţia pe care o instalează. Aplicaţiile din browser nu pot avea aceleaşi drepturi şi funcţionalităţi pentru că browserul în sine este o aplicaţie ce trebuie să continue să ofere un mediu sigur de navigare pe Internet.

Modelul de securitate Adobe AIR are o serie de implicaţii atât pentru programator cât şi pentru utilizator. Pentru programator - conţinutul dintr-o aplicaţie AIR are capabilităţice nu trebuiesc expuse unui context nesecurizat, inclusiv fişierelor de pe Web. Runtime-ul oferă o serie de funcţionalităţi menite să întărească această separare şi să ajute programatorii să creeze aplicaţii cu securitate avansată.

Partea verso a monedei e că utilizatorii nu trebuie să instaleze aplicaţii AIR din surse dubioase. Această practică e similară procedurilor pentru aplicaţii native desktop şi pluginuri pentru browsere. O serie de aplicaţii şi conţinut web necesită anumite pluginuri preinstalate pentru a permite rularea lor. Browserul Firefox are un layer de extensibilitate foarte accesibil ce permite oricărui programator să modifice browserul. Aplicaţiile, pluginurile şi extensiile pot face lucruri dăunătoare sistemului pe care ruleaza şi din această cauză e nevoie ca utilizatorii să aibă încredere în sursele unui astfel de conţinut.

În fine, una din funcţionalităţile importante incluse în Adobe AIR e capacitatea runtime-ului de a verifica identitatea autorului unei aplicaţii dacă aceasta a fost semnată digital cu un certificat emis de o autoritate de încredere ce emite certificate Certificate Authority (CA). De aceea utilizatorii trebuie să fie vigilenţi şi să decidă cu grijă dacă au încredere în autorul aplicaţiei şi dacă doresc să instaleze o aplicaţie a cărei origine nu poate fi verificată de runtime.

Setul de Instrumente de Programare a Adobe AIR

Unul din motivele popularităţii ridicate a aplicaţiilor web este faptul că programatorii web pot implementa aplicaţii pe care utilizatorii le pot rula de oriunde, indiferent de platformă (fie Mac, Windows, Linux, Solaris sau telefoane mobile).

Şi totuşi succesul se bazează nu doar pe implementarea cross-platformă a aplicaţiilor, ci şi pe natura cross-platformă a mediului de dezvoltare. Acest lucru asigură faptul că orice programator poate dezvolta pentru şi cu tehnologia dată. Atât runtime-ul cât şi instrumentele de dezvoltare sunt independente de platformă şi sistem de operare.

Acelaşi lucru se aplică pentru Adobe AIR, care la fel oferă atât accesibilitatea cross-platformă a aplicaţiilor web, cât şi posibilitatea dezvoltării şi publicării aplicaţiilor de pe practic oricare sistem de operare.

Dat fiind faptul că aplicaţiile Adobe AIR sunt dezvoltate cu ajutorul tehnologiilor web existe precum HTML sau Flash, puteţi folosi aceleaşi instrumente/medii pe care le-aţi folosit pentru a dezvolta aplicaţii web. Kitul de Dezvoltare Adobe AIR (SDK) oferă două aplicaţii pentru linie de comandă care permit testarea, depanarea şi împachetarea aplicaţiilor AIR în practic orice mediu de dezvoltare şi cu orice instrument de dizain.

ADL	Permite rularea aplicaţiilor AIR fără necesitatea instalării lor premergătoare
ADR	Împachetează aplicaţiile AIR în pachete de instalare distribuibile

Deşi Adobe a adăugat suport propriilor instrumente de dezvoltare web pentru a putea crea conţinut Adobe AIR (inclusiv Adobe Flex Builder, Adobe Flash CS3 şi Adobe Dreamweaver), programe de la Adobe nu sunt obligatoriu necesare pentru a crea aplicaţii. Puteţi crea aplicaţii AIR cu oricare instrument de dezvoltare web, doar folosint utilitarele pentru linie de comandă.

Oare Adobe AIR reprezintă sfârşitul aplicaţiilor Web din Browser?

Deja cred că puneţi întrebarea: „Adobe AIR e super tare! De ce-ar mai continua cineva să dezvolte aplicaţii pentru browser? Reprezintă oare Adobe AIR sfârşitul aplicaţiilor web din browser?”

Nu.

Repetăm.

Nu.

Deşi Adobe AIR oferă soluţii pentru o serie de probleme ce survin în utilizarea aplicaţiilor web din browser, totuşi sunt câteva avantaje în folosul aplicaţiilor web din browser. Faptul că sunt o mulţime de aplicaţii web în pofida dezavantajelor enumerate mai sus sunt un manifest faţă de avantajele rulării în browser. Atâta timp cât avantajele vor depăşi dezavantajele programatorii vor continua să dezvolte aplicaţii web pentru browser.

Dar această întrebare nu trebuie neapărat să fie de tipul „sau/sau”, pentru că aplicaţiile web construite pentru browser pot fi rapid transformate în aplicaţii Adobe AIR. Puteţi avea o versiune web ce oferă funcţionalităţi asociate browserului şi o versiune Adobe AIR ce beneficiază din plin de faptul că rulează pe desktop. Ambele versiuni pot avea în comun aceleaşi tehnologii, limbaj de programare şi cod de bază. Într-adevăr, unele din primele aplicaţii populare pentru AIR, cum ar fi „twhirl” sau „eBay Desktop” completează cu succes aplicaţiile web existente.

Aplicaţiile Adobe AIR le completează pe cele web. Nu le înlocuiesc.