ugrás a tartalomhoz

Mobilra fejlesztés buktatói

inf · 2012. Aug. 25. (Szo), 23.30
Nem nagyon tudtam besorolni a témát...

Kíváncsi lennék, hogy milyen buktatói vannak a mobilra fejlesztésnek. A legjobban annak örülnék, ha van olyan ebben a témában tapasztalt ember köztetek, aki hajlandó lenne egy blog bejegyzést, vagy esetleg cikket írni a tapasztalatairől.

Amit én eddig észrevettem, hogy egy PC-n tökéletesen működő, csak javascriptet és sessiont használó oldal egyszerűen nem működik android alatt. Konkrétan 404-es hibát kapok bizonyos olyan oldalakon, amik előtt location header irányít át. Még nem debuggoltam, de ha már ilyen szimpla dolgok nem működnek, akkor gondolom korántsem csak ennyiről van szó, amikor az ember megpróbál valamit mobilra fejleszteni.
 
1

Nem tudom

Poetro · 2012. Aug. 26. (V), 10.26
Én már több, mint egy éve szinte csak mobilra fejlesztek, és nem tudok hatalmas buktatókról. A fenti hiba valószínűleg a te rendszeredben van, és nem a mobiltelefonban (például egy végtelen átirányítás vagy hasonló). Ahogy asztali gépek esetén, itt se feltétlen szabad feltételezni, hogy a felhasználó böngészője támogatja a sütiket, a képeket, illetve a JavaScriptet, ugyanis ezeket 2 pillanat alatt ki lehet kapcsolni mind Androidon, mind iOS alatt. Legjobb ha megnézed előbb az oldalt links-ben vagy lynx-ben, és ha abban működik az oldal, akkor érdemes tovább lépni (és ugyanez igaz az asztali változatra is).

A csökkentett képernyőméret, teljesítmény és memórián kívül nem sok kivételes helyzetet kell kezelni, de természetesen vannak olyan problémák itt is, amik csak egyes platformokon, illetve esetleg csak konkrét eszközön fordulnak elő (de természetesen ugyanez igaz az asztali böngészőkre is).

Nem hiszem, hogy egy blogbejegyzést tudnék róla írni, mert nincs benne szerintem elegendő téma.
2

Passz, kétlem, hogy végtelen

inf · 2012. Aug. 26. (V), 10.58
Passz, kétlem, hogy végtelen átirányítás lenne benne, mert IIS elszállna tőle. Direkt a legalapabb dolgokat tettem bele, hogy mindenhol menjen. Megnézem ezen a lynx-en, még sosem hallottam róla :D

szerk:
Haha, ott kezdődik, hogy már maga a böngésző sem indul el win7-en :D Úgy érzem megint valami esélytelen dologba fogtam :D
4

webszerver

Poetro · 2012. Aug. 26. (V), 15.07
Nem lehet, hogy az IIS-nek van valami nem szabványos működése, ami miatt ez történik? Én eddig Apache HTTPD, Tomcat, Node.js és nginx esetén nem tapasztaltam semmilyen problémát. Érdemes lenne megnézni a http forgalmat mondjuk egy proxy-n keresztül, és ott is a raw forgalmat nézni.
5

Semmi különbség nincsen, éles

inf · 2012. Aug. 26. (V), 22.03
Semmi különbség nincsen, éles szerveren is ugyanolyan...
11

Szerintem van

Pepita · 2012. Aug. 28. (K), 01.51
- benne elég téma.
Ha csak azt a pár gondolatot részletezed, hogy "képernyőméret, teljesítmény és memória", már megvan a fél cikk, másik fele lehetne az egyes CSS/JS buktatók, példák, butatelefonok (azokkal is neteznek mifelénk), ill. a bájthuszárkodáshoz néhány tipp/trükk.
Persze véletlenül sem akarnám a szabadidődet elvenni, de biztos, hogy sokan szívesen olvasnánk, nagyon jó téma.
3

Valószínűleg valamilyen hibát

tgr · 2012. Aug. 26. (V), 14.02
Valószínűleg valamilyen hibát vétesz a HTTP requestben (nem megfelelő karakterkódolás a headerekben v. ilyesmi), és az asztali böngésző ügyesebben javítja, mint a mobilos. (Eleve a 404-es hibát a szerver dobja, nem a böngésző.)
6

Hát nem a szerver dobja,

inf · 2012. Aug. 26. (V), 22.04
Hát nem a szerver dobja, hanem a router osztályom... Ékezetes url-eket használok, de azok működnek. Még arra tudok gondolni, hogy ékezetesen belül is csak valamelyik karakter, amit nem csíp... Mindjárt megnézem.
7

Talán

hunkris · 2012. Aug. 26. (V), 23.02
az ő meg az ű?
Azokkal régen gondolt volt, néhol most is gond van.
10

Most nézem, szimplán az

inf · 2012. Aug. 27. (H), 06.23
Most nézem, szimplán az ékezetes karakterekkel nincs gond. A 404-es oldalt akkor hozza be, ha location header-t használok. Lehet, hogy ott használni kell az urlencode-t, vagy passz. Majd kipróbálom, bár úgy emlékszem alapból úgy írtam meg a rendszert, hogy lekódolja a dolgokat mielőtt beteszi a html-be, vagy bárhová.
8

A router osztályod

tgr · 2012. Aug. 26. (V), 23.57
A router osztályod feltehetőleg a szerveren fut, nem a böngészőben :-) Össze kell hasonlítani bájtonként, hogy mit kap a mobiltól és a rendes böngészőtől, gondolom hibás/hiányzó URL encoding az eltérés oka, és a különféle böngészők más implicit karakterkészletet használnak (ezzel egyébként IE-n tudsz sokat szívni, manapság majdnem minden más UTF-8 URL-eket küld, az IE viszont teljesen változó, hogy milyen szabvány szerint kódolja.)
9

ie9 teljesen jó, korábbi

inf · 2012. Aug. 27. (H), 00.17
ie9 teljesen jó, korábbi verzióval még nem próbáltam. ahogy néztem az android is urlencoded küldi...
majd írok egy loggert a kérésekre, aztán nézegetem.. egyelőre nem életbevágó, hogy menjen adroidon is...
12

Semmi

Pepita · 2012. Aug. 28. (K), 02.11
Sok tapasztalatom még nincs a témában (2 honlap), de ahogyan Poetro is írta: kb. ugyanazokra kell figyelni, mint asztali esetén, csak jobban. Magammal én szigorú vagyok: jól olvasható tartalmat kell látni minden oldalon akkor is, ha se JS, se CSS. Sajnos a media="handheld" nem minden mobilböngészőben műxik, pedig ha így lenne, én arra gyúrnék, hogy a mobilváltozat mindössze CSS-ben különbözzön (szép feladat!).

Az említett oldal "csak mobilra" készül? Mert az pl. nekem sok helyen nem tetszik, hogy a mobil-verzió másik domain-en van, ha felismeri a telefonomat, már át is irányít. Én egy session-változóban tárolom a verziót, és könnyen hozzáférhetően ("balfölül") ott a link, ha Júzer váltani akar (mert pl. nem ismertem fel a telóját), de nem megy "másik honlapra" emiatt. És kissé játékos lehet, ha pl. a desktop-v.-n több oldalsáv van, stb...

Ékezetes URL... Remélem tőlem sosem kérnek ilyen hülyeséget, csak szívás lehet belőle. De asszem ebben többiek már segítettek.
13

Elsősorban asztalira szánták

inf · 2012. Aug. 28. (K), 03.19
Elsősorban asztalira szánták az oldalt, az android egyébként sem túl fontos, mert iphone tartozékokat árul... :-) Az ékezetes url inkább csak nekem volt fontos, gondoltam, ha már lehet, akkor miért ne raknám be a keretrendszerembe... Egyébként nem volt semmi gond vele, egyedül a bemeneten kell egy urldecode, a html-be mehet simán ékezetesen... Úgy látszik a location header, ahol gond lehet belőle androidon, de ezt sem tudom biztosan, még nem tanulmányoztam a problémát, lehet, hogy semmi köze nincs az ékezetes url-ekhez...
14

Na, akkor

Pepita · 2012. Aug. 28. (K), 06.21
a főbb szempontjaim igazak a te esetedben is. A probléma megoldása JS-kikapccsal kezdődik... Bocs az ékezetes URL szidásáért, de tényleg nem tartom okos dolognak (pedig valahol éreztem, hogy tőled nem a Megrendelő kérte... :)).

Szerk.: ja, fontos még a menü. Több oldalon már láttam, hogy <select>-ben oldják meg, de gondolom így megint csak js-el lehet, úgyhogy bukta is lehet belőle. Én eddig azt találtam ki, hogy ha kétszintes menüm van, akkor az első szintű "gomb" is link, és az oldal tartalmi részében elhelyezem a 2. szintű (al-)menük linkjeit és mobilra ki se rakom "gombként" az almenüket. Mert ugye a (több) lenyíló menü elég hülyén tud kinézni túl kicsi kijelzőn (esetleg ki se fér), pláne a hover-re történő css-változtatás is böngészőfüggő. A főmenü "gombjaira" meg float: left;.
(Ugye az, hogy "location.href a probléma" nem azt jelenti, hogy js nélkül nem is lehet navigálni? Azt a Guglika se szereti!)
15

Köszi a tanácsokat, a

inf · 2012. Aug. 28. (K), 06.38
Köszi a tanácsokat, a kialakításon nem gondolkodtam, szerintem nem éri meg energiát fektetni bele, csak ha tényleg külön mobilra fejleszt az ember. Ennél a projektnél elég, ha ugyanazt látják, mint a rendes oldalon, aztán majd zoomolgatnak. Alapból nem raktam be egy deka javascriptet se, próbáltam mindent css-el megoldani, és ez sikerült is... Mondjuk css2 kellett az admin oldalakhoz, de azt azért egy normális böngésző már hozza...

A location header-nek majd utánanézek, amint lesz időm. Egyelőre nagyon el vagyok havazva...
16

Végeredmény

Pepita · 2012. Aug. 29. (Sze), 01.11
Majd ha lesz végeredmény, érdekelne! (Mondjuk te meg szoktad osztani.)
Ennél a projektnél elég, ha ugyanazt látják, mint a rendes oldalon, aztán majd zoomolgatnak.
Usability... :) Dehát te tudod - és a megrendelő.
17

Erre van keret... :-) Mondjuk

inf · 2012. Aug. 29. (Sze), 05.10
Erre van keret... :-) Mondjuk egy böngésző statisztikát ettől függetlenül lehetne csinálni...
18

Hát igen

Pepita · 2012. Aug. 29. (Sze), 05.23
A keret az sokat nyom a latba...
19

Problémák

Hidvégi Gábor · 2012. Szep. 20. (Cs), 10.18
dropout kollega linkelte múltkor az egyik blogmark hozzászólásai között a facebookos tapasztalatokat, további érdekességek játékfejlesztés során.

Múltkor olvastam egy blogban, aminek sajnos már nincs meg a címe, hogy a modern scriptnyelvek legnagyobb előnye, hogy nem kell a lefoglalt memória felszabadításával foglalkoznod, ami korábban, az alacsonyabb szintű nyelvek esetében rengeteg időt vitt el, valamint sok hibázási lehetőséget adott. Szerinte az igazi áttörést nem az objektumorientált programozás elterjedése, hanem ez jelentette, mert így lehet igazán hatékonyan fejleszteni.

A második linken leírtakból pont az derül ki, hogy az ilyen korlátozott erőforrásokkal rendelkező rendszereken az automatikus memóriakezelés az egyik legnagyobb probléma, mert nem tudod, hogy mikor ürül ki a memóriából a törölt változó (ez még a kisebb) vagy a betöltött kép (ez a nagyobb baj).

Ezek a dolgok persze egy átlagos weboldalnál nagy valószínűséggel nem fognak előjönni, inkább azoknál az alkalmazásoknál, amelyek sok adattal dolgoznak.