mobiles web app

[_korso_]

Lepo si rekao - swipe-flow.
Jeste malo izmena klasicnog shvatanja requesta, ali je u sustini isto. Imas request koji je asinhron, server vraca 200/403. Verovatno ces imati neki centralni objekat/objekte koji sluze za tu namenu - da kordiniraju dobavljanje podataka i renderovanje sledece stranice. U tom kontekstu ti i dalje dobijas na isti nacin podatke, kroz istu "proceduru" sve to prolazi, samo sto ih da kazem "baferujes" i cekas da korisnik odradi sledecu akciju. I na osnovu toga ti se prakticno on-the-fly definise sledeca stranica aplikacije.

Gore pomenuti js fw-rci nisu nesto teski za savladjivanje. To su light verzije. Imas mnogo teze dojo.mobile i kompaniju, pa senchu. Tome se bas treba posvetiti i istraziti. Ovi mislim da mogu u hodu da se uce. Ja sam bar tako i ucio, mada opet sam radio i sa dojo-om duze vreme, pa je lakse bilo.
Probaj, dosta stvari su resene vec ispod haube. Ako nemas iskustva sa tezim javascript aplikacijama, ovo moze da ti pomogne dosta, nego da pises sam. Ti najbolje znas, sta ti je najprihvatljivije.

Nisam radio sa jqmobile, pa je ovo malo i nagadjanje da tako radi ispod haube. Takodje css mi nije jaca strana. Ali pretpostavljam da postoji neki swipeOut ili kako god da ga zovu event, gde ako se to desi, pozoves centralni page objekat koji:
1. ako je request u toku otkaze ajax request (jer on i sluzi imzedju ostalog za dobavljanje podataka). Opet kako nisam radio sa jqmobile ne znam kako funkcionise. Ali verovatno da u pozadini poziva $.ajax f-ju gde ako imas referencu na trenutni xhr objekat, mozes da pozoves xhr.abort. To znaci da ako je na "pola" swipea otkazao, da ce ostati na prethodnoj stranici, a podaci se nece vratiti sa servera, pa se nece ni procesirati.
2. ako su vec podaci dovuceni sa servera, verovatno da postoji neki property tog eventa na osnovu koga mozes da zakljucis da li je odradio ceo swipe ili ne. Cesto ti eventi imaju kordinate u px, ili neke interesantne podatke, pa na osnovu njih zakljucujes sta se u stvari desilo.
3. takodje mozes da kada se tek odradi ceo swipe onda da zamenis stranicu, koja ce da ide sa nekim slide efektom ili kako se bese zove u jq.

Pretpostavljam da se moze napraviti jedna od ovih varijanti, jer i ja sam cesto odradim swipe i zadrzim jos par sec, pa tek onda pustim (npr. ako mi je u tom trenutku nesto zapalo za oko) i tek onda dobijem sledecu stranicu, bez polovicnih i sl.

Za ovu app sto ima implementirano, procitao sam negde da ima web inspector sa iOS Safari ili tako nesto. Proguglaj, pa gledaj log sta se desava kada radis te akcije koje tebi trebaju. Ono sa overflow mislim da je samo neka vrsta hacka. Verovatno da postoji elegantnije resenje.

[dee]

js kao takav mi nije nikakav problem. odradio sam puno toga s njim (sto raw sto uz pomo raznih frameworka). ne bi bio cak problem ni kuckati nesto sam medjutim je to besmislena rabota. em je tona stvari rijesena sto kazes 'ispod haube' em je nemoguce predvidjeti buducnost i potrebe, a ipak puno koristen framework (koji god), ako nista, barem dijelom ima te stvari na umu. a vrijeme razvoja (i mogucnost prosirenja) svakako su mi vazni.

pogledat cu svakako detaljnije kako i sto jquery radi i kakav je event-cycle od pocetka swapa do loada nove stranice.

u svakom slucaju, jos jednom, puno ti hvala!

[xippi]

e ovo postaje sve bolje http://www.sencha.com/products/architect

[dee]

Originalno napisao _korso_

Komplikovanije, ali u "skladu" sa UX na mobilnim platformama je da sa dovlacenjem inicijalnog javascripta, dovuces i neki konfiguracioni fajl (obican js fajl) koji ti cuva podatke o trenutom korisniku, kao i page stack kome moze da on pristupi. Tako da ako je na stranici 5, a nema pravo da vidi str. 4, vec samo 1 i 2, onda prakticno swipe-left ga vodi na prvu koja je u onom konf fajlu ili stranicu 2 po ovom primeru. Takodje je i ovo resenje optimalnije, jer radis samo prefetch za stranicu za koju korisnik ima autorizaciju.
A gresku da nije autorizovan treba prikazati tek kada odradi nevalidan swipe, jer ako je na stranici 2 on niti zna da je odradjen prefetch niti ce kao sledecu akciju da odradi bas to. Mozda ce samo da zatvori app.

Sve zavisi od situacije, od same logike aplikacije, nemam celu sliku pa je ovo na prvu loptu. Postoje jos neke varijante, ali zavise od sire price i organizacije aplikacije. Valjda ces izvuci nesto odavde.

vracam se ovom postu svako malo...

nego, krenuo sam i vec dosao do nekoliko stranica aplikacije. idem ovim putem sa konfiguracijskim fajlom na osnovi kojeg gradim i menu i swipe flow. e sad, postavlja se na kraju pitanje, zasto uopce imati prefetch? (razdvajam ui logiku na client i server, imam dodatne requeste, etc...)
UI mi je ionako prilicno jednostavan (ocekivano za mobile platformu) tako da se sve vise bavim mislju - zasto uopce raditi prefetch? Odnosno, obrni okreni, zasto server ne bi bio samo za podatke, a kompletna UI logika (kreiranje i sve UI promjene) odradjene na clientu u js? U tom slucaju, server sluzi za autorizaciju + cist data.

Ne zvuci li to kao 'najcisci' pristup?

[_korso_]

Ako sam te razumeo u ovom zadnjem delu poslednjeg posta, to je upravo single-page-app tj RIA "pristup" (proguglaj da vidis, ako vec nisi). Server je zaduzen samo za biznis logiku (ACL, auth, data, jos po neku sitnicu), dok cela UI logika je u Javascriptu koji je u browseru.
Prefetch u ovom tvom primeru vidim isto kao i fetch na click/swipe samo sto podatke dovuces u pozadini bez znanja korisnika. Ali ukoliko na prefetch dovlacis i dinamicki generisan html, onda sva UI logika ti nije na klijentu vec je ima i na serveru.

Da li je najcistije, zavisi ko i kako gleda na to. Npr. Googlovi proizvodi koriste upravo tu tehniku. Neki ljudi koji nemaju mnogo poverenja u clienta i sam javascript, misle da je to losa metoda, dok neki ne bi radili nista osim takvog pristupa.

Ja licno varijante ove tehnike (server: data, client js: UI) koristim za razvoj nekoliko godina inazad i meni je princip dosta cist. Ima i svojih mana naravno - kao i sve.
Mada opet sve to zavisi od app, nekada ima smisla kombinovati par tehnika kako bi napravio najbolje resenje za problem koji resavas.

[dee]

Originalno napisao _korso_

Ako sam te razumeo u ovom zadnjem delu poslednjeg posta, to je upravo single-page-app tj RIA "pristup" (proguglaj da vidis, ako vec nisi). Server je zaduzen samo za biznis logiku (ACL, auth, data, jos po neku sitnicu), dok cela UI logika je u Javascriptu koji je u browseru.
Prefetch u ovom tvom primeru vidim isto kao i fetch na click/swipe samo sto podatke dovuces u pozadini bez znanja korisnika. Ali ukoliko na prefetch dovlacis i dinamicki generisan html, onda sva UI logika ti nije na klijentu vec je ima i na serveru.

Da li je najcistije, zavisi ko i kako gleda na to. Npr. Googlovi proizvodi koriste upravo tu tehniku. Neki ljudi koji nemaju mnogo poverenja u clienta i sam javascript, misle da je to losa metoda, dok neki ne bi radili nista osim takvog pristupa.

Ja licno varijante ove tehnike (server: data, client js: UI) koristim za razvoj nekoliko godina inazad i meni je princip dosta cist. Ima i svojih mana naravno - kao i sve.
Mada opet sve to zavisi od app, nekada ima smisla kombinovati par tehnika kako bi napravio najbolje resenje za problem koji resavas.

Da, da, RIA prica.

Ma, kako sam novi u mobile web razvoju i kako sam krenuo s jQueryMobile primjerima, prirodno je stvar na pocetku otisla u smjeru njihovih primjera (koji podrazumijevaju UI sa servera, vise manje). Medjutim, vec na prvom koraku mi smeta cinjenica da razdvajam UI na klijenta i server jer to nekad do u beskraj komplicira stvari.
S druge strane, u javascript imam gotovo pa potpuno povjerenje (a i, po mom skromnom misljenju, dugorocno je dobra odluka sto vise ici sa javascriptom jer u kombinaciji sa HTML5 to ponovno postaje top vazan jezik) i RIA na klasicnom webu su mi normalna stvar za koju bih se uvijek odlucio. Tako da nije proslo dugo dok sam shvatio upravo to sto govoris:

Ja licno varijante ove tehnike (server: data, client js: UI) koristim za razvoj nekoliko godina inazad i meni je princip dosta cist. Ima i svojih mana naravno - kao i sve.

ja to koristim par godina na klasicnom webu, a sad vidim da je i na mobilnom prica zapravo ista uz tu razliku sto je workflow mrvu drugaciji (al nista sustinski).

u ovom istrazivanju sam cak naisao na primjere gdje ljudi rade serverske komponente/kontrole za generiranje client side UI logike (npr. stare navike Microsoftovih design-developera) sto je potpuno suprotno od smjera koji meni odgovara.
Server: data, client js:UI = za mene je to dobitna kombinacija. A trenutkom kad sam to otkrio konacno se osjecam puno vise kao kod kuce u mobilnom svijetu

[xippi]

Originalno napisao dee

Server: data, client js:UI = za mene je to dobitna kombinacija. A trenutkom kad sam to otkrio konacno se osjecam puno vise kao kod kuce u mobilnom svijetu

upravo to. radis kao bilo koji drugi one page app, js klijent kacis na rest api koji vraca json data. kakav html u odgovoru, kakvi bakraci

[srdjan]

Off Topic: Meanwhile, in hell...

http://westcoastlogic.com/slides/debug-mobile

[dee]

samo da javim...posto je ovo otislo vec prilicno daleko...

jquerymobile je sasvim ok za onu osnovnu, mobile-specific insfrastrukturu (pages, contents, headers, footers i svakako events), a sve ostalo - ria.
jos kad se u pozadini skuca neki web admin UI koji radi pages templates i strukturu sitea ovisno o userima, pravima, itd...to je stvarno krajnje fleksibilno rjesenje.

i, stvar na IPadu doslovno - leti. cist gust je razvijat to.

[dee]

evo i jednog konkretnog problema...

IPad 2, iOS 5.1
namjera je full screen web-app

sve do sada sam napravio kao single-page app i radi ko urica. sad sam dodao autorizaciju, ali kao odvojen page i to zeleci napraviti scenarij:

1) domena.com/login se dodaje na homescreen
2) domena.com/login provjerava da li vec postoji auth cookie (remember me). ako da, radi 302 redirect na domena.com/app. ako nema, daje formu za login i nakon uspjesnog logina takodjer redirecta na domena.com/app

scenarij:

1) radi u safariju
2) radi sa home screena kod mene na localhostu (sa IIS 6 kao web serverom)
3) ne radi na development serveru sa IIS7.5

e sad, dal je do servera il nije, nemam pojma. to je jedina razlika izmedju onog sto imam na localhostu i dev serveru.



pitanje je

treba li to uopce tako raditi ili bas sve strpati u jedan page i onda conditional layout (i js scripts) sa servera ovisno o tome dal je korisnik prijavljen (dakle, dal posluziti app ili login formu)?


dalje, ima nesto sto jos ne kuzim i ne mogu nigdje naci neku jasnu dokumentaciju.
vidim da je po internetu puno price o uiwebview, safari, home screen apps i cijela prica mi nije do kraja jasna. ono sto sam do sada skuzio je da postoje razlike...

- uiwebview je kontrola koja se koristi u native apps wrapperima koje vrte hml5 (dakle, o mi ne treba)
- safari je safari
- sta je home screen?

otvara li se we-app pokrenut s homescreena u safariju (samo bez sucelja) ili tu postoje razlike? taj dio mi je jos magla pa ako tko ima kakva konkretna iskustva i guidelines - bit cu jako zahvalan. dovoljna je i neka pristojna dokumentacija jer ili ja ne znam trazit ili bas i nema po webu to citko i lako dosupno objasnjeno.