Přejít k navigační liště

Zdroják » Různé » Je Silverlight 3 konkurencí pro Adobe AIR?

Je Silverlight 3 konkurencí pro Adobe AIR?

Články Různé

Nedávno byl vydán Silverlight 3, který vedle dlouhé řady významných vylepšení přidal i podporu pro běh aplikací mimo prohlížeč (out of browser, OOB), díky čemuž je občas přirovnáván k běhovému prostředí Adobe AIR. Ačkoliv podobnosti existují, v současnosti stále převažují především rozdíly, na které bychom chtěli v tomto článku poukázat.

Podobnosti

Jak Adobe AIR, tak Silverlight 3 umožňují vývojářům tvořit aplikace, které se nainstalují na uživatelův počítač a lze je pak spustit nezávisle na prohlížeči (a nedejbože i při nedostupnosti internetu). Obě technologie umožňují aplikaci vytvořit v relativně komfortním vývojovém prostředí – v případě AIRu je to technologie Adobe Flex (případně DHTML, ačkoliv to je méně časté), nebo v .NETu, pokud mluvíme o Silverlightu. Zhruba tady ale podobnosti končí, pojďme se nyní podívat na ty hlavní rozdíly.

Bezpečnostní sandbox

Zcela zásadní rozdíl je v tom, co si aplikace může na uživatelově počítači „dovolit“.

Aplikace napsaná v Adobe AIR má plný přístup k lokálním zdrojům, což v principu znamená, že na disk může ukládat nebo z něj mazat cokoliv, k čemu má uživatelský účet práva (pokud na Windows uživatel pracuje pod administrátorským účtem, AIR aplikace má přístup prakticky ke všemu). Principiálně se tedy AIR aplikace chovají jako běžné desktopové aplikace a AIR bychom tak nejlépe mohli přirovnat k běhovým prostředím typu Java, .NET a podobně.

Silverlight OOB naproti tomu běží ve stejném bezpečnostním sandboxu jako běžná Silverlight aplikace. To v praxi znamená, že „instalací“ Silverlight OOB aplikace uživatel neriskuje vůbec nic – taková aplikace nemá přístup k jeho dokumentům ani k žádným jiným lokálním souborům. Offline aplikace samozřejmě potřebuje nějaká data ukládat a načítat, ale Silverlight OOB aplikace tak může činit pouze skrze Isolated Storage, což je bezpečné úložiště izolované od zbytku filesystému. Velikost tohoto úložiště je ve výchozím stavu 25 MB (pro aplikace běžící v prohlížeči 1 MB) a uživatel ho navíc může v extrémním případě zakázat. S lokálním úložištěm to tedy není v SL OOB nijak slavné a zhruba bychom ho mohli přirovnat k trochu vylepšenému ukládání dat v cookies prohlížečů.

Adobe AIR je tedy v tomto ohledu daleko mocnější technologií, což ovšem neznamená, že by přístup Silverlightu neměl své výhody. Tou největší je, že bezpečnost je pro uživatele zajištěna přímo systémem, a uživatel se tedy nemusí „bát“ Silverlight aplikace instalovat – neriskuje prakticky nic. Obě technologie tedy mají své výhody i nevýhody a nelze jednoznačně říci, která je „lepší“, rozdíl mezi nimi je ale na bezpečnostním poli zřejmý.

Instalace, aktualizace

S rozdílným přístupem k lokálním zdrojům jde ruku v ruce jiný způsob instalace a aktualizace. Takto vypadá instalace SL OOB aplikace:

Instalace SL
Instalace Silverlight OOB aplikace

Vše je velmi jednoduché a nic moc se nastavit nedá. V případě Adobe AIR většinou kliknete na tzv. install badge na nějaké webové stránce, čímž se spustí download a následná instalace podobně, jako např. u technologie ClickOnce. Během instalace si na Vistách zobrazí UAC dialog (záleží na konfiguraci), takže instalace vypadá skutečně jako u každé jiné desktopové aplikace.

Instalace AIR
Instalace AIR aplikace

Rozdíl je podobně vidět i u aktualizace – zatímco v případě SL OOB stačí novou verzi nahrát na server a Silverlight se pak už o vše postará sám, v případě AIR aplikace je za aktualizaci zodpovědný programátor, i když v nejnovější verzi AIR 1.5 s touto úlohou výrazně pomáhá AIR Update Framework.

Pohled vývojáře

Pokud se v Microsoftu zeptáte, jakou technologií chtějí Adobe AIR konkurovat, dostane se vám odpovědi, že oni mají WPF a plný .NET, který nejen že možnosti AIRu vyrovnává, ale mnohanásobně je předbíhá. To je pravda – v .NETu můžete dělat prakticky cokoliv a dostupná API jsou daleko za hranicemi relativně omezených možností Adobe AIR. Na druhou stranu AIR přišlo s něčím úžasným – můžete vzít webovou aplikaci a prakticky bez úprav z ní udělat aplikaci desktopovou. A to „prakticky bez úprav“ myslím doslova – ve Flexovém kódu stačí změnit root tag vašeho MXML souboru z <Application> na <WindowedAppli­cation>. Ba co víc – váš kód můžete vyextrahovat do Flexových knihoven, které pak můžete bez rekompilace používat jak ve webových, tak v AIR aplikacích. Funguje zde tedy nejen dokonalá kompatibilita na úrovni zdrojového kódu, ale i kompatibilita binární, což je z vývojářského hlediska skvělá věc.

Ve světě Silverlightu/WPF je situace trochu jiná. Silverlight obsahuje pouze podmnožinu knihoven z plného .NETu (pochopitelně) a i technologie pro definici uživatelského rozhraní není s WPF zcela kompatibilní. Dokonce se ani nejedná o čistou podmnožinu, některé věci se prostě ve WPF a v Silverlightu řeší trochu jinak (viz Microsoft WPF-Silverlight Comparison Whitepaper). Ve výsledku jsou tak WPF a Silverlight podobné, ale ne vzájemně zcela kompatibilní technologie.

Pokud tedy vývojářský pohled shrnu, ve světě Flexu / Flash Playeru / Adobe AIR neřešíte, pro které běhové prostředí vyvíjíte. AIR přirozeně přidává například API pro práci s filesystémem a podobně, ale pokud zůstáváte u základních věcí, jako je zobrazování uživatelského rozhraní, tahání dat ze serveru, zpracovávání uživatelských událostí a podobně, je ve světě Flexu vývoj pro web a pro desktop naprosto totožný. Konvertovat aplikaci z webové na desktopovou je triviální a totéž platí i v obráceném směru, pokud nebylo použito API specifických pro AIR.

Ve světě Silverlightu a WPF zatím tato triviální konverze z webu na desktop neexistuje. Samozřejmě v obou světech používáte .NET, takže řada věcí je podobných nebo i stejných, ale na rozdíly pořád musíte myslet. Při konverzi ze Silverlightu do WPF by měla být cesta poměrně přímočará (i když stále klikatější než v případě Flexu), ovšem opačně můžete na problémy narazit daleko snáz, protože při programování proti plnému .NET Frameworku patrně budete chtít používat celou jeho sílu, která logicky v Silverlightu není k dispozici. Zde bude záležet aplikace od aplikaci, jak moc práce zde bude, nicméně zde už můžeme směle hovořit o „portování“ aplikace namísto její „konverze“.

Technické rozdíly mezi SL OOB a Adobe AIR

I přes popis rozdílů výše mohou a budou existovat aplikace, kde volba mezi SL OOB a Adobe AIR bude validní a zcela smysluplná, například když chci nabídnout uživateli určitou možnost instalace aplikace lokálně, ale přitom prakticky nepotřebuji žádné persistentní úložiště (Twitter čtečka je dobrým příkladem). V takovém případě je dobré upozornit ještě na některé další, spíše technické rozdíly mezi oběma běhovými prostředími:

  • SL OOB nepodporuje notifikaci v systémové oblasti u hodin, AIR ano.
  • SL OOB nepodporuje více oken běžící aplikace, AIR ano.
  • AIR aplikace mohou být „chrome-less“, tedy bez standardního rámečku s tlačítky zavřít, minimalizovat a podobně. SL OOB toto nepodporuje a rámeček operačního systému bude vidět vždy.
  • AIR aplikace mohou data ukládat do vestavěné SQL databáze (SQLite), SL OOB aplikace k dispozici žádnou lokální databázi nemají.
  • Mikrofon a webová kamera nejsou v současné verzi Silverlightu podporovány (jejich podpora se však očekává brzy).

Čemu se tedy Silverlight OOB nejvíc podobá?

Ačkoliv se srovnání s Adobe AIR nabízí nejvíc, podle popisu výše patrně není tím nejlepším. A přitom už na světě existují technologie, které se SL OOB podobají víc než dost: jsou jimi Mozilla Prism, Google Gears a možná některé další.

Vezměte si, co třeba taková Mozilla Prism umí: v menu kliknete na „Convert website to application“, zvolíte, kam se mají umístit zástupci a je to. Při spuštění aplikace se pak nastartuje vykreslovací jádro prohlížeče, jen chybí adresní řádek, menu a toolbar.

To je přesně, co se děje při spuštění Silverlight OOB aplikace – jakoby se nastartoval Silverlight v rámci prohlížeče, jen nevidíte ten prohlížeč. Jinak se ale aplikace chová identicky – jak po funkční, tak po bezpečnostní stránce.

Pokud tedy SL OOB má k něčemu velmi blízko, jsou to nástroje, které na dvě tři kliknutí dělají z webových „stránek“ lokální „aplikace“. Adobe AIR, jak jsem psal výše, je naopak analogií běžných desktopových systémů typu .NET nebo Java.

Výhled pro Silverlight do budoucna

Pro nás jako pro vývojáře je velmi zajímavé, kam se bude SL OOB ubírat do budoucna. Osobně bych byl velmi rád, kdyby ve světě Microsoftích technologií vznikla běhová platforma podobná Adobe AIR se všemi charakteristikami tak, jak jsou uvedeny výše, ale to je asi vzhledem k existenci plného .NETu nereálné. Podle neoficiálních zmínek vysoko postavených lidí okolo Silverlightu ale do budoucna můžeme v oblasti OOB očekávat vylepšení. Má sice i do budoucna zůstat sandboxovanou technologií, ale přístup k lokálním zdrojům se má „bezpečným“ způsobem zvětšovat. Zatím lze jen hádat, co si pod tím představit, ale například nějaké zaručené lokální úložiště s garantovanou velikostí nebo třeba embedded SQL databáze pro potřeby aplikace by mohly podstatně rozšířit možnosti aplikací, aniž by byla ohrožena bezpečnost uživatelových dat. Nyní ale opravdu nezbývá, než si počkat, s čím Microsoft v příštích verzích Silverlightu přijde.

Shrnutí

Na závěr tabulka hlavních rozdílů mezi SL OOB a Adobe AIR:

Rozdíly mezi SL OOB a Adobe AIR
Silverlight OOB Adobe AIR
Bezpečnost Aplikace nemá přístup k datům uživatele, běží v sandboxu Aplikace má plný přístup k lokálním datům
Vývojový model Identický pro web a OOB, ale ne zcela kompatibilní pro web a desktop Identický pro web a desktop
Instalace Snadná Komplexnější, podobná běžné instalaci desktopové aplikace
Aktualizace Automatická Musí být naprogramovaná vývojářem, pomáhá s ní AIR Update Framework
Bohatost API Menší (i když roste s každou verzí) Větší

Pokud bych měl úplným závěrem odpovědět na otázku z názvu článku, řekl bych: Ne, Silverlight OOB není konkurencí Adobe AIR, stejně jako AIR není konkurencí OOB. Využití obou technologií se příliš nepřekrývá a do budoucna asi ani nebude.

Komentáře

Subscribe
Upozornit na
guest
19 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Honza

Škoda, že ve srovnání chybí JavaFX, když už jsme u těch RIA
platforem.

Martin Malý

Pokud máte s JavaFX zkušenosti a dokázal byste takový článek napsat,
budu velmi rád. Mail je „redakce“ zavináč „zdrojak.cz“, tak pokud
máte k tématu co říct, tak se mi, prosím, ozvěte. Děkuji.

jiravanet

Ahoj, zmiňoval jsi, že výhodou Flex aplikace je, že můžeš přepsat jen
hlavní root tag a máš AIR aplikaci. V ten okamžik se však nabízí
otázka, zda tedy využiješ všech výhod Flex aplikace i na desktopu.
Nepředpokládám, že v případě Flex web aplikace budeš mít přístup
k filesystému a tak ani povaha oné aplikace nebude taková, aby filesystém
používala – což je zmiňováno, jako velké plus pro AIR.
Tudíž pokud se rozhodnu, že vytvořím Flex aplikaci, bude nejspíše
využívat nějaký webový service, se kterým bude komunikovat. Ano, pak mám
velice snadnou úlohu v převedení takové aplikace taktéž na desktop
uživatele, obdobně se bude chovat i SL3 OOB. Což jsi sám zmiňoval
v článku.
Potom mi ale přijde tato věta Ve světě Silverlightu a WPF zatím tato
triviální konverze z webu na desktop neexistuje
pochybná, neboť na
stejné úrovni využití web aplikace bude SL na stejné startovní čáře a
nejspíše i ve stejný čas u cíle, neboť z velkého .net fw nebude
potřebovat nic navíc.
Samozřejmě je pěkné, že pro Flex vývojáře bude velice snadné
překonvertovat jeho web aplikaci do AIR a třeba ji doplnit, aniž by musel
zasahovat do UI – což při rozšíření stejně nějakým způsobem bude
muset udělat. V tomto je SL a WPF nejednotné a doufám, že se naplní
vyřčené a WPF se k SL v deklaraci přiblíží.
Díky
 –J.

jiravanet

Takto podáno to vyznívá celkem jasně a pokud to rozdělení beru tak, jak
jsi jej naznačil a s technologií, kterou jsi použil, nemohu nic namítat.
Záměrně však zmiňuji to, že se jedná jen o srovnávané technologie,
tedy čisté WPF a SL, protože je tady ještě XBAP a ve spojení s Client
profile by měl být vhodným prostředníkem právě pro ty webově desktopové
aplikace. Při jeho využití je také možné – zjednodušeně řečeno –
pouhou změnou z <Window> na <Page> přejít z desktopu na web.
Nejsem si však jist, že MS právě XBAPu přisuzuje takovou roli, jakou by
v takovýchto srovnáních mohl mít. Přitom by v některých situacích mohl
být zdatným konkurentem, možná i vítězem. To však většinou musí
posoudit až vývojář/PM a obchodník vhodně prodat klientovi.
Díky
 –J.

jiravanet

To určitě ano, ale ten deployment model se taktéž změní. Pokud
použiješ Page a vytvoříš XBAP, potom můžeš běžet uvnitř UA
prohlížeče, kdežto s Window toto nejde. To že mohu běžet jen na Windows
jsem tak nějak zanedbal, jelikož jsi zmiňoval samotné WPF.
V tomto směru mi právě Flex pro web a AIR pro desktop přijde přirovnáním
blíže právě vývoji XBAP aplikace (byť jen pro Win) – a možná jen mě
;-)
Na druhou stranu jsem rád, že existuje více možností a alternativ, alespoň
se dá klientovi nabídnout přesně to, co potřebuje a právě proto jsem
rád, že takováto srovnání existují, neboť dávají příležitost
k posouzení vhodnosti té které technologie.

Michal Blaha

Borku,zapomel jsi do rozdilu uvest podporovane operacni systemy.

Zda ma AIR take navrh. SL3: Win XP SP2 +; Mac 10.4+; (nenasel jsem oficialni
seznam, toto je vyber z nalezenych info na netu)

AIR: WinXP+, Max 10.4+, Fedora 8, Ubuntu 7.10, openSUSE 10.3

Michal Blaha

Zminil bych take velikost downloadovaneho runtime (pri prvni instalaci).

SL3: 40MB (Win) Air: 15MB (Win)

Za mne je SL3 zklamani ve dvou – v clanku zminenych – rovinach.

  1. OOB je patvar, ktery je k nicemu. Zde je nutne v SL4 umoznit beh aplikace
    v user contextu.
  2. Nulove zblizeni WPF a SL3. Znovupouziti kodu neni snadne a jednoduche, MS
    situaci spise komplikuje, nez by ji zjednodusoval. Duvody uprimne
    nechapu :-(
jiravanet

Michale, nepřidal jsi SL3 skoro celý řád navrch? :-) Mě to ukazovalo cca
4.7MB, necelých 40MB pak mají Silverlight tools, obsahující templaty pro VS,
nápovědu atd.
S tím zmixováním xamlu však souhlasím, ale jak jsem zmínil výše, snad
se to pro příští verze přiblíží (mělo by).

pan pes

Autor je typicky vyvojarsky pulmozek. Jemu se bude snadneji vyvijet
v tomhle, tak je to lepsi. Ale ze aplikace bude mit pristup ke vsem
uzivatelovym dokumentum, to je jen takova drobna nevyhoda. Produkty te posahane
firmy adobe jsou nejhorsi nocni murou pro corporatni prostredi. Ale coz o to,
firmy si to odskacou jen zvysenymi naklady na bezpecnost, ale proc aspon do
webzinu pisici autor nebrani domaci uzivatele, to mi prijde zvlastni. Ta siroka
akceptace paradigmatu „vyvoj za kazdou cenu“ mezi pulmozky je brutalni.
Docela bych zavedl vyvojarske prukazy po vzoru ridicskych prukazu. Snad teprve
hrozba odebrani licence a tim padem vyhazov z prace by mohla pulmozky donutit
trochu myslet i na uzivatele a nejen na sebe. Protoze jinak si ruzni pulmozci
budou moci stahovat od normalnich lidi jejich dokumenty, a to prece
nic neni.

Martin Malý

Cituju z článku: „Adobe AIR je tedy v tomto ohledu daleko mocnější
technologií, což ovšem neznamená, že by přístup Silverlightu neměl své
výhody. Tou největší je, že bezpečnost je pro uživatele zajištěna
přímo systémem, a uživatel se tedy nemusí „bát“ Silverlight aplikace
instalovat – neriskuje prakticky nic. Obě technologie tedy mají své
výhody i nevýhody a nelze jednoznačně říci, která je „lepší“,
rozdíl mezi nimi je ale na bezpečnostním poli zřejmý.“

Ale když se komentátorský celomozek rozhodne, že si musí ulevit, tak
vždy něco najde, i za cenu toho, že tvrzení z článku otočí
o 180 stupňů, že?

Belzebub

To jsou kecy. Souhlasim s tim, ze Adobe Air je primou hrozbou vymyslenou bez
ohledu na zajmy v bezpecnostni oblasti. Ostatne jako vsechno od Adobe.

pas

Proboha, v článku je jasně řečeno, že AIR je srovnatelný s technologiemi Java nebo .NET, tzn. runtime pro běh desktopových aplikací s plnými právy. Pokud si vývojář tuto základní informaci nezjistí a začne obviňovat z něčeho Adobe, tak si o něm opravdu něco pomyslím… Chcete-li mít bezpečnou aplikaci v sandboxu, nepoužijte AIR, ale normální Flash, který je naopak čím dál restriktivnější a v současnosti nejbezpečnější technologií pro tvorbu RIA.

VldySek

Já na svůj celý mozek nějak nepochopil co tím „pan pes“ myslel.
Autor to v části „Bezpečnostní sandbox“ uvedl. Sice trochu zmateně,
ale uvedl, že Adobe AIR má s bezpečností jakýsi problém (doporučuji hned
první větu druhého odstavce uvedené části) ;-) Nikde jsem nečetl nic
o žádném paradigmatu, natož o jeho akceptaci. Článek je o tom, jestli
je Silverlight OOB konkurencí pro Adobe AIR nebo ne. Pro mne z toho plyne
srovnání dvou vývojových prostředí a … víc nic. A to se považuji za
typický vývojářský „desetinkomozek“, takže bez nároku na
licenci ;-)

tom

Btw: AIR ma 15 MB taky z toho duvodu, ze obsahuje kompletni WebKit neboli tridu HTML pro zobrazovani plnohodnotnych webu s podporou CSS a Flashe. Lze proto tedy vytvaret AIR aplikace i bez pouziti Flexu – jen HTML + CSS + JavaScript. Takze lze v ramci AIRovych aplikaci zobrazovat webove stranky a nad nemi jakykoliv overlay. Take lze v ramci AIR aplikace zobrazit PDF dokument (pokud ma clovek nainstalovany Acrobat).

V AIRu si tak napriklad muzete udelat HTML editor a ci widget, ktery zobrazuje napr. mapu s pocasim z nejakeho serveru – cili reuse stavajicich HTML-based sluzeb apod. Take ma clovek pristup ke kompletnimu DOMu v ramci AIRoveho WebKitu a z JavaScriptu ma pak takze zpetne pristup do AIRu.

Tech klicovych veci, ktere ma AIR, je mnohem vic – v tomto clanku je pouze cast – rekl bych, ze si to autor nechava na potom ;-)

Jinak samotny Flash Player 10 umi otevirat lokalne soubory, ktere mu vyberete pres File dialog – zpracovat je a vyplivnout zpet, bez round-tripu na server. V AIRu se pozadovala komplexnejsi a pokrocilejsi funkcionalita.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.