DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > Web aplikacije, web servisi i software
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

Web aplikacije, web servisi i software Frameworks, web servisi, programi, plugin-ovi, ekstenzije korisni za razvoj web sajtova. Sponzor: vivvo

Odgovori
 
Alati teme Način prikaza
Staro 11. 04. 2012.   #21
_korso_
profesionalac
Qualified
 
Avatar _korso_
 
Datum učlanjenja: 21.06.2007
Poruke: 166
Hvala: 27
42 "Hvala" u 23 poruka
_korso_ is on a distinguished road
Default

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.
__________________
Twitter

Poslednja izmena od _korso_ : 11. 04. 2012. u 17:50.
_korso_ je offline   Odgovorite uz citat
"Hvala" _korso_ za poruku:
Staro 11. 04. 2012.   #22
dee
Domagoj Horvat
Expert
 
Avatar dee
 
Datum učlanjenja: 24.07.2006
Lokacija: Zagreb
Poruke: 502
Hvala: 22
10 "Hvala" u 8 poruka
dee is on a distinguished road
Pošaljite ICQ poruku za dee
Default

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!
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo
dee je offline   Odgovorite uz citat
Staro 17. 04. 2012.   #23
xippi
xippster
Master
 
Avatar xippi
 
Datum učlanjenja: 16.06.2005
Lokacija: Beograd
Poruke: 680
Hvala: 102
138 "Hvala" u 84 poruka
xippi će postati "faca" uskoroxippi će postati "faca" uskoro
Default

e ovo postaje sve bolje http://www.sencha.com/products/architect
xippi je offline   Odgovorite uz citat
Staro 25. 04. 2012.   #24
dee
Domagoj Horvat
Expert
 
Avatar dee
 
Datum učlanjenja: 24.07.2006
Lokacija: Zagreb
Poruke: 502
Hvala: 22
10 "Hvala" u 8 poruka
dee is on a distinguished road
Pošaljite ICQ poruku za dee
Default

Citat:
Originalno napisao _korso_ Pogledajte poruku
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?
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo
dee je offline   Odgovorite uz citat
Staro 26. 04. 2012.   #25
_korso_
profesionalac
Qualified
 
Avatar _korso_
 
Datum učlanjenja: 21.06.2007
Poruke: 166
Hvala: 27
42 "Hvala" u 23 poruka
_korso_ is on a distinguished road
Default

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.
__________________
Twitter
_korso_ je offline   Odgovorite uz citat
Staro 26. 04. 2012.   #26
dee
Domagoj Horvat
Expert
 
Avatar dee
 
Datum učlanjenja: 24.07.2006
Lokacija: Zagreb
Poruke: 502
Hvala: 22
10 "Hvala" u 8 poruka
dee is on a distinguished road
Pošaljite ICQ poruku za dee
Default

Citat:
Originalno napisao _korso_ Pogledajte poruku
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:

Citat:
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
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo

Poslednja izmena od dee : 26. 04. 2012. u 14:28.
dee je offline   Odgovorite uz citat
Staro 26. 04. 2012.   #27
xippi
xippster
Master
 
Avatar xippi
 
Datum učlanjenja: 16.06.2005
Lokacija: Beograd
Poruke: 680
Hvala: 102
138 "Hvala" u 84 poruka
xippi će postati "faca" uskoroxippi će postati "faca" uskoro
Default

Citat:
Originalno napisao dee Pogledajte poruku
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
xippi je offline   Odgovorite uz citat
Staro 27. 04. 2012.   #28
srdjan
SYS 64738
Grand Master
 
Avatar srdjan
 
Datum učlanjenja: 25.10.2006
Lokacija: Preko Morače
Poruke: 893
Hvala: 87
346 "Hvala" u 163 poruka
srdjan ima spektakularnu aurusrdjan ima spektakularnu aurusrdjan ima spektakularnu aurusrdjan ima spektakularnu auru
Default

Off Topic: Meanwhile, in hell...

http://westcoastlogic.com/slides/debug-mobile
__________________
mookieapp.com
mobile app for you and your dog
srdjan je offline   Odgovorite uz citat
Staro 15. 05. 2012.   #29
dee
Domagoj Horvat
Expert
 
Avatar dee
 
Datum učlanjenja: 24.07.2006
Lokacija: Zagreb
Poruke: 502
Hvala: 22
10 "Hvala" u 8 poruka
dee is on a distinguished road
Pošaljite ICQ poruku za dee
Default

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.
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo

Poslednja izmena od dee : 15. 05. 2012. u 01:14.
dee je offline   Odgovorite uz citat
3 članova zahvaljuje dee za poruku:
Staro 16. 05. 2012.   #30
dee
Domagoj Horvat
Expert
 
Avatar dee
 
Datum učlanjenja: 24.07.2006
Lokacija: Zagreb
Poruke: 502
Hvala: 22
10 "Hvala" u 8 poruka
dee is on a distinguished road
Pošaljite ICQ poruku za dee
Default

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.
__________________
postoje ludosti bez kojih je nemoguce ljudsko dostojanstvo
dee je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum


Vreme je GMT +2. Trenutno vreme je 11:07.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.