ugrás a tartalomhoz

A LinkedIn is felhagyott a HTML5 mobilklienssel

Trudy · 2013. Ápr. 19. (P), 16.48
Kezd kipukkadni a HTML5 lufi ?
 
1

A cikk és a cikkben

prom3theus · 2013. Ápr. 21. (V), 18.06
A cikk és a cikkben megszólaltatott szakember sem tesz ilyen megállapítást, mint amilyenre a kérdésed utal. Ezzel szemben arról ír, hogy van még hová fejlődnie a platformnak. Ez teljesen normális megállapítás.

"A helyzet a LinkedIn szerint tehát az, hogy ugyan a HTML5 kellően fejlett, mondhatni készen áll a feladatokra, csupán csak a kiszolgáló ökoszisztéma nem elég érett még" - egy ilyen mondat mellett olyan kérdést feltenni, mint amit feltettél, szerintem csúsztatás a cikk tartalmához képest.

A HTML 5 nem lufi. Az, hogy köré épült némi hype, normális jelenség, ahogyan az is, hogy ennek van egy holtponti csúcs utáni visszakorrigáló, leszálló ága. Ez elkezdődhetett esetleg, de ez a folyamat még így sem lufi kipukkadás. Lufi kipukkadás az, amikor valamiről kiderül, hogy jól felfújtak valami semmit érő dolgot. A HTML 5 előtt pedig komoly jövő áll továbbra is, mindenképp értékes dologról beszélünk, ami valószínűleg a következő 5-10 évben paradigma váltáshoz fog vezetni nagyon sok alkalmazási területen.

A böngészőtechnológiák jelenleg nagy ütemben fejlődnek, egyes eszköz készítők nem tudtak alkalmazkodni ehhez az iramhoz, vagy nem akartak (vagy azért, mert ellenérdekeltek benne, vagy azért, mert kiváró stratégiát alkalmaznak - lényegtelen, miért). Lassan eszközök tekintetében is beindulnak a komolyabb támogatások, lásd például az Intel legutóbbi ilyen fejlesztését: itt.
2

Másrészt a felhasználók

Hidvégi Gábor · 2013. Ápr. 21. (V), 19.47
Másrészt a felhasználók szeretnek látni jól működő és gyors animációkat
Kíváncsi vagyok, ezt mire alapozza.
3

Kíváncsi vagyok, ezt mire

virág · 2013. Ápr. 21. (V), 20.27
Kíváncsi vagyok, ezt mire alapozza.


Tényleg, mire is alapozhatja. Hmmm. Hmm. Lehet, hogy valójában a rosszul működő és lassú, szaggatott animációkat kedvelhetik. Vagy nem, valójában minden animációt gyűlölnek. Hagyjuk. Igazad van. A kérdés jogos, nem linkelt az illető idevágó statisztikákat, te pedig kiszúrtad a téma legfontosabb mondatát, az eszenciát. :D :))


Nagyon érdekes volt egy olyan ember véleményét olvasni akinek láthatóan nagyon sok tapasztalata lehet ezen a téren.

...hogy ugyan a HTML5 kellően fejlett, mondhatni készen áll a feladatokra, csupán csak a kiszolgáló ökoszisztéma nem elég érett még


Lassan azért javul a helyzet. Nagyon lassan, gondolom egy LinkedIn szerű monstrumnak nincs ideje várakozni. Viszont pont az ilyen nagy cégek, ahelyett, hogy siránkoznak, meg másokra mutogatnak, kifejleszthetnének ezt-azt, akár cikkben hiányolt fejlesztéshez kötődő eszközöket (debuggert stb.) is... amire akadt már példa a történelem során többször is. :)
4

te pedig kiszúrtad a téma

Hidvégi Gábor · 2013. Ápr. 22. (H), 07.07
te pedig kiszúrtad a téma legfontosabb mondatát, az eszenciát. :D :))
Miért baj/vicces az, ha számomra más a fontos, mint neked?



A legnagyobb problémát talán a képek okozhatják, mert azokról nem lehet tudni, mikor törli a böngésző a memóriából, más JS objektumoknál a programozónál van a kontroll, mert rajta múlnak a körkörös hivatkozások.



És akkor itt kap értelmet az AJAX-os írásom utolsó bekezdésének első mondata: "Mivel sem szabvány-, sem pedig böngészőoldalról nincs támogatása a dinamikusan frissülő tartalmaknak, jelenleg AJAX-ot használni weblapon nem tanácsolnám senkinek". Talán ki lehetne egészíteni azzal, hogy "mobilos weblapon".
5

egyébként

zzrek · 2013. Ápr. 22. (H), 08.23
Egyébként nekem is szemet szúrt. Hogy jön a LinkedInhez az animáció? Tipikusan olyan felhasználási terület, ahol ez pont nem releváns. ... hacsak nem a reklámok elhelyezéséről van szó! Na ügyes vagyok, végülis rájöttem :-)

(Csak, hogy egyértelművé tegyem: az a kifogás, hogy "a felhasználók szeretnek látni jól működő és gyors animációkat" azt jelenti, hogy "sajnos a flash a moblion nem működik, a HTML5-tel animált reklámok pedig akadoznak, ezért nehezebben adható el a felület, mintha natív kliensen szépen megcsináljuk" -- jól látom a helyzetet?)
6

sőt...

zzrek · 2013. Ápr. 22. (H), 08.29
Sőt, azt is akarták írni, hogy "a HTML5 böngésző alapú, és sajnos egyre nagyobb divat az, hogy korlátozzák a követő sütiket, megaztán a JS kód könnyebben elemezhető kliensoldalon, ha mi ilyesmit akarunk csinálni. Szóval sokkal jobb a natív alkalmazás, ahova ezeket bele tudjuk fejleszteni akár rejtetten is, és senki nem fog beleszólni. De ezt persze nem mondjuk ki, majd inkább valami más dumával kimagyarázzuk, hogy miért vagyunk kénytelenek natívra váltani. Ez van"
7

sőt 2

zzrek · 2013. Ápr. 22. (H), 08.34
"Majd elfelejtettem mondani, hogy persze natív klienssel egyébként is sokkal több adatot tudunk leszedni a felhasználó készülékéről, és hogyha szerencsésen alakul, akkor átvehetjük a készülék felett az uralmat, ahogy a Facebook is tervezi... majd jól meglepődnek -- hehe! -- amikor letiltjuk a FB klienset és beleintegráljuk egyes funkcióit a LinkedInbe, hehehehe (kuckuc, fröccsfröccs)"
9

Badarság

vbence · 2013. Ápr. 22. (H), 08.56
Szerintem egyik sem igaz abban az esetben ha egy Android alkalmazásba szúrsz be egy WebView-t.

A "követő sütik" arról szólnak, hogy a korábban megtekintett lapok (egy részének) listáját kapják meg (így jobban tudnak targetálni, és nagyobb kattintás-arányt produkálni). A WebView-ban nem fogsz más lapokat megnézni csak egyetlen szolgáltatást.

Az alkalmazáson belüli viselkedés eléréséhez nem kell semmilyen kód a kiensoldalra (sem natív, sem HTML5 alkalmzás esetén), hiszen minden új adatért egy kérés megy a szerver felé. Ezután akár egy apache access.log-ból már kiderül a dolgok nagy része, nem is beszélve az alkamazáslogikába építhető eszközökről. - Ebben amúgy nem látok semmi problémát, rengeteg oldal készít heatmapot pl, hogy hova kliekkelnek a látogatók, meddig scrolloznak le stb.
22

nem tudtam

zzrek · 2013. Ápr. 22. (H), 20.15
Nem tudtam, úgy gondoltam, hogy a WebView ugyanúgy működik, mint egy távirányított böngészőablak.
Úgy gondoltam, hogy ha egy külső szolgáltatótól (hirdetőcég) helyeznek el benne mondjuk egy iframe-t, akkor az már külső süti, vagyis ezen keresztül a hirdetőcég követni tudja a felhasználót. Ezt a sütit pedig le lehet tiltani WebView-ban is, ez csak a böngészőtől függ, nem így van?

Ezzel kapcsolatos a kliensoldalas feltételezésem is: sokan aggodalmaskodnak az adatgyűjtésekkel kapcsolatban, ezért jött divatba a követő sütik tiltása, és ezért kapja fel a média, ha valaki ezt megkerüli. Ha HTML appal kerülik meg, akkor valamilyen sebezhetőség kihasználásával teszik (tették) (vagy egyéb módszerrel, amikor a szolgáltató és a hirdetőcég összedolgozik), és ez könnyebben lefülelhető. Ha viszont natív appal történik mindez, akkor nehezebben felismerhető, és nem szól bele a böngésző biztonsági megoldása/beállítása és nem lehet senkit azzal vádolni, hogy valamit megkerülve gyűjtenek adatokat.

Azonkívül szerintem nem badarság a flashanimációs reklámfelületes dolog sem. Igaz, hogy direkt viccesen, cinikusan fogalmaztam, és nem gondolom teljesen komolyan, de nem csodálkoznék rajta, ha ezekhez hasonló érvek lennének a háttérben.

Az apptelepítéses jogosultságos dologgal valóban mellélőttem, hirtelen tényleg nem is gondoltam rá, hogy a HTML alapú app is natív app keretben van. De legalább jól szórakoztam, amíg újabb érveket kerestem :-)
24

READ_HISTORY_BOOKMARKS

vbence · 2013. Ápr. 23. (K), 08.38
Nem, hálistennek a böngésző nem közös cookiekkal dolgozik a WebViewkkal. Viszont létezik READ_HISTORY_BOOKMARKS jogosultság, amivel egy app hozzáfér a historyhoz (és bookmarkokhoz). (Nem tudom, hogy 3rd party browserekéhez mennyire).
11

Animáció

Hidvégi Gábor · 2013. Ápr. 22. (H), 09.08
Engem nem zavar az animáció, ha ki lehet kapcsolni, ha nem, akkor viszont nagyon; amíg az akkumulátorok nem lesznek a maiaknál sokkal nagyobb kapacitásúak, addig nincs miről beszélni. A Windowsban, újabb Androidokban lehet csökkenteni a mértéküket, ki lehet őket kapcsolni, de a weben, CSS-ben erre nincs lehetőség.
14

Továbbra is az a véleményem,

MadBence · 2013. Ápr. 22. (H), 09.46
Továbbra is az a véleményem, hogy nem az animációk miatt annyi az akksik üzemideje, amennyi... A telefon világítása, a wireless chip, a gps, a háttérben futó alkalmazások fogyasztása sokkal jelentősebb.
Részemről persze ez csak spekuláció, nincs tapasztalatom, én hetente töltöm a "buta" telefonomat :-).
16

Lehet

Hidvégi Gábor · 2013. Ápr. 22. (H), 09.50
Én is csak spekulálok : ) Régen volt valami (Nokia?) telefon, ahol lehetőség volt a képernyő egy részének a külön bekapcsolására, pl. az órát vagy egy egysoros állapotot megjeleníteni, ez hasznos találmány.
21

Tessék megnézni az alábbi

deejayy · 2013. Ápr. 22. (H), 14.08
Tessék megnézni az alábbi oldalt krómmal: http://colorsublime.com/, és figyelni hozzá a CPU grafikont.
Ha egy 2 magos 2.5ghz-es proci terheltségét 3-5%-ról 40%-ra fel tudja húzni, ott valami nem optimális. Ezt egy mobilon észre sem veszed, csak azt, hogy 3 óra múlva kikapcsol.

A folyamatos animációkkal pont ugyanez a helyzet. Csináltam egyszer egy végtelen scrollozót (elég lassúra vettem a sebességet, mert röptében kellett olvasni, de ez mindegy is), 60-70% CPU.
8

jogos

Gixx · 2013. Ápr. 22. (H), 08.55
Majd elfelejtettem mondani, hogy persze natív klienssel egyébként is sokkal több adatot tudunk leszedni a felhasználó készülékéről, és hogyha szerencsésen alakul, akkor átvehetjük a készülék felett az uralmat...


Asszony telója a hétvégén szórta körbe a címlistát reklám SMS-sel, mert valami chat program (Tango), amit felrakott, a 100 engedély kérelem között ezt is magában foglalta (gondolom én, máskülönben hogyan), csak hát nem figyelt oda erre.
10

Egy kutya

vbence · 2013. Ápr. 22. (H), 09.01
A "HTML5 kliens" ugyanígy egy Android app, bármilyen jogot kérhet telepításkor. Csak a UI lesz HTML5 (vagyis egy WebView-n belül). Az alkalmazást ugyanúgy telepíted, vannak natív komponensek, amik csinálhatnak csúnya dolgokat. - Ebből a szempontból smemi különbség.
12

Jogosultságok

Hidvégi Gábor · 2013. Ápr. 22. (H), 09.09
A jogokat per html kliens lehet megadni, vagy pedig mindegyikre ugyanaz vonatkozik?
13

A Jogok az alkalmazásra

Poetro · 2013. Ápr. 22. (H), 09.38
A Jogok az alkalmazásra vonatkoznak. Ez kb. hasonlóan működik, mint hogy csinálsz egy alkalmazást XULRunnerrel. Az alkalmazásod HTML+JS+CSS+XML, de hozzáférsz a XULRunner miatt a géphez. Ugyanezt megcsinálhatod Webkittel vagy Trident motor használatával (ahogy például utóbbit teszi a Steam Windows alatt). Szóval a böngészőmotort használni, mint alkalmazási felület nem újdonság, és nagyobb ördöngösség sincs mögötte.
Android - iOS - WinMo alá is tudsz ilyet fejleszteni Appcelarator Titanium, Phonegap segítségével.
15

Köszönöm

Hidvégi Gábor · 2013. Ápr. 22. (H), 09.47
Sejtettem, hogy így működik. A többi operációs rendszeren is így van ez (apple, windows)?
17

Nem igazán

Poetro · 2013. Ápr. 22. (H), 10.06
Mivel a hagyományos asztali operációs rendszereken sokkal kevésbé kifinomultak a jogosultságok, nem igazán. Asztali rendszerek általában csak a hálózathoz, és a fájlrendszer egyes részeihez korlátozzák a hozzáférést (Windows esetén pedig még a Registry-hez). Ugyanakkor POSIX rendszerek alatt van lehetőség, az egyes eszközökhöz való hozzáférés korlátozására, ugyanis azok megjelennek a fájlrendszerben, de nem tudom ennek milyen a kihasználása, valamint egyáltalán ki lehet-e használni ezt a tényt, vagy az OS hívásokon keresztül van-e más mód a korlátozásra, mondjuk GPS érzékelőhöz, vagy mondjuk gyorsulásmérőhöz.
19

Steam

Udi · 2013. Ápr. 22. (H), 12.03
Trident motor használatával (ahogy például utóbbit teszi a Steam Windows alatt)

Csak kiegészítés: a Steam 2010-ben Webkitre váltott.
20

Erről lemaradtam

Poetro · 2013. Ápr. 22. (H), 12.21
Köszönöm, erről lemaradtam, a lényegen viszont nem változtat.
23

Mondjuk azt is csak az

saxus · 2013. Ápr. 22. (H), 23.17
Mondjuk azt is csak az OSX/Linux portolhatóság miatt.
18

Az app felől

vbence · 2013. Ápr. 22. (H), 10.12
A dolog gyökere mindig egy natív alkalmazás, ennek tulajdonságai a permissziók. Az alkamazás UI-ja pedig egyetlen 100% széles 100% magas webview (beágyazott böngészőablak, mint egy ActiveX-es IE kontrol desktopon).

Az alkalmazás egyes funkcióit elérhetővé is teheted a Window objektumon keresztül a webview-n belüli webappnak, szóval így a JS kód küldhet mondjuk SMS-t vagy bármit, amit maga az app megtehtet.

Persze vannak kész eszközök, mint a PhoneGap stb.