Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

Adobe AIR

Autor: Piotr Karpiuk o wtorek 21. Wrzesień 2010

Interaktywna galeria aplikacji AIR

Interaktywna galeria aplikacji AIR

Adobe AIR (skrót od Adobe Integrated Runtime) jest międzyplatformowym (Windows, Mac OS X, Linux, niebawem Android), darmowym środowiskiem uruchomieniowym wykonującym zintegrowane z pulpitem aplikacje RIA, wykorzystujące technologie WWW takie jak XHTML, CSS, JavaScript, Ajax, Flash, XML, PDF. Produkt jest dość nowy (pierwsza wersja pojawiła się w 2008 roku) i niedawno ukazała się wersja 2.0. Wykorzystują go m.in. firmy NASDAQ i AOL.

Wady przeglądarki WWW
Przeglądarkę WWW początkowo zaprojektowano z myślą o wyświetlaniu dokumentów HTML, a podstawowa struktura wszystkich wiodących przeglądarek nadal odzwierciedla to pierwotne przeznaczenie, co powoduje pewne ograniczenia i konflikty, np.

  • interfejs użytkownika aplikacji (skróty klawiaturowe, menu kontekstowe) może kolidować z interfejsem przeglądarki, czego jaskrawym przejawem jest przycisk Wstecz,
  • programista aplikacji WWW nie ma kontroli nad współpracą przeglądarki z innymi procesami na komputerze użytkownika,
  • aplikacja nie obsługuje pewnych interakcji z pulpitem do których użytkownicy są przyzwyczajeni (np. przeciąganie plików między różnymi aplikacjami systemu operacyjnego i pulpitem),
  • brak możliwości pracowania offline i kontroli nad danymi przechowywanymi na dysku klienta,
  • ciągle jeszcze dające się we znaki różnice w implementacji standardów (DOM, HTML, CSS) pomiędzy przeglądarkami co wymusza politykę „najmniejszego wspólnego mianownika” i wpływa ujemnie na oferowane możliwości i komplikuje deweloperkę/testy.

Lekarstwo?
Wyobraźmy sobie platformę uruchomieniową sytuowaną gdzieś pomiędzy pulpitem a przeglądarką, której aplikacje zapewniają wrażenia i funkcjonalność zbliżone do tradycyjnych programów instalowanych w komputerze, a jednocześnie zachowują międzyplatformową naturę sieci WWW i wykorzystują model programistyczny standardowej przeglądarki WWW.

Adobe AIR poza większością funkcji oferowanych przez zwykłe przeglądarki pozwala na:

  • wygodny dostęp do pamięci trwałej u klienta na kilka sposobów: bezpośredni dostęp do systemu plików (pełny interfejs API plikowego wejścia/wyjścia), podręczna SQLowa baza danych (SQLite), szyfrowana przestrzeń dyskowa,
  • pracę offline (aplikacja AIR jest instalowana w systemie podobnie jak zwykła aplikacja pulpitu),
  • otwieranie popularnych formatów plików (pdf, doc, ppt, mp3) przy użyciu odpowiadających im natywnych aplikacji skojarzonych z rozszerzeniem (np. Adobe Acrobat, MS Word, MS PowerPaint, iTunes itp.),
  • uruchamianie zewnętrznych (natywnych) procesów i komunikację z nimi poprzez standardowe wejście/wyjście,
  • tworzenie instalatorów (i deinstalatorów) przeznaczonych dla określonych systemów operacyjnych (użytkownik ściąga tylko jeden plik z rozszerzeniem *.air), uruchamianie aplikacji AIR poprzez kliknięcie ikonki skrótu na pulpicie,
  • pełną obsługę schowka systemu operacyjnego i mechanizmu drag & drop (przeciąganie myszką obiektów między aplikacjami systemu operacyjnego),
  • tworzenie i kontrolowanie natywnych okien i menu (np. żeby okno było zawsze na wierzchu lub otwierało się w trybie pełnoekranowym), obsługa dokowania oraz ikon w zasobniku systemowym,
  • nagrywanie dźwięku lokalnie bez dostępu do serwera,
  • komunikację po gniazdach TCP/UDP (w tym z pomocą TLS lub SSL) z innymi procesami na tej samej lub innej maszynie,
  • przejęcie kontroli nad drukowaniem (wybór drukarki, rozmiaru papieru, liczby egzemplarzy, czy drukarka jest kolorowa, czy drukowanie trwa itp.), możliwość druku zarówno bitmapowego jak i wektorowego,
  • obsługę Multi-Touch (obecnie tylko Windows 7) i gestów na komputerach które udostępniają odpowiedni sprzęt,
  • jeśli użytkownik ma zainstalowanego Acrobat Readera, to aplikacja AIR może wykorzystać do renderowania PDFów wszystkie funkcje, jakie Reader eksponuje działając w przeglądarce WWW.

AIR oferuje wsparcie językowe dla wielu języków, w tym polskiego i chińskiego.

W rezultacie użytkownik nie musi nawet wiedzieć że uruchomił aplikację Adobe AIR i może pracować z nią w taki sam sposób jak z każdą inną aplikacją działającą na pulpicie. Zauważ, że aplikacja AIR w ogóle nie musi mieć reprezentacji graficznej.

Nie dajmy się jednak zbytnio omamić reklamami, które nie eksponują należycie faktu, że trzeba zainstalować środowisko Adobe AIR na każdej końcówce u klienta. Można to nieco złagodzić wykorzystując technologię Seamless Install, która umożliwia taką sztuczkę, że kliknięcie na obrazku w przeglądarce pozwala użytkownikowi zainstalować z przeglądarki aplikację AIR (plik z rozszerzeniem *.air) wraz ze środowiskiem Adobe AIR.

Zasadniczo, możemy spojrzeć na możliwości AIR jak na nadzbiór tego co oferuje standardowa przeglądarka. Wg Adobe’a AIR umożliwia wykonywanie już istniejących, przeglądarkowych aplikacji WWW na pulpicie. Jest to jednak slogan reklamowy, w praktyce mogą być konieczne pewne przeróbki lub nawet takie przejście może się okazać trudne – np. „ze względu na różnice w modelu bezpieczeństwa między środowiskiem przeglądarki a AIR do większości popularnych szkieletów JavaScriptu trzeba dodać obsługę Adobe AIR aby mogły one działać w kontekście aplikacji AIR.” W szczególności wspierane obecnie frameworki to Dojo, Ext JS, jQuery, MochiKit, MooTools, Spry. Można więc mówić o pisaniu dwóch wersji tej samej aplikacji (dla AIR i dla zwykłej przeglądarki) wykorzystujących wspólny kod, ale nie o masowym przechodzeniu użytkowników z przeglądarek na Adobe AIR.

Pod maską
AIR wykorzystuje renderer HTMLa WebKit – ten sam co przeglądarka Safari i Chrome. Niestety test wydajności SunSpider wykazuje że interpreter JavaScriptu w AIR 2.0 jest przeszło trzykrotnie wolniejszy od obecnego w Google Chrome 6.0. O ile w przeglądarce plugin Flash jest osadzony w rendererze HTMLa jako zewnętrzny komponent, to w AIR są to elementy zintegrowane ze sobą na bardzo niskim poziomie. Integracja dotyczy również mechanizmów skryptowych (JavaScript i ActionScript) w Adobe AIR, tzn. w aplikacjach AIR wywołania FlashPlayera i ActionScriptu są dostępne na poziomie języka JavaScript, kod ActionScriptu może wywoływać funkcje JavaScriptu (w tym bezpośrednio manipulować modelem DOM dokumentu HTML), tak więc np. obsługę zdarzenia ActionScript można zaimplementować w JavaScripcie.
Jest to możliwe dzięki temu że oba języki skryptowe są silnie spowinowacone (dużym wspólnym mianownikiem jest ECMAScript), mogą współdzielić garbage collector, stertę itp. a więc przekazywanie obiektów pomiędzy językami następuje poprzez referencję a nie kopiowanie.
Co więcej, kiedy kod HTML jest osadzony w treści Flash, to w rzeczywistości jest renderowany przez potok wyświetlania Flasha, co oznacza m.in. że wszystko, co można zrobić z mapą bitową we Flash Playerze (rozmazać, obrócić itp.) można również zrobić z treścią HTML.

Deweloperka aplikacji AIR
W zależności od preferowanych przez dewelopera technologii można użyć różnych narzędzi wspomagających:

Model bezpieczeństwa
Ponieważ aplikacja AIR może na komputerze klienta wyrządzić dużo więcej szkód niż aplikacja WWW w przeglądarce, więc każda aplikacja AIR musi być cyfrowo podpisana przez dostawcę, a jej instalacja wymaga przejścia typowego „rytuału” instalacji tak aby użytkownik był świadomy tego procesu.

Wdrażanie aplikacji WWW na poziomie pulpitu niesie ze sobą szereg potencjalnych niebezpieczeństw. Z jednej strony aplikacja AIR ma szeroki dostęp do zasobów systemu operacyjnego klienta, a z drugiej sięga po techniki webowe które często wykorzystują kod HTML/JavaScript/ActionScript niewiadomego pochodzenia.

W rezultacie model bezpieczeństwa środowiska AIR istotnie różni się od tego zawartego w przeglądarce WWW. W AIR mamy dwie piaskownice:

  • Piaskownica aplikacji: domyślna dla każdej aplikacji AIR; zabrania dostępu do uprzywilejowanego API umożliwiającego dynamiczne ładowanie kodu z zewnątrz, dynamicznego generowania kodu (funkcja eval języków skryptowych – częsty winowajca udanych ataków cross-site scripting XSS), oraz wstawiania dowolnego kawałka HTMLa do drzewa DOM. W tej piaskownicy może się znaleźć tylko kod załadowany z katalogu domowego aplikacji. Zapobiega to sytuacjom gdy np. aplikacja próbuje po cichu bez wiedzy użytkownika się zaktualizować, lub doinstalować pluginy/rozszerzenia.
  • Piaskownica non-application: pozostały kod (ładowany lokalnie i zdalnie); nie ma on bezpośredniego dostępu do API platformy AIR i zasadniczo dotyczą go te same obostrzenia co w standardowych przeglądarkach WWW. W takiej piaskownicy mogą się np. wykonywać pluginy aplikacji pobierane od niezależnych dostawców.

Oczywiście w pewnych przypadkach deweloper może się upierać przy konieczności użycia eval – pozwala na to komunikacja pomiędzy piaskownicami (SandboxBridge API) która sprowadza się do serializacji i deserializacji obiektów. Można przekazać łańcuch z piaskownicy aplikacji do piaskownicy non-application, tam wykonać eval (w bezpiecznym środowisku) i zwrócić wynik z powrotem do piaskownicy aplikacji.

Adobe AIR, 5.0 out of 5 based on 1 rating
Share and Enjoy:
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Śledzik
  • Blip
  • Blogger.com
  • Gadu-Gadu Live
  • LinkedIn
  • MySpace
  • Wykop

Zostaw komentarz

XHTML: Możesz użyć następujących tagów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>