je třeba využít příležitosti se ho zbavit. Ale to se nepodaří.
Názory k článku
HTML5 versus nativní: debata o mobilních aplikacích
Re: HTML je mor,
celé vláknoa aku alternativu voci HTML navrhujes ked ti HTML tak vadi...
Re: HTML je mor,
celé vláknoJavu, 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).
Re: HTML je mor,
celé vláknoTak 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í.
Re: HTML je mor,
celé vláknoStlačením tlačidla "Odeslat" si sa práve nakazil... :)
Jo a HTML5/CSS3/JS/PHP je budúcnosť...
Re: HTML je mor,
celé vláknoTo jsi teda pořádný pesimista. Já věřím, že nás čekají i lepší věci.
Re: HTML je mor,
celé vláknoNo 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"... :)
Re: HTML je mor,
celé vláknoBasecamp není v PHP ;-)
Re: HTML je mor,
celé vláknoJo sorry, zly príklad. Ale rovnako ide o webovú službu...
Re: HTML je mor,
celé vláknoProfesionální aplikaci uděláte i v assembleru.
Re: HTML je mor,
celé vláknoHm, 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 :-))
Re: HTML je mor,
celé vláknoNení umění psát vše v nejnižším jazyce, umění je vybrat správný jazyk pro daný program.
Re: HTML je mor,
celé vláknoAno, a trh vybral HTML, CSS, JavaScript, PHP, SQL :-) A už se toho nikdo a nikdy nezbaví.
Re: HTML je mor,
celé vláknoJaký trch? To vybrali vývojáři, která velká firma, kromě Googlu, prodává HTML aplikace ve větším měřítku?
Re: HTML je mor,
celé vláknoNo 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.
Re: HTML je mor,
celé vláknoTakž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?
Re: HTML je mor,
celé vláknoJe 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í/marketing). Chce to trochu větší nadhled -- svět je pestřejší než jen "PHP, HTML, CSS...".
Re: HTML je mor,
celé vláknoTen svět budou mobilní aplikace, a co se prosadí, to se teprve uvidí.
Re: HTML je mor,
celé vláknoHned je videt, kdo dela webiki a kdo programuje tricet let bankovni aplikace v Jave!
Re: HTML je mor,
celé vláknonjn, 30 rokov off a COBOL je dovod preco internet banking v mnohych bankach funguje tak ako funguje a vyzera tak ako vyzera ;)
Re: HTML je mor,
celé vláknoOno aby nakonec mobilní aplikace nebyly stejně taky o "designu/umění/marketingu" a nebyly jen tím zlomkem vašeho Softwarového inženýrství, do kterého často ani nepatří :)
Hezky sepsané
celé vláknoPě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.
Webová aplikace offline
celé vláknoMám dotaz na zkušené programátory web aplikací pro mobilní platformy. Jak je to v současnosti se schopností pracovat offline? Díky
Re: Webová aplikace offline
celé vláknoBez 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).
Nativni aplikace
celé vláknoja 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 :))
Re: Nativni aplikace
celé vláknoTa 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.
Jak na co
celé vláknoMá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.
Multitouch
celé vláknoNemá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.
aktualizace
celé vláknov č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...
Re: aktualizace
celé vlákno> 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.
Re: aktualizace
celé vláknoChci 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)?
Re: aktualizace
celé vláknou 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)
Komentář k tématu
celé vláknoje 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."
Re: Komentář k tématu
celé vláknomožná tak u applu -- android je v tomhle svobodnější a nejste závislý na "obchodních rozhodnutích" Googlu
Re: Komentář k tématu
celé vláknoAno, 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.
Re: Komentář k tématu
celé vláknoZá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ářů.
Re: Komentář k tématu
celé vláknoNeni 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?
Re: Komentář k tématu
celé vláknoNení, 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?
Re: Komentář k tématu
celé vláknoOK, 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.
Re: Komentář k tématu
celé vláknoUž 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.
Re: Komentář k tématu
celé vláknoOK, jeste jednou diky za prinosne odpovedi.
Re: Komentář k tématu
celé vláknoNení zač, rád jsem si to i pro sebe shrnul :)
Re: Komentář k tématu
celé vláknoNě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í.
Re: Komentář k tématu
celé vláknoVí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.
Re: Komentář k tématu
celé vláknoDí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.
HTA aplikace
celé vláknoSice 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
Re: HTA aplikace
celé vláknoPodle mne Ti HTA nepojede nikde jinde než na Widlích.
Re: HTA aplikace
celé vláknoAno, psal jsem "Pod windows lze vytvářet HTA"... ;)
Re: HTA aplikace
celé vláknoJá vidím rozdíl mezi "pod Windows" a "pro Windows" ;)
Re: HTA aplikace
celé vláknoAha, to je pravda..
Tak to opravuji na pro windows :)
Thin client vs. thick client
celé vláknoTenký 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í.
Re: Thin client vs. thick client
celé vláknoNejsem 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.
Nativní aplikace pro Windows 8 (desktop) v HTML5?
celé vláknoNěco jako webOs akorát že ve větším? No na tohle jsem teda zvědav jak to bude...
Re: Nativní aplikace pro Windows 8 (desktop) v HTML5?
celé vláknoTaky jsem zvedavy, co se z toho vyklube. V HTML5 uz nejakou dobu delam, ale jen pro mobily. Doufam, ze me Microsoft potesi :-)
Haha - nativní app? A co na to Facebook?
celé vláknoProject 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.