mobiles web app
 

Naisao sam ovdje na temu, ali je ona otisla u drugom smjeru (native vs cross-platform something).

mene zanima konkretno...

ima li tko kakva iskustva sa razvojem web aplikacija za mobilne uredjaje? ako da, je li koristio koji framework? ako da, koji?

do sada sam naisao na par, od kojih sam probao jedino jquery-mobile. (probao znaci - par dana gledao primjere i skucao pokoju stranicicu, ali nista sto bi se moglo nazvati ozbiljnim)

sad mi pak treba nesto sto moze razvit financial times mobile app.

ima li tko iskustva? koji framework je good enough?

hvala
pozdrav

Nedavno sam otkrio www.codiqa.com

Disclaimer: nisam mobile web dev pa ne mogu da komentarišem kvalitet koda, standarde i sl.

Ali ovo tako lepo radi, da razmišljam da postanem full korisnik. Kod sebe vidim primenu za:

a) brz wireframing i shareovanje klijentima ideja za UI,
b) razvoj web stranica koje se prikazuju u native aplikacijama kroz WebView.

Bavim se razvojem web sajtova/aplikacija za mobile. Radimo tako da se Web optimizuje za vise telefona/rezolucija, dakle web u backendu je klasican PHP kod, a front se pravi u 3,4 verzije i u zavisnosti na kom mobilnom se otvara web ucitava se odredjena verzija.
Treba da pocnemo da radimo verziju i za JQuery mobile i ta verzija bi se ucitavala iskljucivo za neke novije modele... to je neko moje iskustvo da mozes da dobijes najsiru pokrivenost.

Ovo vrlo zanimljivo izgleda. Slicna stvar kao i http://www.umbrellasdk.com/index.htm (take a tour). Ono sto mi je zanimljivo kod tvog linka je da je u pozadini jquery mobile. vrlo mi se svidio taj framework. Sam SDK mi po sebi nije toliko zanimljiv, ali u kontekstu ovog sto kazes 'brz wireframing i shareovanje klijentima ideja za UI,' - to je fantasticna opcija! tako da cu odmah otvorit profil i probat to malo.

Ono sto je zapravo moje pitanje jest - da li jQuery Mobile ili Sencha ili nesto trece?...odnosno, koji bi bili neki pros/cons svakog.
Sto me najvise 'brine' jesu performanse i ponasanje u stvarima koje glume native applikacije. Recimo, page transitions, podjela jednog html-a na vise logickih cjelina (pages u kontekstu jQuery Mobile-a), kako to radi na zivim primjerima, je li upotrebljivo, itd itd...jer, u sustini, to je i razlog radi kojeg bi se covjek odlucio za neki mobile web app framework. sve ostalo ide i obicnim javascriptom/jquery-jem.

Ovo je smjer kojim cu i ja morati ici. Doduse, nece biti 3,4 verzije nego za sada dvije: iPhone - iPad. Ali ista spika - backend isti a frontend u par verzija.

Jeste li gledali neki drugi framework osim jQuery Mobile? I ako da, zasto ste se odlucili bas za njega?

ja sam se u poslednjem projektu koji radim odlucio za sencha touch bas zbog razloga da ne radim frontend u vise verzija. jedina druga opcija koja valja je backbone.js + jq mobile, mada u ovom trenutku sencha touch radi brze od te kombinacije

sa druge strane ogroman minus za ST2 predstavlja nedostatak dokumentacije tako da je potrebno buljati po primerima da bi se nasao primer funkcionalnosti

a da, ako senchu uzimas u obzir pomiri se sa time da ti treba mac posto je sdk za win totalno sjeban

vise verzija front-enda mi je prakticno zahtjev korisnika (drugacije ce izgledati na iPhone/iPad) tako da tu nemam neki izbor.

na osnovi toga, pretpostavljam, jquery mobile je neki put.

ocito vise ne uzimam :)

ajd da se nadovezem malo, osnovna razlika izmedju jqma i senche je sto uz senchu dobijes kompletnu mvc platvormu dok ovde to moras da izvedes upotrebom jos neceg (po meni je backbone najkul). takodje mi se cini da je da je samo pravljenje panela (nesting i ostalo) u novoj senchi jednostavnije nego u jqm od kako su promenili extjs sintaksu u verziji 4. takodje mape i takve stvari su intergisane u senchi i to radi mnogo glatkije nego recimo jqmaps

preporuka ti je da pogledas sam, je inace zagovaram jqm ali je u ovom konkretnom projektu koji radim sencha mnogo prikladnija

inace onaj sdk sluzi da pokupi iz sencha appa sav potreban js i da ga zapakuje u jedan fajl spreman za produkciju, tako da mozes da razivijas app i konacan proizvoid samo zapakujes preko mac masine. u tom istom slucaju moras sam da dodajes kontrolere i ostalo jer ne mozes da koristis autogenerate. to sve pricam jer sam na linuxu :)

vrijeme je za posao...
krecem s jquery mobile pa cemo vidjet kud cu izbit.

hvala svima!

Ja sam koristio jquery mobile, lepo radi. Sve sto je xippi rekao, ista iskustva imam. Drago mi je da ima ljudi koji koriste backbone, to je ovde veliki hit. Ja sam licno fan spinejs-a koji je na neki nacin verzija backbone-a ali generalno volim taj pristup.

Iako je responsive web design dosta popularan danas, ipak kad smo razmisljali da li da prelazimo na tu verijantu odgovor je ipak bio "jos uvek NE"

http://www.webdesignshock.com/respon...sign-problems/

Dakle, Ima svojih prednosti ali i mana.

U svakom slucaju ako je zahtev tvog klijenta da web radi samo za IPod/IPhone onda je ok da koristis JQuery Mobile, kod mene je slucaj da moram da optimizujem i za starije telefone gde na mnogim ne radi JS, a ni sve opcije CSS-a tako da je to malo teze ...

Responsive nije opcija vec iz razloga sto ce vise stvari biti prikazano na iPadu nego iPhoneu, a i previse mirise na jedno-rjesenje-za-sve-probleme.

tako da, za sad idu dvije verzije, a ako ih u buducnosti bude jos - dodavat ce se.
sretna okolnost je da nas ne zanimaju stariji telefoni.

naisao sam na konkretan problem...
login...odnosno, autorizacija korisnika opcenito. kako je to najbolje rijesiti?

kako uklopiti ajax navigaciju i autorizaciju?
dakle, koristim one page template i svidja mi se data-prefetch mogucnost da ucitam linkane stranice radi boljeg user experienca. medjutim, kako to uklopiti sa loginom? npr, ako imam:

-indexPage
|---subPage1 (ne trazi autorizaciju)
|---subPage2 (trazi autorizaciju)
|---subPage3 (trazi autorizaciju)

kako se rjesava situacija $.mobile.changePage(subPage2) i provjera da li je korisnik logiran?

ne treba mi nikakav konkretan kod, cisto nacelno...

tnx

Postoji standardni nacin za resavanje autorizacije korisnika, a to je ACL

Skoro svaki framework ima svoje biblioteke za to, a mozes da ih koristis i bez fremeworka. (za ovako nesto bi trebalo otvoriti novu temu ako vec ne postoji ...)

cek, nije valjda da acl stoji na clientu? :)

acl je na serveru, ali kako se to rjesava u kontekstu jquerymobilea? recimo, koristim li data-prefatch kao neregistrirani korisnik za stranicu koja trazi registraciju - gdje cu i kako handlati unauthorized odgovor servera?

ne zanima mene registracija korisnika generalno vec kako se rjesava u jquery mobile-u specificno u kontekstu ajax navigacije? dakle, client side prije svega.

ACL je sa serverske strane.

Ja to resavam tako sto ako acl vrati da user nema pristup nekoj stranici vrati mu login stranicu kao view fajl. u jquery mobile-u nisam radio nista ...

Naravno. Taj dio imam i ja rijesen na serveru po ulogama, bla bla. (iako nisam imao pojma da to ima neko posebno ime :D )

Medjutim, imam npr implementiran swipeleft|right event za navigaciju medju stranicama, a stranice su mi data-prefetch. Kako rijesis mogucnost da stranica koja ne treba autorizaciju prefetch-a neku koja treba? Odnosno, sto se u tom slucaju desi ako nelogirani korisnik dodje i napravi swipe prema stranici koja treba autorizaciju?

Za sad koliko vidim, to bi se jedino moglo ako se prefetch radi iz javascripta i lovi pageloaded (nisam siguran u ime) event za svaku i na njoj provjerava sto je server vratio.

Poanta je...da bi swipe radio lijepo i smoothly, stranica mora imati prefetch. A prefetch moze naici i na unauthorized.

Pa serverski ACL sistem mora da postoji.
Imas verovatno vise mogucnosti da ovo resis, sto zavisi od vise stvari verovatno.

Jedna od mogucnosti je da nemas ACL na clientu. Kada si npr. na stranici 2, ti trebas odraditi prefetch za 1 i 3. Ispalis request ka serveru, server vrati npr. status 403 forbidden ili kako god da implementiras ovu "gresku" da kazem, a ako vrati podatke onda ih smestis tamo gde zelis. I korisnik na swipe dobije podatke. Ako pak je vracen kod greske, onda npr. ostavis ga na toj stranici gde je trenutno i prikazes obavestenje da nije autorizovan, ponudis dugme/stranicu za autorizaciju ili home...

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.

//edit
Backbone.js ili varijante tipa ember.js. spine.js, su bas i napravljene za neke ovakve varijante, posto vec radis sa jqueryjem. Mozda da odvojis 2-3 dana i probas da vidis da li ti odgovara.

ovo zvuci odlicno i svakako optimalno. napravi se prefetch samo onih koje smije vidjeti i na osnovi toga se slozi i swipe-flow, nazovimo to tako.
ono sto je meni bilo maglovito je ta promjena paradigme: nemamo klasican request vec onaj koji se dogadja u pozadini, a na osnovi njega treba definirati ponasanje onog sto je vec na ekranu (200/403 prefetcha u pozadini odredjuje swipe ponasanje trenutne stranice).

cini se da cu morat.
vidjet cu koliko mi je lako/tesko implementirati ovaj flow bez njih (jer imam trenutno prilicno ograniceno vrijeme), ali ocito u svakom slucaju vrijedi pogledati.

puno ti hvala, sad je dosta toga jasnije!

e, jos nesto...
ne mogu taj dio nigdje naci, a vidio sam implementirano (npr na app.ft.com)

naime, u jquerymobile swipe ima neki treshold. pod time mislim, prati prst i kad ga pomaknes odredjeni broj pixela u neku stranu on okine odgovarajuci swipe event. medjutim, tad vise ne slusa prst. ne mozes npr. zaustaviti swipe upola na nacin da recimo prstom kontroliras tranziciju izmedju 2 stranice (i da, recimo, postavis tako da ti je pola svake stranice vidljivo).

da li je to uopce izvedivo u jquerymobile-u za swipe medju stranicama ili bi to podrazumijevalo ciganjenje sa overflow:hidden containerom koji bi listao <ul><li>... u sebi, a svaki <li> bio jedan page?

i, ako je to na tragu rjesenja, koliko je to u duhu mobile ux, a koliko ciganjenje?

tnx

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.

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!

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

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?

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 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 :)

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

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.

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.

sad vidim - ne snima mi cookies. kao da sam stavio samo session cookie, ignorira timespan.

[EDIT]moze li mi netko potvrdit, je li ovo normalno na full screen apps? i, ako da, sta to znaci? da koristim local.storage za takve stvari?

prokleti amater.
previdio da nigdje ni ne postavljam cookie.expires :1054:

ispricavam se svima koji su se nacitali...ocito je vrijeme za odmor.

ma bjezi, bruka :)