Projektuppgift- Mashup- Applikation

Transkript

1 Projektuppgift- Mashup- Applikation Som avslutning på denna kurs är det tänkt att Du ska bygga en egen mashup- applikation. Du ska bygga en komplett applikation som du utan tvekan skulle kunna vilja visa upp för tilltänkta kunder eller arbetsgivare. Vi räknar alltså med att din färdiga applikation ska se professionell ut och ha en genomtänkt och genomarbetad design. Vi kommer lämna val av teknik och implementerade funktioner upp till dig själv med undantag för vissa specifika krav. Du är fri att använda andra API:er utöver de vi anger och du är fri att studera olika lösningar för att få din webbapplikation precis som du vill ha den. Uppgiften En vädertjänst Tanken med uppgiften är att du ska skriva en webbapplikation som fungerar som en vädertjänst. Till din hjälp har du API:erna som finns för YR.no och för GeoNames, de två API:erna bör du studera noga innan du börjar på uppgiften. Med hjälp av dessa API:er är det tänkt att du ska skriva en dynamisk webbapplikation som presenterar vädret för olika tätorter beroende på vad användaren vill se. Med hjälp av geonames är tanken att ni ska hitta tätorter och använda dessa för att göra uppslag mot YR. I detta projekt läggs störst vikt vid klienten och presentationen av den data du hämtar samt interaktiviteten med applikation. Din klientapplikation ska endast hämta data via asynkrona anrop vilket gör att applikationen inte ska ge någon form av postbacks. Om du önskar att göra en egen applikation istället för vädertjänsten så se information om detta i slutet av denna handledning. Läs dock igenom informationen kring väderapplikationen för att bilda dig en uppfattning av uppgiftens omfattning. Viktiga datum :00 Om du inte väljer att göra en väderapplikation är detta den senaste tidpunkten för inlämning av en kort beskrivning av din egna idé :00 Din rapport alt. blogglänk ska vara inskickad till john.haggerud@lnu.se Muntlig redovisning. Mer information om tider kommer anslås senare på kursens webbplats.

2 Tekniker Du är fri i ditt teknikval. Vill du använda PHP eller ASP.NET som backend så har du tillgång till dessa tekniker på laborationsservern. Önskar du använda andra tekniker så får du själv drifta projektet. Lykke til! Johan och John Utvecklad av Johan Leitet och John Häggerud Sidan 2 av 6

3 Krav som ska uppfyllas för godkänd: För godkänt betyg i kursen ska din applikation uppfylla nedanstående beskrivning. Väderprognos: Applikationens huvuduppgift är att visa en femdagarsprognos på ett grafiskt tilltalande sätt. Den prognos som användaren möts av ska ha tydliga ikoner som visar vilket väder som gäller, i övrigt är det upp till dig att välja hur din mycket information som ska visas på prognosen. Det ska tydligt framgå för vilken tidpunkt varje prognos gäller. Det ska gå att få mer detaljerad information om en speciell tidpunkt. Bland annat så ska man kunna läsa ut temperatur, lufttryck, vindhastighet och vindriktning. Du kan säkerligen hitta väderikoner på nätet som är fria att använda. När du arbetar mot YR.no är det viktigt att du är disciplinerad i dina anrop och att du inte gör fler anrop än du får göra. Du ska alltså lägga stor vikt vid att implementera en lösning för cachning. Ett smart tips kan vara att ladda ned en xml- fil och lägga på din egen server och testa mot denna innan du vet att allt fungerar. Utvecklad av Johan Leitet och John Häggerud Sidan 3 av 6

4 Navigation: I applikationen ska användaren kunna navigera på två sätt: 1 Geolocation, startläge Om användarens enhet har stöd för geolocation ska detta användas genom att automatiskt försöka bestämma användarens plats och göra ett uppslag beroende på denna d.v.s. visa en 5- dagarsprognos för den plats man befinner sig på. 2 Sökning Användaren ska kunna söka på tätorter. Om enbart ett resultat hittas så ska användaren tas till väderprognosen för denna tätort. Om flera orter hittas ska användaren få välja vilken tätort som efterfrågas genom att välja i en lista. Din sökning gav 2 resultat, vilken ort söker du? Oskarshamn, Kalmar Oskarshamn, Stockholm Då en sökning från användaren sker ska din applikation i sin tur genomföra en sökning mot GeoNames.org för att få ut efterfrågad tätort. Då en av användaren triggad sökning i detta fall ska leda till en sökning mot GeoNames.org så får du inte i detta steg implementera en sökning som börjar sökningen så fort användaren trycker ner en tangent ( ajaxsökning ) då detta skulle leda till orimligt många anrop mot GeoNames. Vill du implementera en sådan sökning måste du själv först se till att alla ortsnamn finns lagrade lokalt på din server. Det är dock tillåtet att göra ett ajaxanrop per sökt tätort. Om du undersöker GeoNames search- funktion kommer du att upptäcka att denna har stöd för paging. Cache: Du bör fundera över något sätt att cache:a sökningar på servern. Dels för att öka prestandan i din applikation och för att slippa skicka onödiga förfrågningar. Local Storage Klient- applikationen ska kunna spara sina 10 senaste sökningar på något vis för att kunna ges möjlighet att använda dessa som snabbval vid sökning utan att behöva skriva in dem. Man bör också kunna spara favoritplatser som man snabbt ska kunna komma åt och få upp en väderprognos för. Dynamisk applikation Applikationen måste vara dynamisk där data från ett API kopplas till förfrågningar till ett annat. Det får alltså inte finnas några hårdkodade värden (t.ex. städer) i din applikation utan sådan information ska läsas från externa platser alt. lokalt cache:ade versioner. Utvecklad av Johan Leitet och John Häggerud Sidan 4 av 6

5 Felhantering Hur är felhantering och validering implementerad? Vad händer om ett av eller båda API:erna slutar att svara eller får förändrad struktur? Dokumentation Du ska på ett bra sätt dokumentera din applikation så man enkelt och tydligt kan få en överblick av vad du gjort. Dokumentationen ska lämnas in i pdf- format alternativt publiceras som ett blogginlägg (skicka in länken till oss). Detta ska göras två dagar innan redovisningen. Följande delar ska tas upp i dokumentationen: Inledning En kort beskrivning av arbetet och dess syfte. Serversida Beskriv hur du byggt din applikation på serversidan. Hur löste du cachningen? Hur länge cachas din data och varför denna tid? Hur har du funderat kring felhantering? Klientsida - Beskriv funktionaliteten i din klientapplikation. Vilka tekniker har du jobbat med? Beskriv hur du använt geolocation och local storage. Ta gärna med någon skärmdump på designen. Hur är det tänkt att användaren ska arbeta med applikationen. Funktioner du anser betygshöjande Beskriv de eventuella funktioner som du implementerat (bortsett från de krav som finns) som du anser vara betygshöjande. Egen reflektion Här tar du upp hur du själv ser på arbetets gång. Har några speciella problem uppstått? Hade du velat implementera saker som inte hanns med? Din applikation ska också kunna nås av oss via en länk. Antingen via vårt VPN eller på en av dig kontrollerad publik server. Genomarbetad design Nej, ogenomarbetad och fantasilös design är inte lika med enkelt och stilrent! Det ska synas att du gett kärlek till din applikations design och inte bara dumpat ut informationen. Eventuellt betygshöjande krav: Bedömningen kommer att ske genom att kursledningen bedömer din applikations funktionalitet, utseendet, hur du använt de tekniker som finns att tillgå, hur rapporten utformats samt hur applikationen presenteras vid redovisningstillfället. Här är lite mer konkreta punkter som också kan vara betygshöjande: Utvecklad av Johan Leitet och John Häggerud Sidan 5 av 6

6 Kanske finns det ytterligare API:er du kan blanda in i din applikation för att höja upplevelsen och ge din applikation mer funktionalitet? Autentiering via t.ex OAuth mot andra tjänster Finns det ytterligare sätt att söka efter väderprognoser? Kanske karttjänster? Naturligtvis ska dina lösningar och idéer ska vara så pass unika att vi kan se att det är du som har utvecklat applikationen själv och inte tillsammans med en klasskamrat. Undersök fler tekniker kring HTML5- relaterade API:er och tekniker och implementera dessa på ett bra sätt. Studera och implementera hur din applikation skulle kunna fungera i ett offline- läge. Glöm inte att dokumentera de delar av din applikation som du tycker är betygshöjande. Jag har en egen idé som jag vill testa Kanske vill du testa några andra API:er för att bygga upp din mashup- applikation? Din applikation ska ha samma omfattning som ovan beskrivna och har samma krav på sig. Innan du sätter igång hör du av dig till kursledningen och beskriver din applikation och tankar kring den för att få ett godkännande. Redovisning och examination Redovisningen består av tre delar: 1) Din skriftliga rapport av projektet. Denna ska vara inskickat minst 2 dagar innan redovisningen. Inskickningen av denna rapport ger möjlighet att få en redovisningstid. 2) Din muntliga redovisning. Under max 10 minuter presenterar du din applikation och svarar på frågor från kursledningen. 3) Efter avslutad redovisning skickar du in din kod zippad i en fil till kursledning samt en länk till din publicerade applikation. Kursledningen försöker efter genomförd redovisning sätt ett betyg på ditt projekt med hänseende på de krav som finns beskrivna i detta dokument, eventuella extra funktioner utöver kraven samt de ovan tre punkter. För högre betyg än 3 krävs att projektet har redovisats innan kursen avslutats (se kursens planering). Utvecklad av Johan Leitet och John Häggerud Sidan 6 av 6