mboost-dp1
newz.dk app til adroid og iphone
- Forside
- ⟨
- Forum
- ⟨
- newz.dk
SCA har udtalt, at en mobilside (ala mobilz.newz.dk) er på tegnebrættet. Der sker dog ikke noget any time soon.
Men en app ligefrem?! Nej, siden er fin nok, som den er.
Men en app ligefrem?! Nej, siden er fin nok, som den er.
det er en smule træls at side og zome ind hele tidentiden(har xperia play)Daniel-Dane (2) skrev:SCA har udtalt, at en mobilside (ala mobilz.newz.dk) er på tegnebrættet. Der sker dog ikke noget any time soon.
Men en app ligefrem?! Nej, siden er fin nok, som den er.
Går man ind på mobilz.newz.dk så kommer man bare ind på newz.dk
Dobbeltklik på tekst, done.mikk4237880 (3) skrev:det er en smule træls at side og zome ind hele tidentiden(har xperia play)
Hvis man nu gerne vil havde en app er det så ikke bare at starte her:
http://www.freeblogapps.com/
og bruge den her newz.dk/rss/news/personal/[ditbrugernavn]
http://www.freeblogapps.com/
og bruge den her newz.dk/rss/news/personal/[ditbrugernavn]
Hvilket desværre kun er de seneste nyheder.Emil (6) skrev:Hvis man kun er ude efter nyhederne, så kan man jo bare hente en RSS-app og smide ens personlige feed ind i den.
Jeg har prøvet at analysere newz.dk's forskellige RSS feeds, og javascript APIs, og der kan desværre ikke bygges en mobil-app uden seriøst web-scrapping.
Hvis newz.dk nu bare kunne stillet et REST API til formålet, så kunne brugerne jo selv bygge app's til de forskellige mobile platforme.
Ligesom videovideo.dk , der fungere det perfekt!
Windcape (8) skrev:Hvis newz.dk nu bare kunne stillet et REST API til formålet, så kunne brugerne jo selv bygge app's til de forskellige mobile platforme.
Som jeg har forstået det, så eksisterer der ingen dokumentation til det nuværende system, da der kun er én koder på det; så at stille et API til rådighed ville kræve ligeså megen tid brugt på dokumentation, som på selv at lave det.
Windcape (11) skrev:Scary :o
Nu er jeg ikke selv koder, og jeg har mindre end 0 % forstand på alt sådan noget systemarkitektur. Så kan du ikke lige forklare mig, hvorfor det er vigtigt at have dokumentation, hvis der ikke er andre, som arbejder på et system end en selv? Der må jo være nogle grunde, og nu har jeg prøvet i en 5 min. at tænke mig til dem, men det er ikke rigtig lykkedes.
Fordi én person på ingen måde kan huske alting i et system.Emil (12) skrev:Så kan du ikke lige forklare mig, hvorfor det er vigtigt at have dokumentation, hvis der ikke er andre, som arbejder på et system end en selv?
Det er derfor nemmere at dokumentere løbende. Og det gør det ligeledes så nemmere at få andre/flere udviklere involveret, skulle det blive nødvendigt.
Eller når denne "ene" person smutter til USA *host*, og efterlader systemet, så har dem som skal overtage det, faktisk noget at gå ud fra. *host*
Derudover ville jeg jo altid argumentere for en service-baseret system-arkitektur, hvor brugerfladen bare var et brugerflade lag, og ikke faktisk en del af systemet som det åbenbart er i dag.
Det er ihvertfald mit indtryk, at rigtig store dele af newz-media platformen skal restruktures hvis den skal kunne benyttes fra mobile. Eller også skal der skrives en parellel platform der benytter nogenlunde samme data.
Sider som f.eks. DR.dk har denne form for service-orienteret arkitektur, hvilket gør dem supernemme at skrive mobile apps til.
Men for at være lidt fordømmende, så er det rimelig ærketypisk PHP udviklere at vælge en løsning hvor man laver tight-coupling af UI og det bagvedliggende logik.
Med frameworks som Rails eller ASP.NET MVC3, så kan man lave alternative brugerflader til samme services, med enkelte klik. PHP synes ikke rigtig at tilbyde det samme.
#12
Prøv og forestil dig at den ene person træder ud foran en bus.
http://en.wikipedia.org/wiki/Bus_number
Prøv og forestil dig at den ene person træder ud foran en bus.
http://en.wikipedia.org/wiki/Bus_number
Derudover behøver et API jo ikke være dokumenteret i den grad, det handler mere om at vi for noget ala.
api.newz.dk/site/<SiteName>/forum/all
api.newz.dk/site/<SiteName>/forum/<ForumName>
api.newz.dk/site/<SiteName>/forum/<ForumName>/<ThreadID>/
api.newz.dk/site/<SiteName>/forum/<ForumName>/<ThreadID>/<PostID>/
api.newz.dk/site/<SiteName>/forum/all
api.newz.dk/site/<SiteName>/forum/<ForumName>
api.newz.dk/site/<SiteName>/forum/<ForumName>/<ThreadID>/
api.newz.dk/site/<SiteName>/forum/<ForumName>/<ThreadID>/<PostID>/
Windcape (8) skrev:Hvis newz.dk nu bare kunne stillet et REST API til formålet, så kunne brugerne jo selv bygge app's til de forskellige mobile platforme.
Ethvert fornuftigt API kan gøre det.
Et RESTFul API med JSON som transport format ville være "hot", men det er ikke eneste mulighed.
Emil (9) skrev:Som jeg har forstået det, så eksisterer der ingen dokumentation til det nuværende system, da der kun er én koder på det; så at stille et API til rådighed ville kræve ligeså megen tid brugt på dokumentation, som på selv at lave det.
Nej.
API'et ville skulle laves og dokumenteres en gang.
Det kan så genbruges i mange sammenhænge: iPhone app, Android app, WP7 app, jeres interne AJAX kode etc..
Derudover bør API'et være ret stabilt over tid mens mobile apps udvikler sig megt hurtigt lige for tiden.
Windcape (13) skrev:Derudover ville jeg jo altid argumentere for en service-baseret system-arkitektur, hvor brugerfladen bare var et brugerflade lag, og ikke faktisk en del af systemet som det åbenbart er i dag.
Windcape (13) skrev:Sider som f.eks. DR.dk har denne form for service-orienteret arkitektur, hvilket gør dem supernemme at skrive mobile apps til.
Øhm.
Opdeling i lag (hvadenten man foretrækker PL-BLL-DAL, PL-CL-BLL-DAL eller noget tredie) er godt.
SOA er godt.
Men de har ikke noget med hinanden at gøre.
SOA er groft sagt når BLL i app X bruger BLL i app Y.
Windcape (13) skrev:Men for at være lidt fordømmende, så er det rimelig ærketypisk PHP udviklere at vælge en løsning hvor man laver tight-coupling af UI og det bagvedliggende logik.
PHP er et af de sprog der har flest dårlige udviklere.
Det er straffen for at være et nemt sprog at lære.
Ada95 har ikke det problem.
Men jeg vil være forsigtig med at konkludere at man skal lav sprog så vanskelige som muligt at bruge for at forhindre dårlige udvikler i at bruge dem.
Windcape (13) skrev:Med frameworks som Rails eller ASP.NET MVC3, så kan man lave alternative brugerflader til samme services, med enkelte klik. PHP synes ikke rigtig at tilbyde det samme.
Specifikke PL/PL+CL teknologier har ikke særligt meget med separation af lag at gøre.
Der er massr af MVC framework i PHP.
Hvad ser du som andre muligheder? Du skal jo huske, at det helst skal være supportet af en telefon, og derfor gerne være MEGET lightweight.arne_v (16) skrev:Et RESTFul API med JSON som transport format ville være "hot", men det er ikke eneste mulighed.
JSON er f.eks. at foretrække over XML, fordi at størrelsen af dataen, selv for et lille antal kilobyte, betyder en hel del for performance/hastighed.
Jeg har netop publiseret en WP7 udgave af videovideo.dk her til aften, så ja ;-)arne_v (18) skrev:Jeg vil vurdere at der 99.99% sandsynlighed for at Windcape netop ville bruge API til at lave en WP app.
Ja, når du har mere end én app. Det betyder ikke at du ikke kan designe hele dit system som serviceorienteret selvom du kun har én app.arne_v (19) skrev:SOA er groft sagt når BLL i app X bruger BLL i app Y
F.eks. på newz, ville det jo betyde at jeg bruge deres services til at poste og rate indlæg med, som vel netop er deres BLL.
Min app er så Y (mobil), deres app er X (newz.dk web)
Ja, men jeg synes imo. PHPs struktur altid har været dårligt når det kommer til at have forskellige views for samme data.arne_v (20) skrev:Der er massr af MVC framework i PHP.
Jeg har da selv brugt et par år med en del frameworks, inklusiv Zend som newz.dk bruger. Det er bare et punkt jeg synes at ASP.NET og Ruby er *langt* foran PHP.
Windcape (22) skrev:Ja, når du har mere end én app. Det betyder ikke at du ikke kan designe hele dit system som serviceorienteret selvom du kun har én app.
Eneste grund til at lave det SOA med en app er hvis man forventer flere apps.
Der er selvfølgelig god grund til at lave lagdeling.
Windcape (22) skrev:
F.eks. på newz, ville det jo betyde at jeg bruge deres services til at poste og rate indlæg med, som vel netop er deres BLL.
Min app er så Y (mobil), deres app er X (newz.dk web)
Jeg vil betragte mobil som værende et PL evt. PL+CL ikke et BLL.
Hvis newz.dk skulle lave noget SOA ville det være en opdeling i:
users
emails
newz
filmz
...
Windcape (21) skrev:
Hvad ser du som andre muligheder? Du skal jo huske, at det helst skal være supportet af en telefon, og derfor gerne være MEGET lightweight.
JSON er f.eks. at foretrække over XML, fordi at størrelsen af dataen, selv for et lille antal kilobyte, betyder en hel del for performance/hastighed.
JSON har nogle reelle bandwidth fordele lige nu (de er nok forsvundet om en 3-4 år men det er en anden sag) så JSON som transport format er oplagt.
Men om servicen er RESTful eller en mere traditionel RPC med HTTP binding er ikke helt så oplagt.
#24
Principelt skal det jo bare være services der alle sammen benytter samme domæne lag (og dermed alt derunder)
Du kan vel også betragte api.newz.dk/users/ som en seperate service fra api.newz.dk/forums/
Rent implementeringsmæssigt er SOA for et content-provider site som newz.dk relativt simpelt, og er praktisk talt bare lagdeling med forskellige output metoder (HTML eller JSON, more or less)
Principelt skal det jo bare være services der alle sammen benytter samme domæne lag (og dermed alt derunder)
Du kan vel også betragte api.newz.dk/users/ som en seperate service fra api.newz.dk/forums/
Rent implementeringsmæssigt er SOA for et content-provider site som newz.dk relativt simpelt, og er praktisk talt bare lagdeling med forskellige output metoder (HTML eller JSON, more or less)
#29
Tjo.
Men lag opdeling var allerede veletableret da SOA blev "opfundet".
Der er nogen som siger at SOA står for "Same Old Architecture".
Det er dog ikke helt korrekt - man har hævet abstraktionsniveauet.
laveste abstraktion - opdeling af kode i funktioner/subroutiner/metoder for funktion/subroutine/metode genbrug
midterste abstraktion - opdeling af apps i komponenter/lag/moduler for komponent/lag/modul genbrug
højste abstraktion - opdeling af virksomhed i funktionalitet/applikationer for funktionalitet/applikation genbrug
Tjo.
Men lag opdeling var allerede veletableret da SOA blev "opfundet".
Der er nogen som siger at SOA står for "Same Old Architecture".
Det er dog ikke helt korrekt - man har hævet abstraktionsniveauet.
laveste abstraktion - opdeling af kode i funktioner/subroutiner/metoder for funktion/subroutine/metode genbrug
midterste abstraktion - opdeling af apps i komponenter/lag/moduler for komponent/lag/modul genbrug
højste abstraktion - opdeling af virksomhed i funktionalitet/applikationer for funktionalitet/applikation genbrug
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.