A LinkedIn is felhagyott a HTML5 mobilklienssel
Kezd kipukkadni a HTML5 lufi ?
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
ene:
Javaslatok felhasználók regisztrálásához
chikk:
Web Slices
Bártházi András:
Perl alapjai IX. - Adatbáziskezelés
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | 1 | 2 |
A cikk és a cikkben
"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.
Másrészt a felhasználók
Kíváncsi vagyok, ezt mire
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.
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. :)
te pedig kiszúrtad a téma
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".
egyébként
(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?)
sőt...
sőt 2
Badarság
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.
nem tudtam
Ú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 :-)
READ_HISTORY_BOOKMARKS
Animáció
Továbbra is az a véleményem,
Részemről persze ez csak spekuláció, nincs tapasztalatom, én hetente töltöm a "buta" telefonomat :-).
Lehet
Tessék megnézni az alábbi
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.
jogos
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.
Egy kutya
Jogosultságok
A Jogok az alkalmazásra
Android - iOS - WinMo alá is tudsz ilyet fejleszteni Appcelarator Titanium, Phonegap segítségével.
Köszönöm
Nem igazán
Steam
Csak kiegészítés: a Steam 2010-ben Webkitre váltott.
Erről lemaradtam
Mondjuk azt is csak az
Az app felől
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.