Adobe AIR är en gränsöverskridande körmiljö för skrivbordet skapad av Adobe som låter webbutvecklare använda webbteknologier för att bygga Rika InternetApplikationer (RIA) och webbapplikationer för skrivbordet.

För att bättre förstå vad Adobe AIR möjliggör och vilka problem det försöker lösa är det bra att först ta en titt på webbapplikationers (relativt korta) historia.

En kort historiebeskrivning för webbapplikationer

De senaste åren har det funnits en ökande trend för applikationer att flytta från skrivbordet till webbläsaren. Detta har drivits på av ett antal faktorer, vilka inkluderar:

• Ett växande Internet som kommunikationsmedium
• Relativt enkel lansering av webbapplikationer
• Förmåga att rikta in sig mot flera operativsystem via webbläsaren
• Avancerade klientteknologiers mognadsgrad, som webbläsaren och Flash Player-körmiljön

Tidiga webbapplikationer byggdes främst med HTML och JavaScript vilka oftast till stor del förlitade sig på klient/server-kommunikation och sidomladdningnar. Den här sidomladdingsmodellen var konsekvent med den dokumentbaserade metaforen för vilken webbläsaren ursprungligen skapades, men gav en relativt dålig användarupplevelse när applikationer visades.

Men med framväxandet av Flash Player-körmiljön, och mer nyligen Ajax-funktionalitet i webbläsaren, blev det möjligt för utvecklare att börja bryta sig loss från sidbaserade applikationsflöden. Utvecklare började erbjuda rikare applikationer via webbläsaren. I en vitbok från mars 2002 myntade Macromedia uttrycket Rich Internet Application för att beskriva dessa nya typer av applikationer i webbläsare, vilka "blandar innehåll, programlogik och kommunikation … för att göra Internet mer användbart och underhållande".

Dessa applikationer erbjöd rikare, mer skrivbordslika, upplevelser samtidigt som de behöll den grundläggande plattformsöverskridande egenskapen hos Webben:

Internetapplikationer handlar helt om räckvidd. Webben lovar tillgång till innehåll och applikationer var som helst, oavsett plattform eller enhet. Rika klienter måste ta till sig och stödja alla populära operativsystem, liksom den breda grupp av framväxande enhetstyper som smarta telefoner, PDA:er, set top-boxar, spelkonsoller och Internettillbehör.

Boken fortsätter med att lista några egenskaper som utmärker RIA:er:

• Ger en effektiv, högpresterande körmiljö för att köra kod, innehåll och kommunikation
• Integrerar innehåll, kommunikations- och applikationsgränssnitt i en gemensam miljö
• Ger kraftfulla och utbyggbara objektmodeller för interaktivitet
• Möjliggör snabb applikationsutveckling genom komponenter och återanvändning
• Möjliggör användning av Webben och datatjänster som erbjuds av applikationsservrar
• Tar till sig både uppkopplade och nedkopplade klienter
• Möjliggör enkel lansering på flera plattformar och enheter

Den här rörelsen mot rikare, mer skrivbordslika upplevelser i webbläsaren (möjliggjord av Flash Player-körmiljön och mer nyligen av Ajax), har lett till en explosion av webbapplikationer.

Idag har Webben etablerat sig starkt som en lanseringsplattform för applikationer som erbjuder fördelar för både utvecklare och slutanvändare. Några av de här fördelarna är möjligheter att:

• Rikta in sig mot flera plattformar och operativsystem
• Utveckla med relativt hög nivå av programmerings- och layoutspråk
• Låter slutanvändare komma åt sina applikationer och data från praktiskt taget vilken Internet-uppkopplad dator som helst
• Enkelt att driva igenom applikationsuppdateringar till användare

Webbapplikationers tillväxt kan skönjas i både Web 2.0-trenden, som består nästan enbart av webbaserade applikationer och API:er, och i stora företags och organisationers anammande av webbapplikationer som en grundläggande affärsmodell.

Problem med att leverera applikationer via webbläsaren

Allt eftersom webbapplikationer blivit mer komplexa så har dom börjat flytta gränserna både för webbläsarens förmåga och applikationens användbarhet. När deras popularitet växt så har dessa frågor blivit uppenbara och viktiga, och dom framhäver det faktum att det fortfarande finns betydande problem för både utvecklare och slutanvändare när dom sprider och använder applikationer i webbläsaren.

Webbläsaren skapades från början för att leverera HTML-baserade dokument. Faktiskt så har inte den grundläggande designen på webbläsaren ändrats mycket från det syftet. Denna fundamentala konflikt mellan dokument- och applikationsfokuserad funktionalitet skapar flera problem när man kör applikationer i webbläsaren.

UI i konflikt

Applikationer som körs via webbläsaren har egna andvändargränssnitt som ofta krockar med webbläsarens gränssnitt. Denna applikation i applikation-modell resulterar ofta i gränssnitt som motsäger och motarbetar varandra. Det kan i bästa fall leda till förvirring för användaren och i värsta fall till att applikationen inte fungerar. Det klassiska exemplet på detta är webbläsarens tillbakaknapp. Tillbakaknappen är bra när man navigerar mellan dokument, men fungerar inte alltid i en programkontext. Även om det finns ett antal lösningar för att komma runt det här problemet så används dom på olika sätt i olika applikationer och användare vet kanske inte om en specifik applikation stödjer tillbakaknappen eller om den kommer att stänga applikationen och få den att förlora data.

Avstånd från skrivbordet

Delvis beroende på webbens säkerhetsmodell (som begränsar åtkomst till användarens maskin) så stödjer ofta inte applikationer i webbläsaren de sorters användarinteraktioner med operativsystemet som folk förväntar sig från applikationer. Till exempel så kan du inte dra och släppa en fil till en webbläsarbaserad applikation och få den att agera mot filen. Webbapplikationen kan inte heller interagera med andra applikationer på användarens dator.

RIA:er har försökt förbättra detta genom att göra rikare, mer skrivbordslika gränssnitt möjliga i webbläsaren men har inte lyckats övervinna de grundläggande begränsningar som separationen från skrivbordet ger.

Främst en online-upplevelse

På grund av att webbapplikationer levereras från en server och inte ligger på användarens maskin så är webbapplikationer främst en online-upplevelse. Även om försök pågår med att göra nedkopplade webbapplikationer möjliga så erbjuder dom inte någon konsekvent utvecklingsmodell, klarar inte av att arbeta mellan olika webbläsare eller kräver att användaren bygger ut sin webbläsare. Dessutom kräver dom ofta att användare interagerar med och hanterar applikationen och webbläsaren på komplexa och oväntade sätt.

Minsta gemensamma nämnare

Slutligen, allt eftersom applikationer blir rikare och mer komplexa och börjar flytta gränserna för JavaScript och DHTML, så möts utvecklare oftare av olikheter i webbläsarfunktionalitet och API-implementeringar. Även om detta ofta kan övervinnas med webbläsarspecifik kod så leder det till kod som a) är svårare att underhålla och skala och b) tar tid från funktionsdriven utveckling av funktionalitet.

Även om JavaScript-ramverk är ett populärt sätt att komma åt de här problemen så kan dom bara erbjuda funktionalitet som redan finns i webbläsaren, och ofta faller dom tillbaka på den minsta gemensamma nämnaren vad gäller webbläsarfunktioner för att förenkla utvecklingsmodellen. Resultatet för JavaScript- och DHTML-baserade applikationer är en fattig användarupplevelse och interaktionsmodell samt ökade utvecklings-, testnings- och lanseringskostnader för utvecklare.

Det faktum att webbapplikationer blomstrat trots dessa nackdelar är bevis för attraktionskraften hos en plattform med en bra utvecklingsmodell som har förmågan att leverera applikationer till flera operativsystem. En plattform som erbjuder räckvidden och utvecklingsmodellen hos webbläsaren och samtidigt ger funktionaliteten och rikedomen hos en skrivbordsapplikation skulle vara det bästa från båda världar. Detta är vad Adobe AIR siktar på att erbjuda.

Introduktion till Adobe AIR

Så, vad är Adobe AIR och hur kan det göra utveckling och spridning av webbapplikationer bättre?

Adobe AIR är en plattformsöverskridande körmiljö utvecklad av Adobe som låter webbutvecklare lyfta sina existerande kunskaper om webbutveckling (som Flash, Flex, HTML, JavaScript och PDF) till att utveckla RIA:er och innehåll för skrivbordsmiljö.

Kort sagt så ger Adobe AIR en plattform mellan skrivbordet och webbläsaren som kombinerar räckvidden och enkelheten hos webbmodellen med funktionaliteten och rikedomen hos skrivbordsmodellen.

Det är viktigt att ta ett steg tillbaka och peka på vad Adobe AIR inte är. Adobe AIR är inte en vanlig skrivbordskörmiljö menad att konkurrera med applikationskörmiljöer i lägre nivåer. Adobe AIR kommer från Webben till skrivbordet och riktar sig mot webbutvecklare. Dess huvudsakliga användningsområde är att möjliggöra att webbapplikationer och RIA:er kan köras på skrivbordet. Detta är en fin men viktig distinktion för vad som driver Adobe AIR 1.0.

I sin kärna är Adobe AIR byggt ovanpå webbteknologier, vilket låter webbutvecklare utveckla för och lansera till skrivbordet med samma tekniker och utvecklingsmodeller som dom använder idag när dom utvecklar för Webben.

Huvudsakliga Adobe AIR-teknologier

Tre huvudsakliga teknologier inkluderas i Adobe AIR och dom faller in i två distinkta kategorier: applikationsteknologier och dokumentteknologier.

Huvudsakliga applikationsteknologier

Applikationsteknologier är teknologier som kan användas som grund för applikationer i Adobe AIR. Adobe AIR innehåller två huvudsakliga applikationsteknologier, HTML och Flash, vilka båda kan användas för sig själva för att bygga Adobe AIR-applikationer.

HTML/JavaScript

Den första applikationsteknologin inom Adobe AIR är HTML och JavaScript. Detta inkluderar en fullständig HTML-renderingsmotor med stöd för:

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

Ja, du läste rätt. Du behöver inte använda Flash för att bygga Adobe AIR-applikationer. Du kan bygga applikationer med full funktionalitet enbart med HTML och JavaScript. Detta förvånar ofta utvecklare som förväntar sig att Adobe AIR fokuserar enbart på Flash.

Men i grunden är Adobe AIR en körmiljö riktad mot webbutvecklare som använder webbteknologier - och vad är mer webbteknologi än HTML och JavaScript?

HTML-motorn som används av Adobe AIR är WebKit med öppen källkod. Den ligger bakom ett flertal webbläsare, som KTHML och Safari på Mac OS X.

Adobe Flash

Den andra grundläggande applikationsteknologin som Adobe AIR bygger på är Adobe Flash Player. För att vara exakt så är Adobe AIR byggt ovanpå Adobe Flash Player 9 som inkluderar det ECMAScript-baserade programmeringsspråket ActionScript 3, liksom den virtuella maskinen Tamarin med öppen källkod (som kommer användas för att tolka JavaScript i framtida versioner av Firefox).

Inte nog med att all nuvarande funktionalitet i Flash Player API:et är tillgängligt i Adobe AIR, några av dom API:erna har byggts ut och/eller förbättrats. En del av den funktionalitet som Flash Player ger till Adobe AIR är:

• Just in time-tolkad ActionScript-motor för hög applikationsprestanda
• Full nätverksstack inklusive HTTP och RTMP, liksom Binary och XML-sockets
• Fullständig vektorbaserad renderingsmotor och uppritnings-API:er
• Utförligt multimediastöd inklusive bitmappar, vektorer, ljud och video

Naturligtvis är Adobe Flex 3 RIA-ramverket byggt ovanpå ActionScript 3, vilket betyder att du till fullo kan utnyttja alla fördelar och funktioner som Flex erbjuder för att bygga Adobe AIR-applikationer.

Huvudsakliga dokumentteknologier

Dokumentteknologier i Adobe AIR syftar på teknologier för att rendera och interagera med elektroniska dokument.

PDF och HTML är dom huvudsakliga dokumentteknologierna som är tillgängliga i Adobe AIR.

PDF

Portable Document Format (PDF) är webbstandard för att leverera och visa upp elektroniska dokument på Webben.

PDF-funktionalitet kräver att Adobe Reader 5.1 är installerat på användarens dator. Om Adobe Reader 5.1 är installerat så kan Adobe AIR-applikationer använda alla de funktioner som Reader även erbjuder en webbläsare.

HTML

HTML skapades ursprungligen som en dokumentteknologi och erbjuder idag en rik och robust kontroll över innehåll och textframställning. HTML kan användas som dokumentteknologi i Adobe AIR - både i en befintlig HTML-applikation och i en Flash-baserad applikation.

Vad innehåller en Adobe AIR-applikation?

När vi nu vet vilka teknologier som finns tillgängliga för applikationer som kör ovanpå Adobe AIR (se fig. 1-1) så ska vi titta på hur dom teknologierna kan kombineras för att bygga en Adobe AIR-applikation.

Applikationer kan bestå av följande teknologikombinationer: * Enbart HTML/JavaScript. HTML/JavaScript-baserad med Flash-innehåll. Enbart Flash (även Flex). Flash-baserad med HTML-innehåll. Alla kombinationer kan utnyttja PDF-innehåll.

Teknologiintegrering och skriptöverbryggning

Eftersom WebKit och Adobe Flash Player inkluderas i körmiljön så är dom integrerade med varandra på en väldigt låg nivå. Till exempel: när HTML inkluderas i Flash-innehåll så renderas det med Flashs grafikpipeline vilket bland annat betyder att allt du kan göra med en bitmapp i Flash Player (oskärpa, rotation, formförändring etc.) kan du ockå göra med HTML.

Den här integrationen på låg nivå gäller också skriptmotorerna som kör ActionScript och JavaScript i Adobe AIR. Adobe AIR möjliggör skriptöverbryggning mellan de två språken och miljöerna vilket gör följande möjligt:

[IMAGE] Fig. 1-1. Adobe AIR-applikationers struktur

• JavaScript-kod kan kalla på Adobe AIR, Flash Player och ActionScript API:er.
• ActionScript-kod kan kalla på JavaScript API:er.
• ActionScript-kod kan direkt manipulera HTML-DOM:en.
• Händelseregistering kan utföras åt båda hållen mellan JavaScript och ActionScript.

Notera att skriptöverbryggning använder "skicka som referens", så när du skickar en objektinstans från JavaScript till ActionScript (eller vice versa) så påverkar ändringar på instansen i en miljö även instansen i den andra miljön. Bland annat gör detta det möjligt att instansiera och använda Flash Players API:er direkt från JavaScript, eller att registrera och lyssna efter händelser.

Den här skriptöverbryggningen på låg nivå mellan de två miljöerna gör det riktigt enkelt för utvecklare att skapa applikationer som är en kombination av både HTML och Flash.

Resultatet av allt detta är att du som utvecklare redan har alla kunskaper som krävs för att bygga en Adobe AIR-applikation.

Adobe AIR-funktionalitet

Om Adobe AIR inte hade erbjudit extra funktionalitet och API:er utan bara låtit webbapplikationer köra på skrivbordet så skulle det inte vara riktigt lika spännande. Som tur är så erbjuder Adobe AIR ett rikt utbud av programmerings-API:er liksom nära integration med skrivbordet, vilket låter utvecklare bygga applikationer som drar nytta av det faktum att dom kör på användarens skrivbord.

Adobe AIR-API:er

Förutom all funktionalitet och API:er som redan erbjuds av Flash Player och WebKit-motorn så ger Adobe AIR utökad funktionalitet och API:er.

En del av funktionaliteten inkluderar, men är inte begränsad till:

• Fullständig API för fil-I/O
• Fullständig API för programfönster
• Fullständig API för systemmenyer
• API:er för uppkopplad/nedkopplad som känner av när nätverksuppkopplingen ändrats
• Fullständig kontroll över fönster-GUI
• API:er för lokal lagring/inställningar
• API:er för systemmeddelanden som knyts ihop med OS-specifika meddelandemekanismer (inte implementerad i beta)
• API:er för applikationsuppdatering
• Inbäddad SQLite-databas

Notera att funktionalitet kan implementeras i körmiljön eller på ramverkslagret (i Flex och JavaScript), eller genom en kombination av båda.

Skrivbordsintegration med Adobe AIR

Som tidigare diskuterats så kan inte alltid applikationer som körs via webbläsaren erbjuda samma användarupplevelse som skrivbordsapplikationer. Det gör att applikationer kan kännas otympliga för användaren att interagera med, eftersom dom inte tillåter den typ av applikationsinteraktioner som användaren är van vid.

Eftersom en AIR-applikation är en skrivbordsapplikation så är det möjligt att erbjuda samma typer av applikationsinteraktion och upplevelse som användaren förväntar sig av en applikation. Den här funktionaliteten inkluderar, men är inte begränsad till:

• Lämpliga installations-/avinstallationsprocedurer
• Genvägar till installationsplatser på skrivbordet
• Rikt stöd för dra-och-släpp:
  • Mellan operativsystemet och AIR-applikationer
  • Mellan AIR-applikationer
  • Mellan lokala applikationer och AIR-applikationer
• Rikt stöd för urklipp
• Systemmeddelanden
• Lokala ikoner

Väl installerad är en AIR-applikation bara ännu en lokal applikation, vilket betyder att operativsystemet och användarna kan interagera med den på samma sätt som med andra applikationer. Till exempel, saker som applikations-prefetch på OS-nivå och applikationsbyte fungerar på samma sätt med Adobe AIR-applikationer som med lokala applikationer.

Målet är att slutanvändaren inte behöver veta att han kör en AIR-applikation för att kunna använda den. Han borde kunna interagera med applikationen på samma sätt som han interagerar med andra applikationer som kör på skrivbordet.

Säkerhetsmodell

Allt det här pratet om skrivbordsfunktionalitet lyfter fram en viktig fråga: hur är det med säkerheten? På grund av att Adobe AIR-applikationer har tillgång till lokala resurser, kan dom teoretiskt sett göra skada?

Först och främst är det viktigt att notera att Adobe AIR kör ovanpå operativsystemets säkerhetslager. Det finns inget sätt att komma runt eller undergräva den säkerheten. Det här är viktigt för det betyder att Adobe AIR-applikationer bara kan jobba inom de rättigheter som de får från operativsystemet, samt alla nuvarande och nya säkerhetsåtgärder som OSet implementerar.

För att köra en Adobe AIR-applikation måste användaren ladda ner applikationen till skrivbordet, gå genom en installationsprocedur och sedan köra applikationen. Detta är en upplevelse som är väldigt lik den att ladda ner och köra en skrivbordsapplikation. Likheten är ingen slump. Adobe AIR-applikationer kör i en fundamentalt annorlunda säkerhetskontext än applikationer i en webbläsare. Det är en säkerhetskontext som ligger närmare en skrivbordsapplikation än en webbapplikation.

För att säkerställa säker surfning så begränsar webbläsarens säkerhetsmodell alla I/O-möjligheter för webbapplikationer. Det innebär begränsad möjlighet att jobba med lokala resurser, vilka nätverksresurser som är tillgängliga och begränsat användargränssnitt. Webbläsaren tillåter bara applikationer att ansluta till data som associeras med (och vanligen erbjuds av) en server på samma webbdomän. Dessutom så ger webbläsaren användaren ett förlitande gränssnitt för att förstå applikationens ursprung och kontrollera dess tillstånd. Den här modellen är tillräcklig för applikationer som är anslutna till enbart en tjänsteoperatör och litar på den tjänsten för datasynkronisering och lagring.

En del webbutvecklare har också sträckt ut webbläsarens säkerhetsmodell genom att integrera data från flera källor och/eller experimentera med användargränssnitt som inte är konsekventa med webbläsarens. En del sådana applikationer kräver en insticksmodul i webbläsaren med förmågor som webbläsare idag inte har. Andra drar nytta av webbläsaregenskaper som användarmeddelanden eller egeninställda säkerhetskonfigureringar för att tillåta mer eller mindre säkerhet hos applikationer från specifika domäner. Dessa mekanismer tillåter webbutvecklare att bygga kraftfullare applikationer, men dom belastar också webbläsarens säkerhetsmodell.

Istället för att försöka bygga ut webbläsaren så att den kan agera både webbläsare och flexibel programkörmiljö så erbjuder Adobe AIR en flexibel körmiljö för att bygga applikationer med webbteknologier. Adobe AIR låter webbutvecklare bygga applikationer som kombinerar data från flera källor, ger användare kontroll över var och hur deras data lagras och producerar användarupplevelser som inte är möjliga i webbläsarens gränssnitt. Eftersom Adobe AIR-applikationer måste installeras på skrivbordet och kräver att användaren litar på dem så kan Adobe AIR-applikationer på ett säkert sätt utnyttja dom förmågorna. Webbläsarbaserade applikationer kan inte garanteras dessa förmågor om webbläsaren ska kunna fortsätta att uppfylla sin roll som en säker applikation för att surfa på Webben.

Adobe AIRs säkerhetsmodell har flera implikationer för applikationsutvecklare och användare. För applikationsutvecklare betyder den att innehåll i en installerad Adobe AIR-applikation har möjligheter som inte bör exponeras för icke-förlitande innehåll, inklusive filer från Webben. Körmiljön har flertalet egenskaper som är framtagna för att stärka den skillnaden och hjälpa utvecklare att bygga applikationer med säkerhetspraxis.

Det här betyder också att användare inte borde installera Adobe AIR-applikationer från källor dom inte litar på. Detta är snarlikt nuvarande praxis för skrivbordsapplikationer och insticksfiler för webbläsare. Många applikationer och webbinnehåll kräver att en insticksfil (som Flash Player eller Apple Quicktime) installeras för att fungera. Webbläsaren Firefox har ett lättillgängligt utbyggnadslager som i grund och botten låter alla utvecklare bygga ut webbläsaren. Dessa applikationer, insticksfiler och utbyggnader kan utföra potentiellt skadliga handlingar och kräver därför att användaren litar på innehållets källa.

Slutligen, en av möjligheterna som kommer att inkluderas i Adobe AIR 1.0-publiceringen är möjligheten för körmiljön att verifiera en applikations utgivares identitet. Användare bör noga överväga ifall dom vill lita på en applikations utgivare, liksom ifall dom vill installera en applikation som inte har signerats.

Adobe AIRs utvecklingsverktyg

Ett av skälen till att webbapplikationer varit så framgångsrika är att dom låter utvecklare enkelt lansera applikationer som användare kan köra oberoende av operativsystem. Vare sig på Mac, Windows, Linux, Solaris, eller mobiltelefoner så ger webbapplikationer räckvidd.

Men framgången baseras inte enbart på plattformsöverskridande lansering utan även på utvecklingsmijöns plattformsöverskridande egenskap. Den låter alla utvecklare utnyttja och utveckla för teknologin. Varken körmiljön eller utvecklingsverktygen är knutna till ett OS.

Det samma gäller Adobe AIR. Inte nog med att Adobe AIR erbjuder den plattformsöverskridande räckvidden hos webbapplikationer utan, precis lika viktigt, så kan Adobe AIR-applikationer utvecklas och paketeras under i stort sett vilket OS som helst.

Eftersom Adobe AIR-applikationer är byggda med existerande webbteknologier som HTML och Flash så kan du använda samma verktyg som du använder för att skapa webbläsarbaserat innehåll till att skapa Adobe AIR-applikationer. Adobe AIR-SDK:et ger två gratis kommandotolkverktyg som gör det möjligt att testa, debugga och paketera Adobe AIR-applikationer med i stort sett vilket webbutvecklings- och designverktyg som helst.

ADL	Låter Adobe AIR-applikationer köras utan att först ha installerats
ADR	Paketerar Adobe AIR-applikationer till distributionsvänliga installationspaket

Även om Adobe har lagt till stöd för att skapa Adobe AIR-innehåll i sina webbutvecklings- och designverktyg (inklusive Adobe Flex Builder, Adobe Flash CS3 och Adobe Dreamweaver) så krävs inga Adobe-program för att skapa applikationer. Med Adobe AIRs kommandotolkverktyg kan du skapa en Adobe AIR-applikation utan några webbutvecklingsverktyg. Du kan använda samma webbutvecklings- och designverktyg som du redan använder idag.

Är Adobe AIR slutet för webbapplikationer i webbläsaren?

Så, nu kanske du säger för dig själv "Åh, Adobe AIR låter toppen! Varför skulle någon någonsin vilja köra en applikation i webbläsaren igen? Är Adobe AIR slutet på webbapplikationer inom webbläsaren?".

Nej.

Jag upprepar:

Nej.

Adobe AIR åtgärdar många problem med att lansera webbapplikationer via webbläsaren. Men det finns fortfarande fördelar med att lansera i webbläsaren. Det faktum att det finns så många webbapplikationer trots nackdelarna vi diskuterade tidigare är bevis för fördelarna med att köra i webbläsaren. Så länge fördelarna överväger nackdelarna kommer utvecklare fortsätta att utveckla sina applikationer för webbläsaren.

Men det är inte nödvändigtvis fråga om antingen/eller. Eftersom Adobe AIR-applikationer är byggda med webbteknologier kan applikationen du lanserar i webbläsaren snabbt göras om till en Adobe AIR-applikation. Du kan ha en webbaserad version som erbjuder webbläsarens fördelar och samtidigt en AIR-baserad version som drar nytta av att köra på skrivbordet. Båda versionerna kan utnyttja samma teknologier, språk och grundkod. Faktiskt så är några av de populäraste tidiga Adobe AIR-applikationerna, som Fine-tune Desktop och eBay Desktop, komplement till existerande webbapplikationer.

Adobe AIR-applikationer komplementerar webbapplikationer. Dom ersätter dom inte.