SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007

Transkript

1 SMULTRON av Fredrik Li, Ester, Anders, Jessica, Philip Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007

2 - När man har turen att hitta en plats där man trivs så mycket att man vill bevara den för evigt, då har man hittat ett smultronställe - 1 Koncept Vi har designat en applikation för mobiltelefoner, som tillhandahåller en interaktiv karta. På denna karta kan användarna själva markera ut de platser i Malmö de gärna vill dela med sig av till andra. De kan exempelvis lägga in en bild och skriva om ett minne de har från den platsen, eller varför de tycker om just den platsen. På så sätt kan vem som helst få ta del av den informella informationen och lära känna sin stad genom andras ögon. Idén Själva idén med vår applikation är att det är användarna som genererar innehållet. Ju fler som använder applikationen och lägger in egna smultronställe, dess större blir den. Likt Wikipedia växer applikationen efterhand som användarna bygger ut den. Idén har vi fått från vår tidigare design uppgift där vi skapade en stadsvandrings applikation vid namn; Kultpunkt. Många av grundfunktionerna är de samma som i Smultron applikationen. Vi fascinerades allra mest av idén av att kunna ha en karta i sin mobiltelefon. En karta med GPS som skulle kunna visa var exakt på kartan man befinner sig. En karta kan användas till flera olika saker, speciellt med en GPS funktion. Detta gör applikationen ännu mer attraktiv. Vi valde att skapa applikationen för smultronställe då vi ville skapa någonting utöver det vanliga. Detta blir en tidsfördrivs baserad applikation som används mer för nöjes skull. Det utesluter inte att applikationen kan användas som en vanlig karta eller som turistinformation. Användningsområde samt Målgrupp Vi anser att vårt koncept appellerar till en väldigt bred användargrupp. Eftersom informationen inte är styrd centralt utan är användargenererad finns det egentligen ingen begränsning för vem som skulle vilja använda den, allt som krävs är en mobil som kan hantera färggrafik och Java, samt har mobilt Internet. Tittar man på andra användargenerarade webapplikationer som t.ex. myspace har de ofta vuxit bortom grundidén. Just nu koncentrerar vi oss på Malmöbor som vill lära sig mer om nya platser i sin hemstad samt att dela med sig av sina egna favoriter. Eftersom den är kostnadsfri och inte kräver registrering för att använda, såvida man inte önskar att lägga till smultronställen, kan man tänka sig att det även kunde vara en intressant applikation för turister. Ofta vill man som turist bara ha en lättillgänglig karta som alltid visar var man befinner sig. Som bonus får de även

3 möjlighet att ta del av andras Malmö, som inte turistinformationen kan informera om. 2 Framtidvision och kommersiella tankar. Vi anser att denna applikation bäst lämpar sig som gratistjänst. En eventuell finansiering av projektet skulle kunna vara en begränsad form av reklam. Att man kan köpa personliga ikoner istället för de fria smultronen. Turistinformationen, eller affärer och restauranger kan köpa sin egen ikon för att vara synligare för sina eventuella kunder. Att inte begränsa applikationen till Malmö, utan genom att bygga det runt någon form av karttjänst, exempelvis Google earth, skulle kunna innebära hela världen som kundgrupp. Teknisk beskrivning Vi har valt att implementera delar av Midlet i applikationens Canvas, för att få gränssnittet att se ut som vi verkligen vill.

4 Smultron är en applikation som bygger på ett gränssnitt inspirerat av vanliga windowsmiljöer, där den mesta av interaktionen sker via en pekare istället för listor och typiska mobilmenyer och listor. För att göra detta skapade Fredrik, en objektorienterad grafikmotor som enkelt tar hand om sådana saker som fönster och knappar samt pekaren. 3 Sprite-klassen; är en klass som extends Canvas och den paintar en bild som man namnger och skickar in genom konstruktorn. Där anger man även bildens position på Stage (se separat beskrivning) samt vilken typ av sprite det är. Det finns fyra olika typer av Sprite att välja på. graficobjekt; innehåller en bild. rolloverbtn; knapp som kan innehålla en alternativ bild som växlas till om den rör vid en annan sprite och som har en fast position ut på Stage. screenbtn; knapp utan RollOver med fast position på mobilens skärm. mousepointer; pekare som styrs med hjälp av telefonens piltangenter/joystick. Varje Sprite kräver inparametrar i konstruktorn som är; två bilder, x, y, anchorpoint för x & y, samt typ och om den är synlig. Varje sprite har även två funktioner för att kolla om den kolliderar med en annan valfri sprite som skickas in i funktionen när man kallar på den. Returnerar true om de upptar samma yta på Stage eller på mobilens skärm. Layer-klassen; innehåller en Vector med objekt av typen Sprite. Samt en boolean för synlighet (on/off) Stage-klassen; är i princip ett virtuellt område som kan vara i princip hur stort som helst. Klassen håller sedan koll på skärmens position över detta virtuella område. Samt en Vector bestående av Layer klassen och en pekare som aktiveras i konstruktorn. Man orienterar sig runt på Stage genom att styra pekaren och när den närmar sig kanten av skärmen flyttar sig Stage istället för pekaren. Sedan kan man definiera flera Layers med grafik och därigenom få full kontroll över vilken ordning grafiken ska ritas upp i, samt tända och släcka efter behov. Detta underlättar avsevärt utvecklingsarbetet då man kan fördefiniera olika arbetsytor och enkelt växla mellan dem. Det går även att enkelt lägga till nya Sprites dynamiskt inifrån programmet, eller som i vårt fall hämta information från en webservice och placera ut dem enkelt på i vårt fall, en karta.

5 Midlet vs. Stage: All inmatning av data sker genom Midlets. Därför var det viktigt att skapa ett enkelt sätt att växla mellan dessa två typer av grafik i vår applikation. Detta löste vi genom att skapa två SplashScreens som vi kallar portaler. Dessa innehåller Dismiss-action som tänder respektive släcker vår Stage. Sedan kan man bara kalla på funktionen från Stage som växlar till Midlet-läget och vice versa i Midlet. All Stage utveckling sker genom att programmera i StageKlassen och Midletten kan programmeras visuellt i NetBeans och ändringar i Midletten påverkar aldrig kopplingen till Stage, så man enkelt kan lägga till och ta bort element från de två utan att frukta haveri i den andra. 4 Gränssnittsanalys Vi har tagit mobiltelefonens begränsade skärm och knappar i betraktning när vi skapat vårt flödesschema. Vi har även tittat en hel del på hur de olika flödesschemana i våra mobiltelefoner ser ut, vilken struktur de har. Det ska vara så logiskt och okomplicerat som möjligt. Vi har försökt tänka på att inte klämma in för mycket på en och samma Form. Det är viktigt att applikationen ska kännas enkel och rolig att använda. Det är viktigt att skapa ett logiskt flödesschema som bekräftar ens handlingar utan att det går till det extrema så att det känns fördummande för användaren. Det räcker exempelvis att man, efter lyckad inloggning, kommer direkt till Formen där man kan lägga in ett nytt smultronställe. Efter detta får användaren en bekräftelse på att ens smultronställe skickats. Vi har valt att förtydliga konceptet med smultronställen genom att ha en ordentlig introduktionsbild för applikationen, ikoner och liknande i samma smultrontema. Färgvalet har gått i tonerna till smultronens färger rött och grönt. Själva kartan går i orange, grönt och vitt, och är lånad från och modifierat den så den passar vår applikation. Vi ville ha dessa färger för att leka lite med just smultron; glada färger som får en att tänka på goda saker och fina minnen. Projektgruppen Vi har i detta projekt kommit förvånansvärt bra överrens med tanke på hur lite tid vi hade på oss samt hur mycket vi hade att åstadkomma. Gruppen valde tillsammans ett relativt stort projekt så vi visste hur pass många timmar vi behövde lägga för att nå vårt mål. Samtidigt var alla överrens om att ett projekt med utmaning är det som ger alla mest i längden. Ingen av oss hade erfarenhet av att jobba med mobila enheter tidigare så detta var en stor utmaning både på den grafiska sidan samt programmeringssidan. Att jobba med små skärmar för mobila enheter är en väldigt annorlunda upplevelse när man är van vid att jobba för stora maffiga widescreenskärmar och webben.

6 Eftersom vi varit nya på samtliga områden för mobila enheter har vi försökt att rotera kunskaperna och lära oss tillsammans - detta är eventuellt något vi har förlorat tid på, men vi känner att vi har tjänat in detta i kunskap istället. Fredrik har dock haft huvudansvaret över kodningen. En sak vi känner oss lite irriterade över är att programmen fungerat under all kritik i datasalarna. Vi minns alla ett problem vi brottades med under en väldigt lång tid gällande vår serverapplikation. Felet var inte kodbaserat fick vi sedan reda på, vi hade kodat alldeles rätt, felet var ett skrivrättighetsproblem till de lokala datorerna vi inte hade. 5 Pitch