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

Zdroják » Mobilní vývoj » HTML5 versus nativní: debata o mobilních aplikacích

HTML5 versus nativní: debata o mobilních aplikacích

Články Mobilní vývoj

Diskuse na téma „webové aplikace, nebo nativní“ se vedou už několik let. Každý přístup má svá pozitiva a negativa, která jsou důvěrně známá a netřeba je vyjmenovávat znovu. Michael Mahemoff opět otevírá tuto otázku, tentokrát ale v souvislosti s aplikacemi pro mobilní zařízení. Nativní, nebo webové?

Překlad článku HTML5 vs Native: The Mobile App Debate, jehož autorem je Michael Mahemoff (Developer Relations, Google). Článek byl publikován pod Creative Commons Attribution 3.0 licencí. Český překlad vyšel na blogu Simply Easy, zveřejňujeme jej po domluvě s překladatelem zde.

Úvod

Mobilní aplikace a HTML5 teď patří mezi ty nejžhavější technologie a v mnohém se navzájem překrývají.  Webové aplikace běží v mobilních prohlížečích a mohou být také zabaleny jako nativní aplikace na různých mobilních platformách. S pestrou paletou platforem, které je potřeba podporovat, a v kombinaci s vysokým výkonem mobilních prohlížečů se vývojáři obrací k HTML5 coby řešení metodou „napiš jednou, využij vícekrát“. Ale je to skutečně životaschopné řešení? Důvody pro nativní řešení jsou tu stále, jsou přesvědčivé a mnoho vývojářů jde raději touto cestou. Následující text je pokus o diskusi na téma nativní versus webový.

Bohatství vlastností

Teze: nativní zvládne více

Mobilní funkcionalitu můžeme rozdělit do dvou dimenzí: uživatelský prožitek s aplikací samotnou a způsob, jakým se aplikace integruje do ekosystému daného zařízení; např. u Androidu by to byly featury jako widgety a notifikace. Nativní kraluje v obou dimenzích.

V rámci uživatelského prožitku s aplikací toho dokáží nativní aplikace víc. Snadno mohou zachytit události jako tažení (drag), na zařízeních, které to podporují, dokonce multitouch. Mohou vykonávat nějakou činnost po stisknutí ovládacích prvků, jako je vyhledávací tlačítko na Androidu nebo ovladač hlasitosti. Mohou také přistupovat k hardware jako je GPS nebo kamera. A s uživatelovým svolením poskytují některé platformy neomezený přístup k operačnímu systému. Jenom si zkuste detekovat pomocí HTML5, jak moc je už vybitá baterie!

Jde o víc než jen o pohodlí v rámci aplikace. Operační systém jako Android poskytuje aplikacím různé způsoby, jak interagovat s uživateli nebo s jinými aplikacemi. Máte aktivní widgety na hlavní stránce. Máte notifikace, které se objevují ve status baru zařízení. A máte tzv. intents, které vaší aplikaci dovolují oznámit ostatním aplikacím, že poskytuje obecnou službu, kterou ostatní aplikace mohou vyžadovat.

Antiteze: nativní vlastnosti mohou být rozšířeny, a web tak jako tak dohání ztrátu

Je pravda, že mnohé vlastnosti nativní aplikace jsou jednoduše mimo dosah HTML5 aplikace. Bez ohledu na to jaké jsou vaše web-fu dovednosti, jestliže vaše aplikace trčí v sandboxu bez možnosti přístupu k API kamery, hned tak schopná fotit nebude! Naštěstí nemusíte v tom sandboxu být. Pokud opravdu potřebujete, aby vaše webová aplikace zvládala fotit, můžete si vytvořit nativní aplikaci s vloženým web view, které bude poskytovat uživatelské rozhraní. Takhle funguje open-source framework PhoneGap: vyplní mezeru mezi webovým a nativním tím, že zpřístupní nativní vlastnosti jako webové služby, které si web view volá pomocí standardního síťového API. Když vytváříte takovéto hybridní aplikace, jste také schopni využít vlastnosti dané mobilní platformy jako jsou widgety, notifikace a intents.

Vytvoření hybridu – web plus nativní – je ideálním řešením jen stěží.  Zvyšuje to komplexitu a použít to lze pouze u webových aplikací zabalených jako nativní aplikace, nikoli u tradičních webových stránek prohlížených v mobilním prohlížeči.  Ale v budoucnosti tomu tak nezbytně být nemusí. Webové standardy se rychle vyvíjejí a moderní mobilní prohlížeče drží tempo. Offline ukládání dat, geolokace, canvas grafika či video/audio playback se těší široké podpoře mezi moderními chytrými telefony. Dokonce i kamera začíná být podporována – Android 3.1 umožňuje fotit a zaznamenat video s použitím webových standardů. A nejnovější iOS prohlížeč podporuje WebSocket pro duplexní komunikaci, streamování a také detekci orientace zařízení.

Mobilní svět se celkově vyvíjí. Web se ale také vyvíjí, a rychle. Jen mezi desktopovými prohlížeči je pět hlavních výrobců, kteří rozvíjejí standardy a přidávají vlastnosti rychlostí blesku. Jakkoliv není triviální portovat všechny tyto vlastnosti pro mobilní zařízení, mnoho z nich už si našlo cestu do mobilních prohlížečů.

Nativní aplikace jsou rychle se pohybující cíl, ale web dotahuje ztrátu.

Výkon

Teze: nativní je rychlejší

Nativní aplikace se nemusejí vyrovnávat s překážkou v podobě běhového prostředí. Běží skoro přímo na železe a mohou využívat pomocníky pro zvýšení výkonu, jako jsou GPU akcelerace a multithreading.

Antiteze: běhová prostředí webu jsou dnes mnohem rychlejší a většina aplikací rychlost stejně nepotřebuje

Říct jen to, že web se stal v nedávných letech rychlejším, by bylo hodně mírné vyjádření. V8, JavaScriptový engine vyvinutý pro Chrome, představoval pro web obrovský výkonový skok už v době, když se objevil, a od té doby se ještě zrychlil:

V8

Grafické renderovací enginy také zrychlily web, a nyní nastupuje hardwarová akcelerace. Podívejte se na rychlostní skok, který  přinesl hardwarově akcelerovaný canvas:

Hardwarově akcelerovaný canvas

Navíc nové Web Workers API umožňuje multithreading a vývojáři moderního webu mohou využívat řadu výkonově optimalizovaných knihoven a dobře prozkoumaných technik pro optimalizaci výkonu. Zatímco většina z těchto technik přichází z desktopového webu, jsou použitelné i v mobilním světě a mobilním zařízením je věnována rostoucí pozornost. Např. výkonový guru Steve Sounders stránku věnovanou mobilním optimalizačním nástrojům.

Ne všechny novinky ze světa desktopů už pronikly na mobilní platformy, ale trend naznačuje, že už jsou na cestě. Také je důležité poznamenat, že většina mobilních aplikací nejsou bleeding-edge 3D hry, ale jsou spíš v zásadě informačně založené: novinky, mail, časové rozvrhy, sociální sítě a podobně. Navštivte pár webů z vašeho mobilu, např. GMail, Amazon, Twitter, a sami budete moci potvrdit, že výkon mobilního webu je víc než dostatečný. Co se týče her, tak ty základní jsou už uskutečnitelné pomocí 2D canvas a WebGL se i na mobilech začíná objevovat – viz Firefox 4. Dokud se nerozšíří, je tady rostoucí rodina frameworků, které kompilují WebGL aplikace do nativních aplikací, které pak mohou využít OpenGL, např. ImpactJS.

Vývojářská zkušenost

Teze: je snadnější vyvinout nativní

Nativní aplikace používají robustní programovací jazyky (např. Java, Objective C, C++), které byly vytvořeny pro komplexní vývoj aplikací a mají za sebou už bohatou historii, která prověřila jejich kvality. Od základů byla vytvořena API podporující danou platformu. Můžete snadno ladit aplikace v desktopových emulátorech, které poskytují dobrou reprezentaci cílového zařízení.

Co činí webový vývoj obtížným je obrovská diverzita prohlížečů a běhových prostředí. Když vaše aplikace běží, není žádná záruka, že určitá vlastnost X bude k dispozici. A i když bude, jak bude implementována v daném prohlížeči? Standardy jsou otevřené interpretaci.

Antiteze: často je snadnější vyvinout web, zvlášť při cílení na více různých zařízení

Pojďme nejprve probrat základní technologie. Je pravda, že webové standardy byly původně koncipovány v době, kdy web byl založen na dokumentech, ne na aplikacích, s JavaScriptem vytvořeným a nasazeným v pouhých deseti dnech! Ale ukázalo, se, že jejich schopnosti jsou mnohem lepší než si kdo představoval – weboví vývojáři se naučili využívat ty dobré části a zkrotit ty špatné. Mimoto ani standardy nejsou dlouhodobě neměnné a poslední kroky v podobě HTML5, CSS3 a EcmaScript Harmony slibují zvýšení přívětivosti pro vývojáře. Zda preferujete C++ nebo Javu nebo JavaScript je předmětem spíš náboženské debaty, a rozhodnutí závisí na kódu, který jste vytvořili v minulosti a ze kterého dnes čerpáte. Ale dnes už můžeme JavaScript zcela jistě zahrnout mezi kandidáty, které je třeba brát vážně.

Druhou stranou fragmentace klientů (prohlížečů a běhových prostředí) je fakt, že všechna tato prostředí vůbec existují. Vyviňte aplikaci pro Android v Javě, a čelíte problému, že pro iOS ji musíte portovat do Objective C. Vyviňte webovou aplikaci, a poběží na Androidu i iOS, a to se ani nezmiňujeme o WebOS, BlackBerry, Windows Mobile a… tedy, taková je alespoň teorie. V praxi budete potřebovat, pokud se staráte o to, jak se uživatelům s vaší aplikací pracuje, věci vyladit pro každou platformu zvlášť. Ale to byste v případě nativních aplikací museli dělat taky, pro většinu operačních systémů existují různé verze a různá zařízení.

Dobrá zpráva je, že „fragmentace“ na webu byla vždycky, a za tu dobu už existují dobře známé techniky, jak se s tím vypořádat. Co je nejdůležitější: princip progressive enhancement vede vývojáře k tomu, aby se nejprve zaměřili na základní funkčnost na jednoduchém zařízení a přidávali vrstvy platformně-specifické úžasnosti tam, kde je dostupná. Mantra detekce vlastností také pomáhá, a dnes máme, díky knihovnám jako je Modernizr, možnost při vývoji použít přístup, kterému se začalo říkat responsive web design, tj. design který se umí přizpůsobit možnostem a schopnostem klienta. Pokud budete tyto přístupy rozumně používat, můžete s minimem nákladů rozšířit portfolio podporovaných zařízení a váš web bude fungovat všude možně – pravděpodobně i na klasických mobilních telefonech ze staré školy, a dokonce i na zařízení jako jsou hodinky a televize, bez ohledu na výrobce a operační systém. Podívejte se na naši multi-UI demonstraci na Google IO 2011, v níž jsme se zaměřili na různé druhy zařízení (klasický mobilní telefon, chytrý telefon, tablet, desktop, TV) se společným základem kódu.

Look-And-Feel

Teze: nativní lépe zapadá do prostředí platformy

Jedním z definujících vlastností každé platformy je její look and feel, jak vypadá a jaký dojem vytváří. Uživatelé očekávají, že kontrolní prvky budou vypadat konzistentně a bude se s nimi manipulovat všude stejně. Existují jisté ustálené zvyklosti, které se liší platformu od platformy, např. co se stane když uživatel provede „dlouhé podržení“ (bude se dotýkat nějakého prvku po dobu několika vteřin)? Platformy mají standardy chování pro takové věci, a nemůžete je všechny uspokojit s jedinou HTML5 aplikací.

Look-and-feel určité platformy je daný nativní softwarovou knihovnou té které platformy. Ta nabízí standardizované widgety, které dávají aplikacím ten vzhled a dojem, který uživatelé očekávají. Můžete mít spoustu očekávaného look-and-feel „zadarmo“, jenom tím, že použijete nativní toolkit.

Antiteze: Web má svůj vlastní look-and-feel, a navíc můžete přizpůsobit webové rozhraní pro platformy, na kterých vám nejvíce záleží

Jak jsme si řekli v předchozí sekci: vývoj webu lze dělat tak, že nejprve napíšeme verzi „jedna velikost se hodí pro všechny“, abychom získali funkční základ, a potom využijeme progressive enhancement. Zatímco rozšiřování je často chápáno jako přidávání vlastností, můžete aplikaci rozšířit i tím, že přidáte vlastnosti specifické pro platformy, na kterých vám nejvíce záleží. To je obdoba „detekce prohlížeče“, což je něco, nad čím se webová komunita mračí, zejména proto, že zde existuje velké množství rozdílných prohlížečů. Ale jestliže dáváte dvěma nebo třem platformám velmi vysokou prioritu a jste ochotni vynaložit extra úsilí, abyste se vyrovnali nativním alternativám, tak právě toto může být způsob, jak toho dosáhnout.

Co se týče výchozí verze, tak lze říct, že i web má svůj vlastní look-and-feel, a můžeme dokonce říct, že každá mobilní platforma má svůj „webový look-and-feel“ daný defaultním prohlížečem a běhovým prostředím. „Webový look-and-feel“ může být pro vaše uživatele přijatelný a fakticky vám umožní dosáhnout většího stupně konzistentnosti s tím, co uživatel zná z prohlížeče na desktopu a na dalších zařízeních, se kterými může pracovat. Navíc existuje mnoho úspěšných aplikací, které nativní look-and-feel moc nepodporují. Tohle platí například pro hry (má vaše oblíbená mobilní hra look-and-feel vašeho mobilního operačního systému?) a ještě víc to platí pro konvenčnější aplikace – např. zkuste několik populárnějších Twitter klientů pro vaši platformu, a uvidíte široký rozptyl uživatelských rozhraní.

Nalezitelnost

Teze: nativní aplikace je snadnější nalézt

Distribuční mechanismy aplikací jako Android Market a Apple AppStore jsou v posledních letech obrovsky populární a představují významnou sílu, která táhne celý mobilní průmysl. Kterýkoliv vývojář může poslat svou nativní aplikaci na tržiště aplikací, kde ji uživatelé mohou nalézt díky kombinaci vyhledávání, procházení kategorií a doporučování. Nejen to – pokud jste udělali svou práci správně, nadšené hodnocení a komentáře přesvědčí i další uživatele ke zmáčknutí toho veledůležitého instalačního tlačítka.

Antiteze: ve skutečnosti jsou webové aplikace snadněji k nalezení

Web je pravděpodobně to nejsnadněji objevitelné médium, které kdy bylo vytvořeno. V pouhé URL máme (alespoň teoreticky) jednoznačný identifikátor pro cokoliv, co bylo kdy publikováno na webu, což zahrnuje i jakékoliv aplikace, publikované na standardních webových stránkách. Vyhledávače usnadňují objevování tohoto obsahu; mohou na něj odkazovat ostatní webové stránky, včetně katalogů webových aplikací, které jsou podobné zmíněným trhům mobilních aplikací. Sdílet webové aplikace se svými přáteli může naprosto kdokoli, jenom tím, že na ně odkáže v e-mailu či vzkazem na sociálních sítích. Odkazy mohou být poslány i v SMS, kde na ně mobilní uživatelé mohou kliknout a spustit aplikaci přímo v prohlížeči svého zařízení.

Zatím nemáme stejná tržiště, kde uživatelé mohou hodnotit a komentovat aplikaci, ale i to se mění. Čtěte dál…

Monetizace

Teze: nativní může být monetizováno

„Šestiletý stvořil aplikaci během přestávky na oběd a prodal zilión kopií po třech dolarech za každou“. Poslední dobou můžete vídat takové titulky často, takže není žádný div, že vývojáři, ať už velcí nebo malí, vzhlížejí k mobilním tržištím s nadějí na výdělek. Mobilní platformy nabízejí několik způsobů, jak mohou vývojáři přímo vybírat peníze za své aplikace. Nejjednodušší je jednorázová platba k odemčení aplikace jednou provždy. Na některých platformách jsou dostupně také platby uvnitř aplikací a mechanismy předplatného, které jsou úzce integrované konzistentním a bezpečným způsobem. Tyto novější formy placení dovolují vývojářům proměnit úspěšnou aplikaci v dlouhodobý zdroj příjmů.

Kromě těchto způsobů plateb je stále možné monetizovat pomocí tradičního webového modelu, např. prostřednictvím reklamy nebo sponzoringu.

Antiteze: web bylo možné monetizovat vždy, a možností přibývá

Web by nebyl tím strojem pohánějícím moderní průmysl, kdyby neexistovaly hojné příležitosti, jak na něm vydělávat. Ačkoliv přímé mechanismy typu „plať za užití“ se zatím moc nerozvinuly, jsou tu různé tržní niky, kde lze vytvořit životaschopná řešení například s modelem předplatného „software jako služba“. Příkladem mohou být Google Apps, produkty 37Signals a prémiové verze různých e-mailových služeb. Navíc přímé platby nejsou jediným způsobem, jak vytvářet zisk z webových aplikací. Je tu online reklama, affiliate odkazy, sponzorství, cross-promotion a další produkty a služby.

Po všem, co tu bylo řečeno, by se nikdo nemohl divit webovému vývojáři, co čte ty titulky a cítí špetku závisti. On nemůže poslat URL do tržiště nativních aplikací, tak co má dělat? Můžete vytvořit nativní „wrapper aplikaci“ – pro každou platformu, na kterou se chcete zaměřit, vytvoříte prázdnou nativní aplikaci, která jednoduše obsahuje komponentu webového prohlížeče (Web View). Do ní vložíte svou webovou aplikaci. Pak stačí už jen tyto nativní aplikace poslat na různá tržiště aplikací (a pak jen pozorujete, jak vám tečou peníze!). Dnes jsou v těch nejznámějších tržištích pravděpodobně stovky, ne-li tisíce podobně webem poháněných aplikací. Některé jsou tak vychytrale asimilované, že v nich vůbec nepoznáme webové aplikace.

Nevýhodou je nutnost kompilování pro každou platformu. Tady mohou pomoci frameworky jako PhoneGap. Nebo ještě lépe, tady můžeme použít webové služby jako PhoneGap Build a vyvíjející se Apparatio. Nasměrujte je na vaše repozitáře kódu, a vypadne aplikace pro Android, aplikace pro iOS a tak dále… připravené k poslání na tržiště aplikací. Žádné instalování nativních SDK na váš počítač; všechno co potřebujete k vytvoření těchto aplikací je editor kódu a webový prohlížeč.

Budou někdy tržiště aplikací podporovat webové aplikace přímo, bez potřeby balit je jako nativní aplikace? To zatím není jasné. Víme, že Google loni představil Chrome Web Store, a ačkoliv se to týká jen desktopu, tento obchod spustil zájem u některých dalších hráčů na poli prohlížečů, a celé je to částí trendu směrem ke katalogům webových aplikací, včetně některých pokusů, specifických pro mobilní zařízení. Jsme v raných fázích konceptu webových obchodů, ale náznaky jsou slibné.

Shrnutí

Bylo by pěkné vyhlásit zde vítěze, ale právě teď žádný jasný vítěz není. Některé aplikace se více hodí do nativního světa, některé se lépe hodí pro web. Web má pravděpodobně rychlejší rozvoj, ale co se týče schopností a kvalit provedení, hýbou se nativní aplikace taky rychle vpřed. A dokud nenastane čas, kdy webové technologie budou „občany první kategorie“ na většině mobilních operačních systémů, vždy bude na místě zvážit nejprve nativní verzi.

Jestli si zvolíte pro vývoj mobilních aplikací webovou cestu, mějte na paměti dodržování standardů a principu progressive enhancement. Web je technologie, která dokáže vaši aplikaci dostat na spoustu různých zařízení a operačních systémů kolem. Ať už tomu budete říkat „fragmentace“ nebo „diverzita“, web s tím počítá a vy, jako vývojáři, můžete těžit z toho, co v tomhle směru udělali jiní před vámi.

Komentáře

Subscribe
Upozornit na
guest
56 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ivan Nový

je třeba využít příležitosti se ho zbavit. Ale to se nepodaří.

ejci

a aku alternativu voci HTML navrhujes ked ti HTML tak vadi…

Ivan Nový

Javu, C++, C#. Tedy na aplikace. A ne znásilňování webu a z prohlížeče dělání OS a programování v 5 jazycích na 50 řádcích kódu. (HTML, CSS, Javascript, PHP, SQL).

pas

Tak ono se dá psát i bez znásilňování, nebo si to nechat vygenerovat z nějakého jiného jazyka, takže se to redukuje na otázku, jestli je HTML/JS ten správný „bytecode“ pro aplikace. Asi proč ne. Na druhou stranu třeba Apple v poslední době (iCloud…) vnucuje otázku „proč ano“, když toho, co mělo být hlavní výhodou webových aplikací (viz promo video, kde vám zničí chromebook, zapnete nový a pokračujete, kde jste skončili), se dostáhne i s nativními aplikacemi, se stejnou lehkostí. A pokud vás nikdo neomezuje ve výojářských nástrojích a tím pádem si vás nepřipoutává k sobě (viz nejdříve zakázaná a následně povolená kompilace z Flashe pro iOS), tak není problém ani s cross-platformností.

Tomáš Lištiak

Stlačením tlačidla „Odeslat“ si sa práve nakazil… :)

Jo a HTML5/CSS3/JS/PHP je budúcnosť…

Opravdový odborník :-)

To jsi teda pořádný pesimista. Já věřím, že nás čekají i lepší věci.

No keď sa spätne pozrieme ako sa vyvinulo HTML od prvých verzií až po súčasný návrh HTML5, tak si myslím, že nás čakajú ešte zaujímavé nové prekvapenia.

Práve som si spomenul, keď do mna pred pár rokmi jeden kolega z výšky hustil, že PHP je pre deti a profi aplikáciu s tým v živote neurobím. Teraz by som mu asi ukázal prstom na Facebook či Basecamp. Myslím, že by sa teraz za tie svoje kecy hanbil. Podobne ako sa za pár rokov bude kolega hanbiť za výrok „HTML je mor“… :)

Pepa

Basecamp není v PHP ;-)

Tomáš Lištiak

Jo sorry, zly príklad. Ale rovnako ide o webovú službu…

Ivan Nový

Profesionální aplikaci uděláte i v assembleru.

jay

Hm, na tenhle názor jsem čekal, protože to co nahoře píšeš o HTML a C++ …, tak někteří prohlašují o C++ … a assembleru.
Rád bych viděl něco jako třeba EIS napsané v assembleru :-))

Michal

Není umění psát vše v nejnižším jazyce, umění je vybrat správný jazyk pro daný program.

Ivan Nový

Ano, a trh vybral HTML, CSS, JavaScript, PHP, SQL :-) A už se toho nikdo a nikdy nezbaví.

jay

Jaký trch? To vybrali vývojáři, která velká firma, kromě Googlu, prodává HTML aplikace ve větším měřítku?

Ivan Nový

No a to je trh. Prostě konkurence používá PHP, HTML, CSS, JavaScript, SQL. Má nějakou produktivitu a náklady, nějaké klienty s jejich typickými zakázkami, které vytváří poptávku a tomu se musíte přizpůsobit. Jiné technologie nemohly konkurovat na segmentu trhu pro malé a střední firmy, protože to znamenalo vyšší náklady jak pro vývoj, tak pro provoz.

jay

Takže by bylo lepší dělat věci dráž?
Řekněme, že by byli kvalitnější, ale proč, když to kupující nejsou ochotní ocenit a naopak oceňují spíš vlastnosti, které mají HTML aplikace a ty nativní ne?

Opravdový odborník :-)

Je vidět, že většina lidí tu dělá jenom „webiki“. Softwarové inženýrství je ale mnohem širší oblast a ty weby jsou jen zlomek (a často tam ani nepatří, protože jde spíš o design/umění/mar­keting). Chce to trochu větší nadhled — svět je pestřejší než jen „PHP, HTML, CSS…“.

Ivan Nový

Ten svět budou mobilní aplikace, a co se prosadí, to se teprve uvidí.

valnoha

Hned je videt, kdo dela webiki a kdo programuje tricet let bankovni aplikace v Jave!

DeathWalker

njn, 30 rokov off a COBOL je dovod preco internet banking v mnohych bankach funguje tak ako funguje a vyzera tak ako vyzera ;)

Čelo

Ono aby nakonec mobilní aplikace nebyly stejně taky o „designu/umění/mar­ketingu“ a nebyly jen tím zlomkem vašeho Softwarového inženýrství, do kterého často ani nepatří :)

Michal Feltl

Pěkný článek, se kterým souhlasím. Klient nebo řekněme ten, kdo chce svůj web (nebo bysnys) převést na mobilní platformu, měl by popřemýšlet, zda bude lepší zvolit cestu nativní aplikace skrz mobilní OS nebo vytvořit web pro mobilní prohlížeče.

Naith

Mám dotaz na zkušené programátory web aplikací pro mobilní platformy. Jak je to v současnosti se schopností pracovat offline? Díky

PH

Bez problémů, app cache funguje dobře a lokální úložiště taky. Pokryje se tím iOS, Android, Blackberry (i Playbook), webOS, jen u WP7 nevím (asi až od Manga).

Sislik

ja vesmes preferuju nativni aplikace, nejen na PDA, ale i na PC – prijdou mi lepsi, pohodlnejsi a pokud komunikujou pres internet, tak prenasi jen nezbytne nutny data (prenaseji jen data a ne to, jak data zobrazit), coz v mistech, kde neni HSPA, docela ocenim :)
s tema prenosama toho souvisi vic – obcas treba zalaguje net nebo treba na chvili vypadne signal uplne, tak s webovou applikaci bych mel docela asi problem, kdyz si pripravim v PDA mail v nativnim mailovym klientu, tak treba v metru jen pockam, nez bude stanice a poslu a pohoda :) (pominu-li, ze pokazdy nadavam, ze v Praze nejsou pokryty komplet linky metra :))
kdyz mam nativni aplikaci, tak nemusim treba resit veci jako aktualizace prohlizece nebo smazani cache prohlizece – nemusi se bat o zadny, lokalne ulozeny data nebo to, ze s novejsi verzi prohlizece prestane nejakak ma oblibena aplikace fungovat

jinak, treba na PC si radsi pustim Outlooka vedle, nez lovit, kterej tab v prohlizeci je webmail a snadno se do nej ALT+TABnu, takze bez ohledu kde jsem, max do 2 s jsem v libovolny aplikaci, kdezto, kdyz budu mit v prohlizeci treba 100 tabu, tak do 2s jsem v prohlizeci a pak treba dalsi 2 s budu hledat muj tab a vesmes navic musim kliknout (prohlizec pouzivam zasadne v 1 okno, nesnasim, kdyz jich je vic)

abych to shrnul, premejslim, co v PDA pouzivam jako webovou aplikaci, ale nejak me nic nenapada :) asi jen hledani v jizdnich radech, ale to pouzivam dost sporadicky navic nevim, jestli navsteva webu PMDP, najiti si linky, smeru a vychozi stanice je povazovatelny za aplikaci, kdyz to jen zobrazuje „tupe“ data z nejaky DB :) a v PC? tam asi taky ty jizdni rady (ale to nebude aplikace) a pak mapy (coz aplikace urcite uz bude :))

pas

Ta technická omezení, o kterých píšete, už neplatí – máte k dispozici app cache (tudíž se nepřenáší GUI, ale jen data, např. v JSONu) a lokální úložiště (tudíž můžete pracovat i offline). Jediné, co je problém, je ta schizofrenie pro uživatele, kdy jednu sadu aplikací má v OS a druhou v browseru, který se dnes vlastně stává virtualizovaným OS uvnitř jiného OS. Tohle řeší teprve systémy, které nativní aplikace vůbec neumožní – viz ChromeOS. Na mobilních zařízeních se něco takového ale asi ještě dlouho nedá čekat.

lukoko

Málokdy je překryv tak velký, aby nebylo z požadavků na aplikaci zřejmé, jestli je nutné ji dělat nativní, nebo webapp. Pokud jsou požadavkem nějaké fullscreen animace a je kladen důraz na jejich plynulost, na pixel-perfect vzhled a podobné věci, nezbude než udělat aplikaci. Na druhou stranu pokud webová aplikace dokáže splnit průměrné požadavky na cokoliv (kromě přístupu k hw, openGL atp). Je potom velký rozdíl jestli to má být webová aplikace, která má vypadat jako aplikace, nebo offline webapp, která vypadá jako web. Je potřeba se zamyslet na UI.

vkalina

Nemám s vývojem aplikací pro mobily (téměř) žádné zkušenosti, nicméně jako uživatel můžu říct, že i webové aplikace umí multitouch, první příklad co mě napadá je http://maps.google.com na iPhonu umí multitouch úplně stejně dobře jako nativní mapová aplikace.

alfi_

v článku mi chybí ještě jedno srovnání – nativní aplikaci stáhnu jednou a pak používám, webovou v podstatě stahuju vždycky znovu (nebo jen její kousek, který právě používám).

výsledek je takový, že každá návštěva třeba android marketu znamená, že některá z 20-50 aplikací v telefonu potřebuje aktualizovat = stahování jednotek až desítek MB i na pomalém připojení, nová instalace, zrovna když něco potřebuju, tak se aplikace aktualizuje nebo alespoň zdržuje procesor a moc to neovlivním (jen zákazem všech aktualizaci)..

webová aplikace je naopak vždy aktuální, vždycky se používá nejnovější dostupná verze. i to má ale nevýhodu – pokud provozovatel aplikaci vyvíjí průběžně (viz třeba m.facebook.com), aplikace může v podstatě každý den vypadat trochu jinak, chovat se trochu jinak, mít různé chyby a uživatel musí být pořád ve střehu, co se od posledně změnilo, kde najde svůj oblíbený odkaz nebo funkci…

Čelo

> to má ale nevýhodu – pokud provozovatel aplikaci vyvíjí průběžně (viz třeba m.facebook.com), aplikace může v podstatě každý den vypadat trochu jinak

Což zase může být ku prospěchu věci, kdy jste schopen nasadit změnu jen pro určitou část lidí a na základě měření jejich chování a případných dalších reakcí až následně přizpůsobit aplikaci ostatním.
Z mého pohledu je to lepší přístup pro menší týmy a startupy, kteří chtějí využít své velké přednosti a to velké flexibility.

Pepa

Chci se zeptat – když vlezeš do Android marketu tak se ty aktualizace začnou stahovat autmaticky samy? Nebo si můžeš zvolik kterou a kdy stáhnout (např. až doma na WiFi)?

alfi_

u každé aplikace je zaškrtávátko „aktualizovat automaticky“. pokud je zapnuté a povolené datové spojení, aplikace se začne aktualizovat sama při vstupu do marketu bez ohledu na připojení (edge) nebo jinou činnost telefonu..

druhá možnost je jednou za čas vše aktualizovat ručně, teď už je tam i tlačítko „aktualizovat vše“ (android 2.2)

Martin Malý

je na http://blog.theunpluggedweb.com/post/6536550719/the-native-is-better-thing-again-sigh – zajímavý je závěr, zhruba ve smyslu: „I kdyby měli zastánci nativních aplikací pro mobily ve všem pravdu, stejně budu obhajovat a používat webové technologie spíš než třeba Cocoa Touch. Rozdíl je pro mne hlavně v tom, že jedno můžete použít kdekoli, teoreticky na jakémkoli zařízení s obrazovkou, dneska i v budoucnu. To druhé vás zamkne pro jednoho výrobce a vy budete závislí na jeho obchodních rozhodnutích.“

Opravdový odborník :-)

možná tak u applu — android je v tomhle svobodnější a nejste závislý na „obchodních rozhodnutích“ Googlu

pas

Ano, přenositelnost je zásadní věc. Ale to nutně nemusí znamenat, že aplikace je přenositelná na úrovni runtimu. Může být přenositelná tím způsobem, že ji zkompiluju z jednoho kódu pro různé platformy. Důležité je, aby mi daná platforma toto nezakazovala. Apple si to zkusil loni a po smršti kritiky to po pár měsících zrušil. Pokud mi teď dovoluje používat libovolné jazyky a nástroje, programovat proti abstraktnímu API, tak už se o vendor lock-in mluvit nedá, protože je fuk, jestli to abstraktní API existuje za běhu iPADu nebo jestli ho mám jen v době kompilace.

jezovec

Závěr zajímavý, ale podle mého obecně nepřijatelný.

Proč?

Protože ten člověk se na to dívá z pohledu vývojáře, a ne uživatele.

On jako vývojář může to „jedno“ použít v každém broweru a na obrazovce, ale co to přinese uživateli? Že může přistoupit ke službě klientem napsaným jednou a použitelným i jinde – no a? Na kolika zařízeních uživatel službu běžně používá, a opravdu očekává že v nich najde toho samého, nebo trochu přebarveného klienta, bez ohledu na ovládání, zvyklosti a design prostředí konkrétního zařízení? Bez ohledu na to v jaké situaci to které zařízení typicky používá – a co tedy v daném kontextu od služby chce?

Jak takový přístup pomůže klientům a provozovatelům služby (teda kromě toho že trochu ušetří – je otázka zda na pravém místě a jestli tím naopak v důsledku neprodělá)?

Mluvíme zde přece o službách, aplikacích, ne rich-textu (a i u něj je to otázka).

Použitelnost klientské aplikace, a je třeba zase si uvědomit že mluvíme o klientu k nějaké službě, musí splňovat dva trochu protichůdné požadavky: zapadnout do UX daného zařízení, a zároveň přinést i typický UX dané služby. To první univerzální klienti většinou splnit nemohou, a nutnými kompromisy v nich kulhává i to druhé.

Jesli je Apple v něčem dobrý tak je to právě v tom že je orientovaný na uživatele. Ti jsou jeho zákazníci, nikoli vývojáři klientských aplikací. A jako (mimo jiné) vývojář tvrdím že to je dobře.

PS: Aby nedošlo k nedorozumění, myslím že webové aplikace mohou mít v určitých případech své opodstatnění. To se ale musí odvíjet od toho k čemu mají v daném konkrétním přípdě sloužit a potřeb uživatelů, ne vývojářů.

LS_999

Neni tedy zaver ten, ze jako pro uzivatele je pro mne mnohem lepsi html5,
nebot pak mam aplikaci typu „kup jednou, uzivej vsude“, kdezto naopak,
nativni iOs applikace mi je vsude jinde nez na iphonu na pytel apod. pro
dalsi platformy?

jezovec

Není, protože ve valné většině případů si kupujete službu (jednou) a k ní pak máte různé klienty, třeba iOs nativní aplikaci na iPhone a webové rozhraní na desktopu a taky papír když si ten časopis předplácíte i klasicky. Tj. vy si nekupujete (resp. nestahujete) iPhone aplikaci pro tu aplikaci samotnou, ale proto že se skrz ní dostanete na tu službu, že vám nějak přinese tu službu do vašeho telefonu.

„Kliento-centrický“ pohled je podle mně postavený na hlavu. Vy přece chcete používat tu službu (noviny, twitter, blog, mapy, geocaching, kalendář, text editor) jak nejlíp to jde na každém svém zařízení – a ne primárně mít jednoho univerzálního klienta napsaného jednou univerzální technologií.

A pokud ta aplikace o kterou máte zájem není klientem nějaké serverové služby, tak už je její napsání v HTML5 s spouštění v browseru úplně na hlavu, nezdá se vám?

Také, kolik takových mobilních zařízení běžně máte (jako jednotlivec uživatel) aby se vám opravdu vyplatilo mít jednoho přenosného univerzálního klienta? Kolik máte telefonů? A nebo chcete používat stejného klienta na 27“ displayi i na 9“ displayi tabletu a 3″ displayi telefonu?

LS_999

OK, diky za odpoved.

Asi dost zalezi na typu aplikace/sluzby, jestli je
klient vhodny nebo ne. Je opravdu nutne na pristup do banky
mnoho ruznych native klientu, ja myslim, ze ne.

Také, kolik takových mobilních zařízení běžně máte (jako jednotlivec uživatel) aby se vám opravdu vyplatilo mít jednoho přenosného univerzálního klienta? Kolik máte telefonů? A nebo chcete používat stejného klienta na 27“ displayi i na 9“ displayi tabletu a 3″ displayi telefonu?

To zalezi na situaci – bezne uzivam kolem 5 desktopovych pocitacu+
2 mobily,
a pak zalezi na licenci toho klienta, pokud bude na 1 pocitac,
tak si ho mam koupit 7x? To se pak tedy prodrazi…
Ale nevim, nevyznam se v tom, spis se tak ptam.

jezovec

Už vám rozumím. Ano, záleží na licenci toho klienta, to máte pravdu.

Já mám třeba „elektronické“ předplatné novin (platím ročně nějaké peníze za plný přístup): mám je předplacené jednou, na počítači je čtu na webu, na iPhonu a iPadu nativní aplikací – kterou vydaly ty noviny zadarmo. Zadám do ní jméno a heslo a jsem tam, stejně jako na webu, ale na těch menších zařízeních pohodlněji a co se týče třeba multimédií a off-line provozu i spolehlivěji.

Jiný příklad: Čtu ale občas i jiné noviny, ty jsou na webu při registraci zdarma. Vydaly ale i aplikaci pro iPhone, za kterou chtějí pár liber ročního poplatku. Koupím si jí jednou, mohu jí mít za ten jeden poplatek na všech svých iOs zařízeních: tady platím za „komfort“, a je to nepřenositelné na jiné než má vlastní iOs zařízení.

Protipříklad: iWork v iCloudu (tj. Apple „office“): tam se platí za klienta pro desktop a iOs zvlášť, i když data mezi nimi lze sdílet prostřednictvím cloudu.

V mých úvahách, a myslím že píšu o celkem typickém scenáři, je primární ta služba, a aplikace je jenom okno do ní, poskytované provozovatelem té služby. Služba nevydělává na prodeji klientů – proto jsou typicky zdarma a nebo za symbolický poplatek. Pokud je služba sama zadarmo, pak mohou být klientské aplikace dražší, jako platba za komfort.

V protipříkladu jsem uvedl aplikace které nejsou klienty nějaké služby, ale mohou fungovat samostatně (stand-alone), a jejich data lze sdílet napříč zařízeními. Jsou to ale typicky komplexní aplikace, u kterých je jejich cross-platformní implementace v HTML5 technicky velmi obtížná, ne-li neřešitelná.

Troufám si tvrdit, že univerzální přenosilený HTML5 klient je vhodný zejména na „tenčí“ klientské aplikace pro serverové služby. A že i tam není jeho hlavní výhodou „přenostitelnost“, ale snadný přístup při impulzivním a nebo nouzovém využití služby.

Pokud je mobilní klient jenom trochu komplexnější, a nebo je primárním nebo rovnocenným (s desktopem) kanálem pro přístup ke službě, pak se vyplatí zvážit použití nativní aplikace.

Zvláštím případem jsou alternativní klienti využívající API k nějaké službě a nebo službám (mash-up) – tam jsou myslím HTML5 aplikace ještě méně vhodné.

A na závěr bych se na to zkusil podívat obrázeně: ne HTML5 je „hrozbou“ nativním aplikacím na mobilních platformách, ale naopak čím sofistikovanější a komplexnější HTML5 aplikace budou, tím zřetelněji bude vystávat otázka zda už pak není lepší vyvinout pro danou službu mobilního nativního klienta, alespoň pro hlavní mobilní platformy, a rozdávat ho zadarmo. Neboli, zda se naopak nativní klienti nestanou na mobilech nějakým Web 3.0. Jestli nativní aplikace nakonec neposkytne za srovnatelné peníze lepší muziku.

LS_999

OK, jeste jednou diky za prinosne odpovedi.

jezovec

Není zač, rád jsem si to i pro sebe shrnul :)

pas

Nějaké oblasti, kde se ta cross-platformnost hodí, by se našly. Třeba malé casual hry – jsou dost „kliento-centrické“ (spousta kódu na straně klienta), ale zároveň jsou i klientem webové služby (multiplayer), najmout programátory pro všechny různé platformy se dost prodraží, a zároveň není nutné nebo ani žádoucí, aby na každém zařízení používaly jeho specifické UI. Pak jsou webové technologie ideální.

Čelo

Víceméně jste napsal, co jsem chtěl říct. A ještě bych dodal že díky „responsive“ přístupu nevidím ani problém v různých rozměrech obrazovek.

jezovec

Díky za připomínku, a vlastně s vámi souhlasím. Na takovéhle menší rychloobrátkové záležitosti (to nemyslím pejorativně!) je web app vhodná.

Moje polemika směřovala proti argumentu jakési inherentní výhodnosti „mám jedno, použiju všude“. Někdy to pochopitelně výhodné být může.

Tomik

Sice trošku OT, ale i tak to semka dám..
Pod windows lze vytvářet HTA (HTML application), kde se pracuje s HTML/CSS jako GUI, a JScriptem, který pomocí ActiveXObject může přistupovat k souborům, spouštět nativní aplikace… S HTA nepracuji dlouho, ale přijde mi, že to skoro nikdo nepoužívá… A mě by zajímalo proč a jestli má cenu se HTA pořádně naučit..

Děkuji za reakce

pravdokop

Podle mne Ti HTA nepojede nikde jinde než na Widlích.

Tomik

Ano, psal jsem „Pod windows lze vytvářet HTA“… ;)

Čelo

Já vidím rozdíl mezi „pod Windows“ a „pro Windows“ ;)

Tomik

Aha, to je pravda..
Tak to opravuji na pro windows :)

Anonymous

Tenký klient (HTML) vs. tlustý klient (nativní), to už tu jednou bylo. Každý má své výhody a nevýhody a každý má své uplatnění.

pas

Nejsem zrovna expertem na tloušťku klientů, ale řekl bych, že nativní aplikace a aplikace v HTML5 jsou stejně tlusté – liší se prostě jen použitým jazykem plus pár drobnostmi v možnostech API.

jezovec

http://arstechnica.com/microsoft/news/2011/06/html5-centric-windows-8-leaves-microsoft-developers-horrified.ars

Něco jako webOs akorát že ve větším? No na tohle jsem teda zvědav jak to bude…

PH

Taky jsem zvedavy, co se z toho vyklube. V HTML5 uz nejakou dobu delam, ale jen pro mobily. Doufam, ze me Microsoft potesi :-)

Bob

Project Spartan is the codename for a new platform Facebook is on verge of launching. It’s entirely HTML5-based and the aim is to reach some 100 million users in a key place: mobile.

http://techcrunch.com/2011/06/15/facebook-project-spartan/

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.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.