HOVEDPROSJEKT. Mobile Apps for ios og Android Plattformer

Transkript

1 PROSJEKT NR. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo 17 TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Mobile Apps for ios og Android Plattformer PROSJEKTDELTAKERE Anders Nordli Knudsen DATO ANTALL SIDER / BILAG INTERN VEILEDER Eva Hadler Vihovde Maha Sami Laham OPPDRAGSGIVER Khedar Nassir Shyto Norsk Regnesentral Daniel Notstad SAMMENDRAG KONTAKTPERSON Trenton Schulz Hussain Salbi Prosjektgruppen har utviklet to applikasjoner for informasjonsformidling av Norsk Regnesentrals tjenester og prosjekter. En for ios enheter og en for Android mobiltelefoner. Norsk Regnesentral er en privat forskningsbedrift som driver forskning innen IKT og statiskmodellering. De utfører oppdragsforskning for næringsliv, offentligsektor og private organisasjoner både i Norge og internasjonalt. Prosjektgruppen har bestått av fem studenter i fra forskjellige studieretninger. Vi har delt inn gruppen 3 STIKKORD hvor hvert gruppemedlem har fått ansvarsområder. Ut i fra disse ansvarsområdene har gruppen organisert, handlet og produsert det vi i dag kan si er et godt utførtarbeid som gjenspeiler Tilgjengelighet seg i kvaliteten på de applikasjonene som er blitt produsert. Ettersom Norsk Regnesentral Norsk Regnesentral ikke har hatt noen form for applikasjon for informasjonsformidling tidligere, har gruppen vært nødt til å lage dette helt i fra bunnen av. Gruppen har vært nødt til å lære seg helt nye språk og verktøy i utviklingen av applikasjonene, noe som har vært en spennende, utfordrende Mobilapplikasjoner og lærerik prosess. Side 1 Vi har fått mye positive tilbakemeldinger i fra oppdragsgiver og vi vil benytte anledningen til å takke for et godt gjennomført samarbeid.

2 Side 2

3 Denne rapporten er delt inn i fire hoveddeler. Prosessdokumentasjon, kravspesifikasjon, produktdokumentasjon og testdokumentasjon. Det vil i tillegg til disse inneholde brukerdokumentasjon for Android og ios. Kravspesifikasjon, prosjektskisse, forprosjekt-rapporten, arbeidsplan, figur liste, ordliste, referanseliste og CD med program-koden er lagt til som vedlegg. Det er referert til hver rapport og vedlegg i innholdslisten ved tall i hvert dokument. Hver hoveddel har en innholdsfortegnelse, innledning og forord. Prosessdokumentasjonen vil ta for seg hvordan prosessen i fra å planlegge prosjektet og hvordan utviklingen av applikasjonene har foregått. Kravspesifikasjonen vil ta for seg generelle og spesifikke krav som oppdragsgiver har utarbeidet i sammen med prosjektgruppen. Kravspesifikasjonen finnes i to versjoner. Den første versjonen prosjektgruppen utarbeidet er lagt til som vedlegg. Produktdokumentasjonen vil i hovedsak beskrive applikasjonenes egenskaper og funksjoner. Testrapporten inneholder tester som har blitt gjort på applikasjonene for å forbedre disse. Testene og resultatene kan du se i Testrapporten. Brukerhåndbok er en veiledning for brukere av applikasjonene og beskriver hvordan man bruker applikasjonene på ios og Android mobiltelefoner. Vi har igjennom prosessen med å ferdigstille applikasjonene, blitt veiledet av prosjektveileder Eva Hadler Vihovde i fra Høgskolen i Oslo og Akershus og oppdragsgivers representant Trenton Schulz. Vi vil i den anledning benytte sjansen til å takke dem begge for god veiledning og ønsker alle som leser denne rapporten en god lesing. Side 3

4 1. Forord 2. Innholdsfortegnelse 3. Prosessdokumentasjon. 4. Kravspesifikasjon. 5. Produktdokumentasjon. 6. Testrapport. 7. Brukerdokumentasjon ios 7.2. Android 8. Vedlegg. 8.1.Opprinnelige Kravspesifikasjon Ordliste. 8.3 Prosjektskisse. 8.4 Arbeidsplan Figur liste Referanseliste. 8.7 Forprosjektet 8.8 CD med program-koden. Side 4

5 Side 5

6 1. Forord Dette dokumentet skal kunne leses som et selvstendig dokument. For den som har lest forprosjektet, kravspesifikasjonen eller kjenner godt til prosjektet, er det ikke nødvendig å lese kapittel 3 med underkapitler. Man kan da starte å lese i fra kapittel fem. Tekniske utrykk som brukes i beskrivelsene og forklaringene for applikasjonene er lagt til som vedlegg i ordlisten. Denne er anbefalt å ha bruke hvis det skulle være ord og utrykk som er uforståelig. Denne prosessdokumentasjonen vil i hovedsak ta for seg hvilke utfordringer det har vært ved å utvikle produktene vi har produsert. Det vil også ta for seg hvilke løsninger vi har kommet fram til for å løse utfordringene vi har stått ovenfor. Dokumentet vil også ta for seg hvordan planleggingen, hva som er blitt planlagt og hvilke dokumenter som har blitt brukt for at prosjektet skulle gjennomføres på en best mulig måte. Til slutt vil det bli presentert en konklusjon. Prosessdokumentasjonen kan være interessant for sensor, veileder, oppdragsgiver og andre som skulle være interessert i prosessen ved å utvikle disse produktene. Beskrivelser av produktenes funksjonalitet og hvordan disse ser ut, kan man lese om i produktdokumentasjonen. Vi vil også henvise til brukerdokumentasjon ettersom disse beskriver hvordan man bruker produktene. Side 6

7 2. Innholdsfortegnelse 1.Forord 2. Innholdsfortegnelse 3. Innledning Om Prosjektgruppen Om Oppdragsgiver Dagens situasjon Mål Overordnet beskrivelse av produktet Planlegging Start av prosjektet Oppdeling av arbeid Kravspesifikasjonen og forandringer Gjennomføring Organisering Ansvarsområder Organisering av arbeidet Styringsdokumenter Prosjektskisse Forprosjekt Arbeidsplan og Fremdriftsplan Risikoanalyse Utfordringer og løsninger ios Generelt Meny Språk Revisjon av Meny og Språk Utviklingen av delsystemene for ios Om NR og Kontakt NR Side 7

8 9.2 Nyheter Blogg og Feeds Mail Abonnering Kart Revisjon av funksjoner Sluttendringer for ios Tegnkoding Universell Utforming Utfordringer og løsninger for Android Generelt Meny Språk Utviklingen av delsystemene i Android Om NR og Kontakt NR Nyheter og Blogg Feeds Mail Abonnering Kart Sluttendringer Tegnkoding Universell Utforming Kravspesifikasjon Mulige Forbedringer Oppsummering/Konklusjon 36 Side 8

9 3. Innledning I dette kapittelet har det blitt skrevet om prosjektgruppen, hvem de er, hvor de kommer i fra og litt om bakgrunnen til hver enkelt. Det er også skrevet om hvem oppdragsgiver er, historie, hvor mange ansatte og hva deres arbeid går ut på. Senere i kapitelet vil det bli sagt litt om dagens situasjon hos oppdragsgiver, kort om rammebetingelser og hvorfor prosjektgruppen har fått dette oppdraget. Til slutt i dette kapittelet vil det bli en kort overordnet beskrivelse av systemet. 3.1 Om Prosjektgruppen Prosjektgruppen er satt sammen i fra høgskolen i Oslo og Akershus og består av 5 studenter. Vi er tre studenter i fra studiene dataingeniør, én student i fra anvendt it og én student i fra informasjonssystemer og it-ledelse. Alle studentene er i fra forskjellige nasjonaliteter: Norge, Spania, Etiopia, Syria og Iran. 3.2 Om Oppdragsgiver Oppdragsgiver er Norsk Regnesentral, et forskningsinstitutt som har 70 ansatte hvor 60 av disse er forskere. Norsk Regnesentral er en uavhengig, ideell og allmennyttig privat stiftelse som utfører oppdragsforskning for næringsliv, offentlig sektor og private organisasjoner både i Norge og internasjonalt. Forskningsområdene er IKT og statistisk modellering, og NR er ett av Europas største miljøer innen anvendt statistikk. Største anvendelser er petroleum, finans/forsikring, jordobservasjon, miljø, helse, forvaltning og bildeanalyse. Innen IKT arbeides det med informasjonssikkerhet, universell utforming og smarte informasjonssystemer. Prosjektgruppen jobber i samarbeid med Institutt for Anvendt forskning i Informasjonsteknologi. Siden NR ble stiftet i 1952 til 1970 har NR hatt en viktig rolle i å utføre matematiske beregninger for andre organisasjoner. NR har jobbet med statistikk, fjernmåling, datakommunikasjon, internett vitenskap, multimedia, GEO statistikk, petroleum, marine ressurser, strømpriser og finans. Selskapet ble først et selvstendig institutt i 1985 og i 1988 flyttet den til sin nåværende lokasjon. NR er blant annet kjent for oppfinnelsen av programmeringsspråket Simula. 3.3 Dagens situasjon Norsk Regnesentral har per dags dato tre typer informasjonskanaler. Igjennom e-post, SMS og en webside formidler de informasjon til sine ansatte og det offentlige. De ønsker å utvide dette slik at Norsk Regnesentral kan forenkle informasjonsformidling til sine ansatte, Side 9

10 privatpersoner og bedrifter som er interessert i å få informasjon om Norsk Regnesentral og deres tjenester. Dette igjennom å utvikle en applikasjon som støtter Android og ios som er de mest brukte mobiloperativsystemene på markedet. Dette har dannet grunnlaget for hovedprosjektet som Høgskolen i Oslo og Akershus har kunnet videreformidle til studenter og hvor vi har valgt dette som hovedprosjekt. 3.4 Mål Vi har etter oppdragsgivers ønske og etter beste evne utviklet et produkt som Norsk regnesentral kan anvende nå og videreutvikle på et senere tidspunkt. Målet vårt var å utvikle en applikasjon som var brukervennlig og oppfylte de krav som oppdragsgiver hadde gitt og som man kan lese mere om i kravspesifikasjonen. Vi føler vi har klart oppgaven og nådd de målene vi har satt i sammen med oppdragsgiver. 4. Overordnet beskrivelse av produktet Hensikten med systemet har vært å gi brukere av smarttelefoner informasjon, slik at de til enhver tid har mulighet til å være oppdatert med den nyeste informasjonen som er utgitt i fra Norsk Regnesentral. Dette skal komme i form av en applikasjon, et tilleggsprogram som håndterer informasjonen som norsk regnesentral vil formidle på en enkel og strukturert måte. Applikasjonene skal være to-språklig, norsk og engelsk. De skal inneholde funksjonene Om NR, Nyheter, Blogg, Feeds, Mail Abonnering, Kontakt NR og Kart og hvor disse skal vises som rader. Applikasjonene og funksjonene er beskrevet detaljert i kravspesifikasjonen. Under vil man se en grafiskfremstilling av applikasjonen og hvordan man navigerer seg fram i fra hovedmenyen og til de forskjellige emnene. Nyheter Feeds Om NR Meny Blogg Kontakt NR Mail Abonnering Kart Figur 1. Side 10

11 5. Planlegging I dette kapitelet er det skrevet om hvordan planlegningen av prosjektet har blitt satt opp, gjennomført og om planleggingen er blitt gjennomført etter planen. 5.1 Start av prosjektet Vi startet prosjektplanleggingen med en prosjektskisse og et forprosjekt. Videre fortsatte vi med å organisere og diskutere hvilke ansvarsområder hvert enkelt gruppemedlem skulle ha som hovedansvar. Det å bestemme hva for eksempel en prosjektleder skulle gjøre og hvordan han skulle gjøre ting, ble diskutert og avklart. Vi hadde en brainstorming rundt hvert ansvarsområde. Mer om organisering kan man lese om i kapittel seks. Etter at ansvarsområder var utdelt, begynte vi å lage en rekke styringsdokumenter. Framdriftsplan, arbeidsplan og risikoanalyse ble laget. Hvordan disse styringsdokumentene er satt opp og organisert, kan man lese om i kapittel 6 og i forprosjektet som man kan lese som vedlegg. Noe av styringsdokumentene er også lagt til som vedlegg. Vi hadde ukentlige møter i gruppen og sammen med oppdragsgiver. I disse møtene ble det diskutert hvordan vi ville angripe problemstillingen og å få avklart kravspesifikasjonen. Kravspesifikasjonen har vært et dynamisk dokument som har blitt forandret etterhvert som oppdragsgiver så resultatene og gruppen jobbet med produktet. Denne ble laget i begynnelsen av prosjektet, som et styringsdokument for hvordan produktene skulle se ut og fungere. Denne er lagt til som vedlegg og kan leses i sin helhet. 5.2 Oppdeling av arbeid Oppgaven dreide seg om å lage en applikasjon som fungerte i ios og Android. Gruppen valgte å dele seg i to ved utviklingen av de forskjellige plattformene. En av grunnene til dette var at vi bare hadde en MacIntosh maskin til disposisjon. For det andre ville læringsutbytte bli større ettersom vi hadde mange nok i gruppen til å gjøre det på denne måten. 5.3 Kravspesifikasjonen og forandringer Gruppen fant fort ut at det var flere løsninger for å løse de forskjellige kravene i oppgaven på. Vi jobbet etter kravspesifikasjonen og etter testing og samtaler med oppdragsgiver, ble løsningene som var valgt i fra begynnelsen forandret. Dette fordi funksjonalitet eller brukervennligheten ble optimalisert gjennom å forandre løsningene. Dette var til tider frustrerende ettersom når man da hadde jobbet med utgangspunkt i fra kravspesifikasjon, måtte vi jobbe med en ny løsning som vi i utgangspunktet trodde vi var Side 11

12 ferdige med. 5.4 Gjennomføring Dokumentene var til hjelp på den måten at vi hadde oversikt over arbeidsoppgaver som skulle gjøres. Planleggingen og styringsdokumentene skulle være til hjelp med å overholde tidsfrister som var satt av oss selv og HIOA. Vi mener at vi ikke klarte å overholde våre egne tidsfrister på grunn av at omfanget i oppgaven var større enn vi trodde. Derfor lå vi bak skjema mot slutten av prosjektperioden etter våre egne tidsfrister, selv om vi overholdt de tidsfrister vi fikk av oppdragsgiver og faglærer. Side 12

13 6. Organisering I dette kapittelet vil man kunne lese om de forskjellige ansvarsområdene som har blitt tildelt, samt hvordan man har organisert arbeidet og om dette var en fordel eller ulempe. Det er også vist hvordan vi har organisert arbeidet ved noen figurer. 6.1 Ansvarsområder Prosjektgruppen bestod av fem gruppemedlemmer hvor vi valgte de ansvarsområder som er vist under i figur 1. Navn Ansvars område Anders - - Prosjekt leder - - Backup ansvarlig - - ios og Android programmer Nassir - - Vara leder - - Android programmer Maha - - Møte roms ansvarlig - - Android programmer - - Fremdriftsplan og arbeidsplan ansvarlig Hussain - - Talsmann for gruppen - - ios programmerer - - Kontaktperson for gruppen - - Vara referent /loggfører Daniel - - Referent/loggfører - - ios og Android programmer - - Rapport ansvarlig Figur 2. Det at vi valgte å dele oss inn på denne måten var til stor hjelp ettersom man da hele tiden hadde oversikt over hvem som hadde ansvar for hva og hvem man skulle henvende seg til for samarbeid. Side 13

14 6.2 Organisering av arbeidet I tillegg til ukentlige gruppemøter, møttes gruppen på Skype. Vi var fem personer på gruppen hvorav tre gikk på studieretning innenfor dataingeniør, den fjerde innen informasjonsteknologi og den femte i anvendt data. Når vi sto så sterkt utviklingsmessig, bestemte vi å splitte oss innenfor hver av de to operativsystemene vi skulle lage. Et medlem av gruppen skulle være borte i utlandet en periode og ville ha kontakt med oss over internett. Vi delte oss således i to og to programmeringsmessig og hvor den femte, som var i utlandet, ville hjelpe til der det trengtes ressurser samtidig som at han tok for seg dokumentasjon. Vi brukte Skype, Google Docs og Dropbox for kommunikasjon, fildeling og sikkerhetskopieringer. Under ser man to figurer. Figur 2 viser hvordan arbeidet ble organisert i Google Docs. Figur 3 viser hvordan arbeidet ble organisert i Dropbox. Dette var en stor fordel og forenklet mye av arbeidsprosessen. Figur 3. Figur 4. Side 14

15 7. Styringsdokumenter Dette kapittelet inneholder beskrivelse av hvordan prosjektskissen, forprosjekt-rapporten, arbeidsplan og fremdriftsplan ble produsert. Det har også blitt skrevet om det har verdt en fordel eller en ulempe. Prosjektskissen, forprosjekt-rapporten og arbeidsplanen er lagt til som vedlegg. 7.1 Prosjektskisse Det første styringsdokumentet prosjektgruppen laget var prosjektskissen. Dette dokumentet inneholder i hovedsak beskrivelse av prosjektet, hva det kunne utvikles i, navn på prosjektdeltakere og oppdragsgiver. Dette dokumentet var egentlig ikke til så stor hjelp. Vi visste hva oppdraget gikk ut på. Vi leste det som hadde blitt lagt ut av oppdragsgiver, via HIOAs sine internettsider før vi valgte prosjektet. Vi føler prosjektskissen bare var en repetisjon av hva vi allerede visste i fra før. I etterkant har vi også sett av vi misforstod og at en del av anbefalingene ble satt som krav i dette dokumentet, i stedet for at dette var et interessefelt. Den fullstendige prosjektskissen kan sees som vedlegg. 7.2 Forprosjekt Det andre styringsdokumentet prosjektgruppen laget var en forprosjekt-rapport. Vi foretok en grundig analyse av hva som skulle gjøres og grovvurderte hvilke elementer oppgaven skulle inneholde. Dette hjalp oss ved at vi fikk organisert arbeid, avklart hvilke farer det fantes ved en risikoanalyse, finne ut av utviklingsmiljø, ansvarsområder for hvert enkelt gruppemedlem og generell organisering av arbeidet og gruppen. Forprosjekt-rapporten er lagt til som vedlegg. Side 15

16 7.3 Arbeidsplan og Fremdriftsplan Disse planene har hjulpet prosjektgruppen å vurdere ressursbehov, fremdrift, oversikt og til å ha kontroll over prosjektet. Dette hjalp oss ved at vi hadde god oversikt over når ting skulle være ferdig. Men som sagt tidligere klarte vi ikke å overholde fristene som ble satt. Fremdriftsplanen kan man se under i figur fire. Figur Risikoanalyse I forbindelse med alle typer prosjekter er det risikoer. Det handler om at man alltid har en viss mengde resurser å forholde seg til, enten det dreier seg om tid, penger eller andre faktorer som kan gjøre et prosjekt utfordrende. Derfor lagde vi en risikoanalyse. Meningen med dokumentet var å gjøre gruppemedlemmene oppmerksom på faktorer som kunne ødelegge for prosjektet. På denne måten kunne vi være forberedt på problemer og iverksette tiltak for å forhindre en kritisk tilstand. Noen av tiltakene var blant annet å delegere ansvarsområder til hvert gruppemedlem tidlig i prosjektet. Vi hadde faste møtetider, bestemte at Google Docs, Dropboks og Skype skulle være kanaler for kommunikasjon, deling av arbeid og sikkerhetskopiering. Vi skulle skrive timelister i Google Docs, slik at alle kunne se hvor mye hvert enkelt medlem hadde arbeidet. Dette for å forhindre skjev arbeidsfordeling. Dette var til hjelp ved at alle hadde noe å gjøre til en hver tid. Risikoanalysen kan man lese i sin helhet i forprosjektrapporten som vedlegg. Side 16

17 8. Utfordringer og løsninger ios I dette kapittelet er det først blitt skrevet litt generelt om hvilke utfordringer og løsninger som prosjektgruppen har hatt å forholde seg til ved utvikling av applikasjonen til ios. Så har det blitt skrevet om prosessen ved å utvikle Menyen, språket og revisjon av disse. I kapittel 9 vil det bli beskrevet nærmere om prosessen ved utvikling av delsystemene. 8.1 Generelt Å lage en applikasjon for smart-telefoner er noe ingen av oss hadde vært borti før. For ios var vi fastlåst til å utvikle i Mac og kun en av oss hadde en slik maskin tilgjengelig. Object C som er programmeringsspråket brukt i Xcode var også noe ingen av oss hadde spesiell kjennskap til. Før vi kunne starte med å programmere, måtte vi finne ut av hvilket utviklingsmiljø vi skulle benytte oss av. Apple har lagt til rette for at utvikling i ios systemer skal gjøres via deres eget utviklingsverktøy med programmeringsspråket Object C. Xcode er et veldig intuitivt verktøy for ios utvikling. Mye er lagt opp til at brukeren enkelt skal komme i gang og kunne lage enkle applikasjoner selv uten stor programmeringsbakgrunn. I tillegg er det en innebygget simulator som viser resultatet. De første timene gikk bort på å dra ulike objekter til skjermbilde, som hele tiden gir et bilde hvordan applikasjonen ser ut, og således teste denne på simulator. Vi hadde ingen lærebok tilgjengelig for ios. All informasjon og svar på spørsmål fant vi på internett, fra Apple sin utviklingsside eller brukereksempler. Dette var mye skumlesing til de delene vi ønsket å vite. Vi hadde ikke tid til å gjennomføre et helt opplæringskurs og utvikle applikasjonen, på den tiden vi hadde til rådighet. 8.2 Meny I mobilapplikasjoner er det ofte en egen meny du kommer til før du velger hva slags funksjon du ønsker å gjennomføre, som å lese nyheter eller vise informasjon. Som utgangspunkt ville vi ha selve menyen i orden med alle dens egenskaper, samt en tom side som vises når du trykte på de knappene du ønsket å bruke. Menyen skulle også kunne benyttes i norsk- og engelsk-språklig utgave. Det ble først lagd et skjermbilde med alle knappene vi trengte og tekst til disse knappene. Det første programmeringsmessige vi gjorde var å utvikle en knappetrykk funksjon som leste opp i systemlogg hva knappen het. Innforstått med at applikasjonen registrerte de forskjellige knappene, planla vi å lage de tomme sidene som skulle vises ved å trykke på knappene. Å lage de var ikke noe problem, men vi møtte vår første store utfordring i hvordan vi skulle få disse forskjellige sidene til å henge sammen. Man skulle enkelt kunne Side 17

18 delegere knappetrykk til å vise et nytt vindu ved å holde ctrl inne etter å ha trykket på knappen, og så dra pilen som kommer over til det ønskede vinduet. Men uten en rett navigasjonsstruktur i bakgrunnen fungerte ikke tastetrykket på en ønskelig måte og om det virket så var det ingen måte å komme seg tilbake til menyen igjen. Dette er noe av det mest essensielle i alle mobilapplikasjoner. Og vi sto fast. Metoden for å løse dette problemet fant vi ved å lage hele applikasjonen på nytt med et eget template-format. Dette var en tabellstruktur som vi også har brukt i den endelige versjonen. I bakgrunnen er det en navigasjonskontroll som følger med hvor i applikasjonsdelene du befinner deg, og har navigasjonstopper til alle underskjermer til hovedmenyen. Dette gjør det enkelt å kunne gå tilbake til menyen igjen. Det var en veldig banal prosess som krever rett struktur i ios og skjer automatisk for Android. Når vi først fant ut hvordan dette foregikk og hvilke objekter vi kunne bruke i skjermbilde for å få det til, kunne vi gå tilbake til det vi først gjorde og få dette til å fungere. Vi sto dermed med to variasjoner av applikasjonen. En med knapper og en med tabell. Til tabellen lagde vi egne tekstfelt som ga de ulike radene navn. Vi lot tabellversjonen ligge og jobbet videre med språk til knappeversjonen. 8.3 Språk Språk er bestemt ut i fra hvilke innstillinger mobilen opererer med. Hvis det er norsk tekstvalg skulle vår applikasjon også være tekstet på norsk. Standarden ble satt som engelsk. En strengliste bestående av identifikator og tekst på norsk og engelsk ble lagd. Vi satte rett tekst på knappene kodemessig bestemt av lokasjon (norsk eller engelsk mobilspråk) og hentet dette fra rett liste. Ved et ubemerket feilklikk ble programmet plutselig ikke kjørbart og vi måtte bygge det opp på nytt igjen. Dette var en feil vi fant løsningen på senere, vi hadde huket av tilhørigheten for en av skjermene som skulle vises, men på dette tidspunktet måtte vi bare stramme beltet og gjøre det hele på nytt igjen. Grunnstrukturen var til slutt i boks og vi var forberedt på møte med oppdragsgiver. 8.4 Revisjon av Meny og Språk På møte med oppdragiver diskuterte vi hvordan applikasjonen skulle fungere. Vi viste både knappeversjonen og tabellversjonen og preferansen falt på tabell. Etter møte var jobben å få over alle språkfunksjonene på tabellversjonen og bruke denne vider Side 18

19 9. Utviklingen av delsystemene for ios I dette kapittelet er det blitt skrevet om prosessen ved å utvikle delsystemene til ios. Disse er delt inn i underkapitler. Noen beskrivelser av delsystemene er blitt slått sammen på grunn av at de enten hadde et lignende problem eller løsning. Til slutt vil underkapittel 9.6 ta for seg revisjon av delsystemene. 9.1 Om NR og Kontakt NR Vi valgte å fokusere på de enkleste funksjonene som applikasjonen skulle inneholde, de som bare var ren tekstinformasjon. Vi skrev teksten som skulle være i Om NR og Kontakt NR på norsk og engelsk, og lot en innebygget funksjon delegere rett streng på norsk eller engelsk til feltet teksten skulle bruke. Dette feltet hadde vi først satt som en etikett og ikke tekstboks. Dette skulle vise seg å bli tungvint. Når vi satte inn teksten i etikettet fant vi ut at teksten var for stor til å kunne vises i feltet, selv om vi satte antall linjer til å være over hundre som er mye mer enn nødvendig. På slutten av etikettet symboliserte... at det var mer tekst som ikke hadde blitt vist, så vi undret oss over hvordan vi kunne få fram dette. Et rullefelt på siden var en mulig løsning, så vi begynte å søke igjennom artikler og prøve oss fram via programmering til å få festet et vertikalt rullefelt til å vise resten av etikett innholdet. Noe som var alt annet enn enkelt. Etter et par dagers strev med dette byttet vi ut ved en impuls etikettet med en tekstboks. Ikke bare ble alle linjene vist uten at vi måtte gjette oss fram til hvor mange vi ønsket å ha, men det var et innebygd rullefelt også! 9.2 Nyheter Da vi var fornøyd med alle de enkle funksjonene, begynte vi med alle som viste en webside. Å sette opp en kobling til en nettside var enkelt nok, men oppdragsgiver mente at websiden var for stor til å skulle vises i iphone. Det ville være knotete å lese nyhetene der. For å løse dette skulle vi bare ta det innholdet som hadde med nyheter å gjøre, og vise dette som en egen side. Vi lagret først en streng med all kildekoden til Norsk Regnesentrals nyhetsside, som vi hentet ved oppkobling fra telefonen, og så begynte å stykke opp og lage en ny html kode ut ifra denne strengen. Det at vi visste når nyhetsoverskriftene begynte ut ifra template-kildekoden til nyhetssiden, gjorde at vi bare trengte å ta alle overskriftene derifra som skille mellom html-bitene. Vi splittet opp kildekoden i en streng array og tok alle delene fra nyhetsartiklene begynte som en egen streng. Denne brukte vi som koden til siden vi skulle vise. Resultatet var en restrukturert nyhetsside med bare de nyhetene som skulle vises. Å trykke på noen av lenkene på denne siden ville gå til en hel side igjen, men selve nyhetssiden var sånn som ønsket. Side 19

20 9.3 Blogg og Feeds Vi gjorde noe lignende for bloggsiden og feeds som med nyhetssiden og viste disse som separate html-sider. Meningen var bare å ta det innholdet vi ønsket brukeren av telefonen skulle se og kutte bort alt det overflødige rundt. Dette var før vi begynte å gjøre om feeds til RSS og ikke som html. 9.4 Mail Abonnering Et nytt problem vi støtte borti var når vi skulle ta Mail Abonnering. En tidligere prosjektgruppe hadde lagd en side for registrering som Norsk Regnesentral bruker i dag, så vi trodde det skulle være en enkel sak og bare vise denne som en html side uten noe ekstra kluss med kildekoden. Siden vistes helt praktfullt men vår irritasjon var at det tok ett minutt og seksten sekunder før den kom fram første gang den skulle vises. Vi kunne ikke fatte hvorfor det skulle ta så lang tid for noe så enkelt. Dette er ikke noe vi har funnet ut til dags dato heller. Kanskje det er noe i viderekoblingen iphone ikke liker, eller buffere i simulatoren ikke er stor nok til å takle lastingen av den siden etter å ha vist andre sider. Vi har hatt tilfeller hvor siden vistes umiddelbart men har ikke kunnet fastslå om det er grunnet bedre internett forbindelse. Den versjonen ble ikke testet på en ordentlig iphone. Løsningen ble at vi lagde de nødvendige feltene på en innebygd html-side i telefonen, og sendte informasjonen til samme sted som siden vi ønsket å linke til. En side som åpnet et minutt og femten sekunder raskere enn det vi prøvde først. 9.5 Kart Kart var en funksjon som ikke ga mye trøbbel å få gjennomført. Til dette trengte applikasjonen en egen kartpakke som måtte legges til prosjektet for å kunne bruke Google sine karttjenester. En innebygd kart viser ga oss et fint grått og blått verdenskart med muligheter for å kunne zoome in og ut. Det var også en egen huk-av boks for å vise din egen posisjon som vi benyttet. Arbeidet ble således å markere hvor på kartet Norsk Regnesentral lå og prøve å få zoomet inn på Oslo-området. Selv etter å ha huket av for å vise din egen posisjon kom ikke dette fram på kartet. Vi lagde da en egen markør for din posisjon også. Vi fikk testet oss fram til å få alt dette til å fungere, men av en eller annen grunn så fant ikke vi vår egen posisjon selv dobbelt markert. Vi zoomet ut kartet. En markør var plantet litt utenfor kysten til Afrika. Dette var ikke en feil i seg selv ettersom simulatoren ikke klarer å vise din posisjon. I så fall blir det utenfor Afrika eller på Apple sitt kontor i Cupertino. Når vi testet det på iphone markerte kartet din posisjon klart og tydelig. Side 20

21 9.6 Revisjon av funksjoner Vi hadde regelmessig kontakt med oppdragsgiver og vi hadde møter både på Norsk Regnesentral og Høgskolen hvor vi viste hva vi hadde fått til, og fikk innspill på hva vi måtte forbedre. I en tid var det ønsket å ha nyheter som tabellstruktur lignende det vi gjorde med feeds, men det var såpass lite informasjon og ble seende greit ut at dette ikke stiltes som nødvendig endring. For Om NR trengte vi bare fjerne en duplikat overskrift. Senere forstørret vi også teksten på innholdet. I Kontakt NR var det ønskelig å ha forbedret utseendet. Innholdet var i en tekstboks og hentet fra strenglisten vår, så det var lite vi kunne gjøre for å forbedre det på den måten. Vi valgte isteden å sende inn innholdet som en webside og bruke html-tagger for å fikse teksten til å bli bedre visuelt. Noe tungvint for Object C og Xcodes håndtering av strenger er måten du strukturer dem på. For eksempel i Java kan en enkel tekst: Jeg skriver en prosessdokumentasjon. Det er veldig viktig. Lages som en string sånn her: String stekst = Jeg skriver en prosessdokumentasjon. + \n + Det er veldig viktig. ; Denne måten å lage en streng viser hvordan utseendet vil bli også. I Xcode derimot må strengen gjøres: NSString stekst = Jeg skriver en prosessdokumentasjon.\ndet er veldig viktig. ; Våre strenger for Kontakt NR, med html-tagger, var mye lengre enn disse to setningene og alt måtte legges inne i en lang klump med tekst. Det positive med å ha dette som en webside var at vi kunne huke av for at den innebygde leseren gjenkjenner telefonnumre og lenker. Disse ekstra godbitene har vi flittig brukt. Feeds og Blogg hadde hittil kun blitt vist som en webside hvor vi redigerte html-koden bak. Det var ønskelig og heller kunne bruke RSS som Feeds egentlig bruker. Vi måtte finne ut en måte å gjøre dette på, for det er ingen innebygd RSS leser som vi kunne benytte oss av enkelt. Valget ble da å lage en egen RSS-leser manuelt til applikasjonen vår. Før vi kunne kaste oss over dette nye problemet, bestemte Xcode seg for at nå var en passelig stund å slutte å virke. Side 21

22 Etter å ha reinstallert og rotet oss fram til å få Xcode til å fungere igjen begynte vi med prosessen for å få feeds inn på simulatoren og bygge opp en egen leser for det. RSS er et webformat som brukes til å gi ut nyheter eller informasjon raskt. Ved å åpne Norsk Regnesentrals RSS fil kan vi få ut all informasjonen presentert som en lang tekstfil. Ved hjelp av denne kunne vi bruke samme metode som for nyheter og fordele tekstblokker til array. Atom, som Norsk Regnesentral bruker, er en type RSS som vi fant hadde følgene struktur for feed: <item> <title> </title> <link> </link> <description> </description>... </item> Vi satte alle item-innholdene i en egen denne array og hentet ut fra titler, linker og beskrivelser som vi satte i egne arrayer. Dette er grunnlaget for feeds funksjonens visning og det ble mange IndexOutOfBounds feilmeldinger før vi klarte å få dette ryddig og feilfritt på plass. Tabellstrukturen for å vise alle disse feedene måtte vi bygge opp fra grunnen av programmessig. Vi lagde en egen klasse for denne strukturen med en tom tabell i bunnen på skjermbildet. Etter å ha lagd alle arrayene for feeds, tok vi nummeret av titler og brukte det til å bestemme hvor mange rader tabellen trengte. Teksten til disse radene ble det samme som titlene. Det ble laget en ny klasse for å vise feeds som vi sendte med tittelen, beskrivelsen og linken som lå i den feedsen som blir trykket på, for å vise dette. Nå var også første gang vi ble virkelig bevisst på at vi kjørte alle delfunksjonene i en klasse samtidig, og ikke unike for hver funksjon av menyen. For lette operasjoner som å vise tekst er dette ikke noe problem, men det kan være verre med de tyngre brukt i nyheter og feeds. Et annet problem med dette ligger i at når det er feil for oppvisningen av en funksjon, vil de andre også få feil. Ved testing på iphone har ikke dette slått ut i en merkbar negativ måte. Samme metode ble brukt for blogg, lagde to klasser og arrayer for RSS en som lå bak siden. Side 22

23 10. Sluttendringer for ios I sluttfasen av applikasjonsutviklingen har vi hatt et par endringer for applikasjonen. Størst av alle var å sette Blogg tilbake som en webside og ikke som RSS. Vi fant ut at innholdet i feeds vi hentet hadde ikke alle blogginnleggene fra siden til Norsk Regnesentral og inneholdt html kode som ga et dårlig utseende. Et bilde av dette har blitt lagt til under men dette er fra før vi fikset tegnkode problemet. Her ser man hva æ, ø og å blir fra latin1 lest som UTF-8. Figur 6. Opprinnelig var det ønsket, men ikke krevd, å ha en GoBack funksjon for websidene med nettinnhold. Da vi lagde denne fant vi ut at den ikke lagret html-filen som vi redigerte lokalt i historikken. Sannsynligvis fordi vi brukte kildekoden som en egen streng og ikke viste selve nettsiden. Ettersom GoBack bare ville funke for de neste sidene som kom, implementerte vi ikke disse. Side 23

24 Mail Abonnering hadde blitt løst med en lokal side. Vi måtte finne ut en måte å få oversatt denne mellom norsk og engelsk. En løsning ville vært å lage to forskjellige html sider, lagre disse lokalt og kalle på den rette ved å lese språket på mobilen. Isteden valgte vi for ios, siden vi hadde hatt suksess med enkle strengendringer før, å lage stikkordsformer på teksten og bruke string replace med rett lokasjonsstreng. En siste forbedring på Kontakt NR kom ved å lage definisjonsliste for personal informasjonspunktene etter ønske fra oppdragsgiver om dette. Vi gjorde også om headerne til h1 isteden for h2 i html koden. Blogg fikk en endring tilsvarende nyheter etter å ha blitt satt tilbake som en webside. Vi tok alle innleggene uten strukturen bak og viste kun dette på siden som vi hadde prøvd før. Blogginnlegg blir vist som noder og ulikt html headerne for Nyheter, er det ikke sannsynlig at denne koden kommer til å bli endret. Så vi hentet ut alle nodene og viste disse på siden. I tillegg måtte vi legge ved linker til CSS-filene brukt på siden, for at innleggene skulle vises på en god måte. Vi fullførte de siste endringene ved å gi tilbakemeldinger for Nyheter, Blogg og Feeds når det ikke er internettforbindelse. Linkene som vistes i Feed ble også fjernet, ettersom all informasjonen allerede ble vist. For Kart vil et cache bilde av kartet fremdeles vises men ikke kunne endres på, eller et grått kart sees med pinnen for Norsk Regnesentrals posisjon. Mail Abonnering bruker skript som kjører på en ekstern side for å koble mailadresse til nyhetsbrev. Siden vi ikke har tilgang til dette skriptet og vi ikke har store kunnskaper om JavaScript og J Query som er brukt, har vi valgt å legge til informasjonstekst på siden som forklarer hva som skjer når det går greit. Dette er ikke ideelt og en forbedring ville vært å gi beskjed om det ikke er internett forbindelse. Det har vist seg at når vi har testet dette på smarttelefoner har tilkoblingen til den eksterne siden vist feilmeldinger der når noe gikk galt Tegnkoding Norsk Regnesentral bruker latin1 som tegnkode for sine websider. En vanlig streng benytter seg av UTF-8. Forskjellene mellom dem er små men slår ut når det kommer til spesielle tegn. Slik som æ, ø og å. Dette var et problem som viste seg for alle sidene vi hentet informasjon direkte fra nettet og restrukturerte det lokalt. I Xcode kunne vi spesifisere tegnkoden når vi lagde strengene og således enkelt beholde latin1 kodingen for applikasjonen. Side 24

25 10.2 Universell Utforming Hovedfokuset og intensjonen bak har alltid vært å ha en universell utformet applikasjon. Det skal være mulig for alle å kunne bruke applikasjonen uten eksklusjon for brukere med funksjonshemninger. Selv om det er innebygd mye for iphone for å støtte dette er det noe vi har måtte være bevisst på og sette opp selv. For hver tabell rad har vi måttet få ios til å tolke det som en knapp og ikke lese teksten vi har plassert over (som da ville bli lest opp som en tekst, og ikke som en knapp å trykke på for de som har dårlig syn). Navnet som leses opp har vi også måtte bruke engelsk og norsk oversettelse. Det er bevisst brukt hvit og svart for applikasjonens bakgrunn og tekst. Vi har også endret navigasjonstoppen til å ha en blåfarge som Norsk Regnesentral bruker for deres logo. Oppdragsgiver har flittig vært med på å gi tilbakemeldinger om hvordan prestasjonen på dette punktet er for applikasjonen og kjørte en test på dette på Norsk Regnesentral. Side 25

26 11. Utfordringer og løsninger for Android I dette kapittelet er det først blitt skrevet generelt om hvilke utfordringer og løsninger som prosjektgruppen har hatt ved utviklingen av applikasjonen til Android. Videre er det skrevet om prosessen det har vært forbundet med å utvikle Meny og språket Generelt Vi brukte Androids SDK (Software Development Kit) og Eclipse (eget utviklingsverktøy for Java, men kan ta andre språk som egne moduler) som utviklingsverktøy. Grunnen til dette var at gruppemedlemmene var kjent med dette utviklingsverktøyet fra før. Sammenkoblingen og få alt dette til å gå på flere maskiner skulle vise seg å ikke være så lett. I noen tilfeller var Eclipse versjonen for gammel og måtte oppgraderes, i andre fungerte ikke Android SDK eller nektet å la seg installere (i et tilfelle fant vi ikke SDK filene i det hele tatt). Når vi først hadde fått ned disse filene og installert det, skulle det tukles litt før vi fikk en Hello World! applikasjon til å fungere. Av en eller annen grunn fungerte ikke samme oppsetts måte på alle maskiner. Til det mest kranglevorne problemet valgte vi å bare pakke sammen en fungerende Eclipse og kopiere den over til den andre maskinen for å få alt i orden. Krevde timers strev bare å komme i gang, men vi fikk det til å virke Meny Det finnes en mal i emulator for listview hvor man kan dra inn forskjellige knapper i et annet vindu slik at man får en grafisk framstilling av hvordan tingene vil se ut. Kodingen vil da foregå automatisk. Valget falt på denne malen. Hver knapp ble linket til egen XML-fil og java-klasse. Vi har sett på eksempel i læreboken Professional Android 2 Application Development som viser hvordan et knappeobjekt (som er en del av XML fil) og java-klasse virker sammen. Først virket ikke knappene selv om alt var rett fordi vi måtte definere hver XML fil i AndroidManifest.xml. Filen som inneholder tillatelser og aktiviteter applikasjonen har. Xml - filene defineres som activity i AndroidManifest.xml, f.eks: <activity android:name=".about" android:theme="@android:style/theme.notitlebar" /> Informasjon om aktiviteter fant vi etter søking om problemet på nettet. Vi brukte en OnClickListener for å teste at disse virket. Side 26

27 På et senere tidspunkt var vi nødt til å forandre struktur og navnsetting på menyknappene. Vi gjorde tilsvarende endringer i layout-filene* som resulterte i at hele programmet stoppet opp fordi den ikke lenger fant de filene som det skulle refereres til. Siden omfanget av endringene var store, var det bedre å bare lage hele menyen på nytt og gjenbruke koden i de nye filene. *Android bruker egne XML-filer for utseende til skjermbilder Språk I Android måtte vi først lage en mappe som heter values-nb for norsk. I denne mappen måtte vi ha en XML-fil som heter strings. I denne filen inneholder det kildekoder hvor disse er strenger. For hvert ord vi brukte, var vi nødt til å definere det på nytt. På engelsk laget vi ikke en ny mappe ettersom dette allerede ligger i applikasjonen. Dette er gjort på samme måte i ios. Vi fant informasjon om språket etter søking på flere internettsider. Og kombinerte dette for å løse språksetting. Android applikasjoner forandrer språk på forhåndsbestemte strenger ved å se i string.xml filen i values mappen. Det som blir skrevet der vil være standardspråket som benyttes. Vi kan legge til oversettelser ved å opprette nye values mapper ved å ta bokstav identifikatoren til språket vi ønsker å benytte og sette dette som et tillegg til mappenavnet. For norsk bokmål vil vi ha nb som identifikator og mappenavnet values-nb. String.xml som vi plasserer der vil være de tekststrengene som vises når Android kjører med norsk bokmål. En annen utfordring ble å kunne kalle på disse strengene vi hadde lagd. Dette ble løst i layout-filene ved å som verdi for tekstfeltet til Om NR og ved å kalle på strengen i egne Android funksjoner i koden. Eksempel på dette kan du se under: <TextView android:text="@string/abbout"/> Side 27

28 12. Utviklingen av delsystemene i Android I dette kapittelet er det blitt skrevet om utfordringen og løsningene for hvert delsystem til Android applikasjonen. Delsystemene er delt inn i egne underkapitler. Som i kapittel 9 har noen delsystemer blitt slått sammen på grunn av at de enten hadde et lignende problem eller løsning Om NR og Kontakt NR Om NR og Kontakt NR har blitt løst på samme måte som i ios hvor man lagrer en streng med informasjon fra NR i applikasjonen. I siste versjon av Om NR brukte vi Medium TextView isteden for TextView som viser større tekst enn vanlig. Medium TextView finnes som en mal i selve Android programmet. Teksten ble definert som ett ord i XML filen f.eks: android:text="@string/abbout" og vi definerte abbout i strings filene som finnes under values og values-nb folder. f.eks. under values -> strings.xml: <string name="abbout"> Norwegian Computing Center, NR, is... </string> og under values-nb -> strings.xml: <string name="abbout">norsk Regnesentral er en uavhengig, ideell... </string> Informasjon om dette fant vi i læreboka Professional Android 2 Application Development. Teksten for Kontakt NR brukte vi først vanlig TextView som er lettere og fortere for selve programmet enn å bruke en html fil. Dette endret vi senere til html og en WebView for å vise definisjonsliste Nyheter og Blogg I denne delen skulle det utelates elementer i fra Norsk Regnesentrals sin nettside og bare utvalgte artikler, tekster og linker skulle være på applikasjonen. Dette fordi at NRs nettside skulle tilpasses applikasjonen på en best mulig måte. Vi startet med å bruke en vanlig "Webview" med tilhørende "templates", hvor man lastet NRs nyhetside inn i applikasjonen. Men dette viste seg å bli et dårlig resultat utseendemessig. Header ble så stort at man måtte navigere seg en hel skjermside til høyre for å se header og overskrifter. Vi forstod først ikke hvordan vi skulle løse dette og etter mye prøving, feiling og samtaler med oppdragsgiver, fant vi ut av at å bruke en streng metode Side 28

29 kunne vi redigere html koden og dermed ta bort header og alle overskrifter, og dermed få et godt resultat. Først laget vi Nyheter som en simpel "WebView", definerte denne i XML-filen og linket den til Java klasse hvor vi brukte metoden: webview.loadurl(" Informasjon om å lage WebView fant vi i læreboken, Professional Android 2 Application Development. Feilen vi fikk var at siden ikke ble lastet ned selv om det var internett forbindelse. Problemet var at vi måtte gi tillatelse for å bruke internett. Tillatelsen blir definert i AndroidManifest.xml på denne måten: <uses-permission android:name="android.permission.internet" /> Etter å ha fått vist nyhetssiden, startet arbeidet med å få redigert denne til å vise bare det ønskete innholdet. Tankegangen var den samme som for ios, vi skulle ha kildekoden som en egen streng og splitte denne. Men hver gang vi skulle hente dette fra nettet og prøve å få vist kildekoden som en webside, kræsjet Android simulatoren. Vi prøvde ulike variasjoner av samme ide: hente ned bytes i en buffered reader, hente ned strenglinjer og bygge opp med en "stringbuilder" eller hente ned enkelttegn. Simulatoren fortsatte å stoppe uten noen tilbakemelding. I respons valgte vi å laste ned websiden som en lokal fil og legge denne inn i applikasjonen. Vi leste så denne som en webside. Ettersom nyhetsbildene er lest lokalt på Norsk Regnesentrals server, måtte vi redigere html-koden til å hente bildene derifra. Siden vistes nå på skjermen og vi kunne begynne å teste hvordan redigeringskoden fungerte på Android. Det ble brukt samme kode som vi hadde lagd for ios men oversatt til Java. Oppstarten for siden var et par sekunder senere men kodesnutten virket. To problemer gjensto for nyhetssiden. Først var det tegnkodingen som viste rare symboler der vi på norsk har æ, ø og å. Løsningen på denne kan du lese i det egne kapittelet lenger ned. Den andre og viktigste derimot var hvordan vi kunne få synkronisert den lokale filen til å være det samme som den vist på Norsk Regnesentral. Igjen gikk vi tilbake til å laste ned informasjonen fra nettet og samme feilen viste seg der ennå. I et forsøk på å finne ut hva som gikk galt, benyttet vi oss av en "try-catch" metode. Det rare var at de forventede feilmeldingene som det å ikke ha forbindelse, ikke finne innhold og lignende ikke slo ut. Koden ble endret til å fange opp alle feilmeldinger og gi oss beskjed om hva som slo ut. Dette ble vårt første møte med NetworkOnMainThreadException for utvikling av Android applikasjoner. Side 29

30 I senere Android SDKer har NetworkOnMainThreadException blitt lagt til for å forhindre at oppbyggingen til vinduer ikke tar for lang tid og slår ut hver gang du foretar deg en komplisert nettverksmetode i oppstartsprosessen. Når forsøkene vi gjorde for å komme unna denne feilmeldingen ved å starte nedlastningen av html-siden i en egen prosesstråd ikke fungerte, slo vi av denne innstillingen for nyhetssiden og fant ut hvorfor denne reagerte. Siden vi ønsket å vise redigert kom opp etter to og et halvt minutt. Vi gjorde denne prosessen raskere ved å lese linjer av tekst i stedet for enkelttegn fra nettsiden, og lagret alt dette i en streng. Dette senket oppstartsprosessen ned til fjorten sekunder. Ved bruk av "logcat", Androids egen meldingsvindu i Eclipse, tok vi notasjoner over hvor lang tid hver handling på nyhetssiden ble gjort. To sekunder var hele prosessen for å få siden ned som en streng, resten av tiden ble brukt for å redigere denne. Tiden ble forkortet igjen ved hjelp av stringbuilder og nyhetssiden vistes da etter mellom fire og seks sekunder. Dette var vi fornøyd med. I likhet med nyheter, ble blogg hentet i fra nettsiden til NR. Men til forskjell i fra nyheter trengte vi ikke bruke noen string-metode for å dele opp html-koden. Innholdet i bloggen ble tilpasset applikasjonen slik at alt ble vist vertikalt og dermed ble det et godt resultat. Grunnen til at vi fikk forskjellige resultat mellom Blogg og Nyheter i begynnelsen, var at Blogg åpnet i nettleser applikasjonen. Noe som oppdragsgiver sa at måtte endres slik at brukeren ikke skulle hoppe mellom to applikasjoner. Vi fikk samme utfordring som Nyheter i begynnelsen ved at siden ikke var tilpasset mobilskjermen. Vi søkte etter problemet på nettet og fant ut at vi måtte endre på innstillinger til måten URLen skal lastes ned på Feeds Siden vi allerede hadde løst NetworkOnMainThreadException utfordringen for Nyheter, ble det enkelt å laste ned Feeds strenger og opprette arrayer(lister) med disse på samme måte som for ios. Utfordringen ble å få opprettet en tabell med alle feedene og sende videre informasjonen som skulle vises. Vi lagde en tableview som bak struktur i layoutfilen. I denne tomme tabellen satte vi programmessig rader med egne tekstfelter, hvor teksten var feeds tittelen. En OnClickListener skulle gå til en ny side med hele feedinnholdet. Å finne ut hva slags indeks på valgt feed var greit nok, så kunne vi bare ta beskrivelsen og linken i tillegg, men å sende det over til en ny klasse var litt mer vrient. Først prøvde vi å sende teksten som parametere til den nye klassen uten å finne en fornuftig løsning på dette. Således begynte vi å se nærmere på hvordan klasser i Android blir opprettet. Vi fant ut at en bundle (pakke) alltid blir sendt med i opprettelsen av det nye Side 30

31 skjermbilde og at vi kunne legge til innhold til denne pakken. Vi plasserte strengene som skulle vises og fikk opprettet en ny webside med feed-innholdet. Suksess. Vi hadde nå en tabell vi ikke kunne rulle nedover på, med masse tette felt som ikke var lette å skille mellom radmessig. Det tok også litt tid før feed-innholdet vistes så man ble usikker på om man faktisk hadde trykket på noe rett. Overgangen derimot stemte overens med knappetrykket så dette fungerte greit. Problemet vårt lå visuelt. Vi måtte få dette til å se bedre ut. Ideen vi begynte med var å lage forskjellige bakgrunnsfarger på feed-radene i tabellen for å skille ut hva som tilhørte hvilken rad. Mens vi holdt på med fargevalg kom ideen om padding for radene og bruke disse for å skape mer mellomrom for teksten. Selv om fargene ikke ble vist, ga padding i seg selv nok til å skape et skille der det hadde vært tett tekst tidligere. I seg selv virket dette greit, men vi hadde ikke noe visuelt som sa hva brukeren hadde trykket på. På en impuls skiftet vi OnClickListener fra å sjekke om raden ble klikket på, til selve feed tittelteksten. En innebygd funksjon i Android fikk denne trykkede teksten til å bli grå og nedpresset, som tilfredsstilte hva vi ønsket å oppnå. For å lage et vertikalt rullefelt satte vi hele tabellen i et ScrollView layout. Feeds var i boks Mail Abonnering Vi brukte en forkortet versjon av html-koden til nyhetsbrev andre studenter hadde lagd for NR tidligere og brukte denne som en lokal fil på applikasjonen. Teksten her var blandet norsk og engelsk, så vår oppgave ble å få oversatt denne på rett måte. Vi løste dette ved å lage to ulike versjoner lokalt på applikasjonen og skrev selv teksten som skulle være der. Mobilspråket brukte vi som skille mellom hvilken av disse to filene som skulle åpnes. Strukturen på denne siden endret vi også til å bli likt som i ios Kart Det skulle vise seg å være kronglete å få kart til å fungere for Android, ironisk nok ettersom dette er Google sin egen mobilplattform. Grunnen til dette er at prosessen ved å installere alle støttepakkene, hele 7 stykker, tok mye resurser. For å få vist kartet trengs det en signeringsnøkkel for at emulatoren skal kunne vise dette. Denne nøkkelen måtte vi lese fram via Java sitt keytoolprogram og få debugsigneringsnøkkel fra Google. Man måtte registrere nøkkelens MD5 kode for videre å referere til dette i XMLfilen, direkte i koden. Kartet kunne da vises i emulator. Side 31

32 Når applikasjonen var ferdig kunne denne signeres ordentlig og vises etter installasjon, men da vi holdt på kunne vi bare teste kart på de maskinene vi hadde signert de unike debugnøklene på. Det var også kronglete å legge markører til på kartet. Dette på grunn av kodingen. Man måtte først laste ned markører fra internett. Deretter måtte man sette posisjonens latitude og longitude i koden. Når vi hadde fått vist kartet på applikasjonen snakket vi med oppdragsgiver om hvilke ønsker det var for denne funksjonen. Vi måtte finne en måte for brukeren til å vite hvor han selv var og hvor Norsk Regnesentral befant seg. Gruppen bestemte seg for å vise dette ved hjelp av kartmarkører, både for NRs posisjon og brukeren. For å få til dette måtte vi lage et eget overlay med markøren og posisjonen til Norsk Regnesentrals kontor, og legge dette kodemessig oppå kartet vi brukte. Vår egen posisjon var enklere å få til. Android har selv et eget overlay som man kan aktivere sin egen posisjon på. Vi kan ikke se vår egen posisjon på emulatoren ettersom dette krever egne innstillinger og forbindelse som vi har på mobilen. 13. Sluttendringer Vi hadde først brukt knapper som fikk brukeren tilbake til menyen. Ettersom Android selv har en egen funksjon for dette, fjernet vi senere disse overflødige knappene. Det var først en egen etikett som het NR Hjem øverst på Meny. Denne har vi siden fjernet ettersom applikasjonen har en tittelmeny. Etter egen testing forstørret vi titteltekstene for radene på Feeds så de var lettere synlig. Mye av etterarbeidet var å få de to applikasjonene like og det er derfor det ikke står mer om sluttendringene for Android Tegnkoding Til forskjell fra ios skulle tegnkoding for Android vise seg å være litt mer tungvint. Vi møtte samme problem på Nyheter og Feeds etter vi hadde lagd koden som en streng. Derimot var det ikke like simpelt å få den innebygde webleseren vår til å vise dette i ISO (latin1) selv om vi sendte dette med som argument. Problemløsningsprosessen begynte da med å finne ut hvor i kodingen strengene våre skiftet tegnkode, altså hvor alt falt sammen. Vanlige strenger er kodet i UTF-8 og dette måtte vi hele tiden være bevisst på mens vi testet. For å finne ut hvor teksten slo seg vrang brukte vi Androids logcat til å sende ut den informasjonen vi hadde på ulike tidspunkt. Den første feilen fant vi i BufferedReader som leste ned linje for linje kildekoden fra nettet. Vi skiftet den til å lese latin1 og sjekket Side 32

33 innlesningen på nytt i logcat. Innforstått med at dette virket tok vi en utskrift av strengen som vi hadde bygd i StringBuffer, før vi hadde begynt å endre på koden, og en utskrift etter. Samme rette skrift. Men hver gang vi skulle lese denne i WebView * var tegnkoden feil. Vi prøvde å endre tegnkode argumentet for WebView til forskjellige former samtidig som vi endret innlesnings-tegnkodingen for BufferedReader i et desperat forsøk for å se om logcat var feil eller vi hadde oversett noe. Samme gale resultat, men endringen av BufferedReader ga oss enda rarere feiltegn. Et videre forsøk her ville vært å skrive ut strengen til en fil og lese denne på maskinen utenfor WebView. Dette er hva vi ville gjort hadde vi ikke funnet løsningen. Sannsynligvis hadde vi sett den rette strengen der også. Problemet oppdaget vi var i hvordan WebView viste siden vi prøvde å sende den. Parameterne vi sendte var selve strengen, at det skulle være text/html som format og ISO tegnkoding. Formatet måtte vi endre til å gi tegnkoden der, og bruke base64 som siste parameter ettersom det er det WebView egentlig bruker. Selve strengen vi sendte måtte vi oversette til base64 og dette hadde Android en egen funksjon til å gjøre ved å lese inn bytes fra et gitt tegnsett. Her kunne vi skrive in ISO for å få dette til å virke. Vi brukte samme overgang for å få Feeds til å vise rett tegnkode. *WebView er et Android object som viser html-sider på applikasjonen, uten å sende dette videre til en annen nettleser. Kan fungere som en nettleser i seg selv Universell Utforming Forbedringer for universell utforming i Android er en prosess som blir bedre med tiden, men som nå ikke har kommet like langt som for ios. Siden prosjektets start har vi fått vite at det er ikke mye som man får gjort og at det store her er TalkBack applikasjonen du kan installere. Selv denne er ikke like brukbar for alle versjoner av Android. Programmeringsmessig og utseendemessig har vi ikke kunne gjort like mye her som for ios, men vi har prøvd å få de visuelle forbedringene på plass. Side 33

34 14. Kravspesifikasjon Kravspesifikasjonen har vært et dokument som vi har utarbeidet sammen med oppdragsgiver. Mesteparten av de tekniske kravene var det opp til gruppen selv å finne ut av. De krav som har vært i dokumentet har vi jobbet konsekvent etter i utviklingen av applikasjonene. Det har i utgangspunktet bare vært én kravspesifikasjon, men ettersom oppdragsgiver har sett resultatene av de opprinnelige kravene har disse blitt endret og derfor blitt to versjoner. Det originale, og det endelige dokumentet. Vi har nevnt tidligere i rapporten at grunnen til dette, var fordi kvalitet på applikasjonene da ble forbedret. Et eksempel på et opprinnelig krav vi hadde, var at emnet Mail Abonnering skulle lastes direkte inn i applikasjonen. Dette tok veldig lang tid og derfor etter oppdragsgivers ønske forandret vi dette. Vi forandret da til at vi skulle lage en webside som et mellomledd i å abonnere på NRs nyhetsbrev. Et annet eksempel, var at vi skulle hente informasjon i fra bloggen til NR som feed. Men dette viste seg å ikke bli et godt resultat. Så vi forandret dette til ha samme løsning som feeds. Blogg ble endret til å benytte seg av RSS og ikke som en webside etter ønske fra oppdragsgiver. Dette resulterte derimot i at det kom html kode vist i siden, så dette endrete kravet måtte vi gå tilbake på og heller bruke en webside som originalt antatt. Begge versjonene av kravspesifikasjonen er lagt til som vedlegg i dokumentet. Side 34

35 15. Mulige Forbedringer I et program vil det alltid være forbedringspotensialer. Via oppdragsgiver har vi fått vite at Norsk Regnesentral kommer til å restrukturere sin webside. Da vil nyhetsidens kode være nødt til å tilpasses dette. Igjennom hele utviklingsprosessen har vi hørt at oppdragsgiver har vært positivt overrasket over framgangen og hva vi har fått i stand. Punktene under vil være hvilke forbedringspotensialer vi tror applikasjonene våre har. Nyheter og Blogg - For sidene med redigert html: få siden mer kompakt ved marginer rundt. Flere iterasjoner med brukertest mellom. Få stresstester applikasjonen og Accessibility. Nyheter Android - Vis bildene fra NRs side. Feeds - Hent inn bare et bestemt antall feed på en gang. Mulighet til å hente in flere etter knappetrykk. Kart - Rute fra din posisjon til Norsk Regnesentral. Visuelle forbedringer etter iterasjonstester. Side 35

36 16. Oppsummering/Konklusjon Ettersom ønsket til NR var å informere allmenheten om organisasjonen, prosjektene og tjenestene de tilbyr, konkluderer vi med å ha hjulpet NR med å realisere deres ønske. Vi mener at applikasjon vi har fått lov til å utvikle, forenkler denne informasjons videre formidlingen på en utmerket måte. Nå har alle muligheten til å ha NR i sin lomme. Vi er beæret over å ha jobbet med en så stor forskningsbedrift som det Norsk Regnesentral er. I prosjektperioden har det vært mange utfordringer som prosjektgruppen har stått ovenfor. En av disse var at vi fikk en oppgave som vokste i omfang. Dette på grunn av at visse funksjoner ikke fungerte optimalt og måtte endres. Det har ofte vært mye frustrasjon og for å komme videre har gruppen vært nødt til å slå hodene sammen og finne løsninger på problemstillingene sammen som gruppe. Eksempler på dette er ved å forandre tegnkodingen til Latin1. Dette strevde gruppen med på begge applikasjonene. Vi mener det å ha stått ovenfor en så stor oppgave med mange utfordringer som har oppstått, har vært en et godt utgangspunkt i å lære seg frustrasjonsmestring. Vi har alle forskjellig bakgrunner når det gjelder kompetanse og kultur. Dette er også en erfaring rikere vi har gjort oss. Det å dele inn arbeid og finne hvilket arbeid som passet best for hver enkelt var en utfordring vi løste ved at vi alle var proaktive i å si hva vi kunne og hva vi ikke kunne. For eksempel ville en i gruppen som var språkmektig ta for seg hovedansvar for dokumentasjon og en som stod sterkt programmeringsmessig ta for seg hovedansvar for programmering. Når det gjelder utviklingsmiljø, har prosjektgruppen lært seg å arbeide med nytt programmeringsspråk som Objekt C og kombinere javakode med XML-filer. Selv om ikke alle har programmert har alle vært nødt til å sette seg inn i hva hvert enkelt gruppemedlem har arbeidet med. Utviklingsverktøyene som har blitt brukt i utviklingen av applikasjonene har prosjektgruppen også lært seg å bruke. Vi hadde ikke brukt dette til applikasjonsutvikling tidligere og nå kan vi bruke dette til eventuelle andre prosjekter som prosjektgruppen skal arbeide med. Side 36

37 Side 37

38 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen er, hvem som er arbeidsgiver samt litt bakgrunnsinformasjon om prosjektet. Dokumentet beskriver i hovedsak hvordan systemet skal fungere og se ut. Kravene er delt opp i funksjonelle og ikke-funksjonelle krav. Dokumentet inneholder også krav til de som skal drive opplæring i systemet, mulige organisatoriske og personellmessige konsekvenser før vi runder av med hvilke krav det er til dokumentasjon. For den som kjenner til prosjektet, lest produktdokumentasjon, prosessdokumentasjon eller forprosjektet; anbefaler vi å starte med å lese i fra kapittel fire. Side 38

39 2. Innholdsfortegnelse 1. Forord 2. Innholdsfortegnelse 3 innledning Om Prosjekt Gruppen Om Oppdragsgiver Dagens situasjon Mål Funksjonelle egenskaper og krav Funksjonelle krav Ikke-funksjonelle krav Spesifikke krav av delsystemer Meny/Menu Funksjonelle krav Ikke-funksjonelle krav Om NR Funksjonelle krav Ikke-funksjonelle krav: Nyheter Funksjonelle krav Ikke-funksjonelle krav Blogg Funksjonelle krav Ikke funksjonelle krav Feeds Funksjonelle krav Ikke-funksjonelle krav Mail Abonnering/Subscription Funksjonelle krav Kontakt NR Funksjonelle krav Ikke-funksjonelle krav Side 39

40 5.8 Kart Funksjonelle krav Logisk datamodell Krav til opplæring i bruk av systemet 48 Side 40

41 3 innledning Dette dokumentet er laget med henhold til hovedprosjekt på høgskolen i Oslo og Akershus. Dokumentet inneholder i hovedsak hvilke kriterier systemet er utviklet etter. Noen kriterier eller krav er utarbeidet i løpet av utviklingen av produktet. Først har vi en overordnet systembeskrivelse som gir et grovt innblikk i hva som er ønsket, hvem som ønsker det og hvem som har utført arbeidet. Vi har delt opp krav som norsk regnesentral har i funksjonelle og ikke-funksjonelle krav. 3.1 Om Prosjekt Gruppen Prosjektgruppen er satt sammen i fra høgskolen i Oslo og Akershus og består av 5 studenter. Vi er tre studenter i fra studiene dataingeniør, èn student i fra anvendt it og èn student i fra informasjonssystemer og it-ledelse. Alle studentene er i fra forskjellige nasjonaliteter: Norge, Spania, Etiopia, Syria og Iran. 3.2 Om Oppdragsgiver Oppdragsgiver er Norsk Regnesentral, et forskningsinstitutt som har 70 ansatte hvor 60 av disse er forskere. Norsk Regnesentral er en uavhengig, ideell og allmennyttig privat stiftelse som utfører oppdragsforskning for næringsliv, offentlig sektor og private organisasjoner både i Norge og internasjonalt. Forskningsområdene er IKT og statistisk modellering, og NR er ett av Europas største miljøer innen anvendt statistikk. Største anvendelser er petroleum, finans/forsikring, jordobservasjon, miljø, helse, forvaltning og bildeanalyse. Innen IKT arbeides det med informasjonssikkerhet, universell utforming og smarte informasjonssystemer. Prosjektgruppen jobber i samarbeid med Institutt for Anvendt forskning i Informasjonsteknologi. Siden NR ble stiftet i 1952 til 1970 har NR hatt en viktig rolle i å utføre matematiske beregninger for andre organisasjoner. NR har jobbet med statistikk, fjernmåling, datakommunikasjon, internett vitenskap, multimedia, GEO statistikk, petroleum, marine ressurser, strømpriser og finans. Selskapet ble først et selvstendig institutt i 1985 og i 1988 flyttet den til sin nåværende lokasjon. NR er blant annet kjent for oppfinnelsen av programmeringsspråket Simula.. Side 41

42 3.3 Dagens situasjon Norsk Regnesentral har per dags dato tre typer informasjonskanaler. Igjennom e-post, sms og en webside formidler de informasjon til sine ansatte og det offentlige. De ønsker å utvide dette slik at Norsk Regnesentral kan forenkle informasjonsformidling til sine ansatte, privatpersoner og bedrifter som er interessert i å få informasjon om Norsk Regnesentral og deres tjenester. Dette igjennom å utvikle en applikasjon som støtter Android og ios som er de mest brukte mobiloperativsystemene på markedet. Dette har dannet grunnlaget for hovedprosjektet som Høgskolen i Oslo og Akershus har kunnet videreformidle til studenter og hvor vi har valgt dette som hovedprosjekt. 3.4 Mål Vi har etter oppdragsgivers ønske og etter beste evne utviklet et produkt som Norsk Regnesentral kan anvende nå og videreutvikle på et senere tidspunkt. Målet vårt var å utvikle en applikasjon som var brukervennlig og oppfylte de krav som oppdragsgiver hadde gitt. Disse kan man lese mer om senere i dette dokumentet. Vi føler vi har klart oppgaven og nådd de målene vi har satt sammen med oppdragsgiver. 3.5 Rammekrav - Applikasjonen skal kunne støtte Android og ios. - Applikasjonen skal være universelt utformet. - Det skal være mulig å utvide systemet.. - Applikasjonen skal være brukervennlig. Med brukervennlig menes at systemet skal være lett å hente informasjon ut i fra, samtidig som at systemet automatisk skal hente oppdatert informasjon i fra norsk regnesentral sine nettsider. - Støtte for Norsk og Engelsk. Side 42

43 4. Funksjonelle egenskaper og krav Under vil det bli en mer detaljert beskrivelse av hvilke funksjonelle og ikke-funksjonelle krav systemene er bygget opp etter. Beskrivelsene i kravene under gjelder generelt for systemene ios og Android. 4.1 Funksjonelle krav - Applikasjonen skal kunne støtte norsk og engelsk språkvalg i telefonen. - Applikasjonens standardspråk skal være satt til engelsk. - Det skal vises tydelig hvilket delsystem som blir valgt. - Skal være støtte for VoiceOver. - Hvis applikasjonen ikke har tilgang til internett eller inneholder feil, skal applikasjonen gi informasjon om dette. - Hvis applikasjonen laster opp informasjon skal den ha en indikator som viser dette. - Tegnkoding skal være satt til UTF-8, latin1 for tekst hentet fra nett. 4.2 Ikke-funksjonelle krav - Delsystemene skal ha rekkefølge: Nyheter, Om NR, Kontakt NR, Blogg, Feeds, Mail Abonnering og Kart. - Knappene skal plasseres vertikalt under hverandre og være oppført På en ryddig og strukturert måte. - Fargene skal ha god kontrast. - Det skal ikke ta mer enn 5 sekunder å komme inn på hvert delsystem. - Delsystemene skal vises i form av knapper. Side 43

44 5. Spesifikke krav av delsystemer I teksten under er det beskrevet hvilke krav som er spesifikt knyttet til hvert delsystem og de som gjelder for begge systemene IOS og Android. 5.1 Meny/Menu Funksjonelle krav - Skal være en tabell. - Skal inneholde referanse til hvert delsystem. - Det skal være enkelt å komme inn på hvert delsystem ved å ikke komme borti de andre radene når man velger emner Ikke-funksjonelle krav. - Skal være én overskrift i applikasjonen. - Skal hete Norsk Regnesentral. Norwegian Computing Center på engelsk. - Skal inneholde rader som setter i gang applikasjonens ulike delsystemer. 5.2 Om NR Funksjonelle krav - Ved å velge delsystemet Om NR skal informasjon om Norsk Regnesentral vises. - Informasjonen skal ligge lagret i applikasjonen. - Informasjonen skal hentes i fra applikasjonen. - Siden skal være i en tekstboks Ikke-funksjonelle krav: - Informasjonen som ligger lagret på applikasjonen skal inneholde generell informasjon, historie, samarbeidspartnere, hensikt med organisasjonen og hva organisasjonen arbeider med. - Det skal være sammendrag i fra Norsk Regnesentral sine sider hvor informasjonen er tilpasset applikasjonen. Side 44

45 5.3 Nyheter Funksjonelle krav - Ved å velge delsystemet Nyheter skal applikasjonen hente utvalgt informasjon direkte i fra Norsk Regnesentral sine sider Ikke-funksjonelle krav - Vises som tekst og eventuelt bilder. 5.4 Blogg Funksjonelle krav - Ved å velge delsystemet Blogg skal det hentes informasjon direkte i fra Norsk Regnesentrals blogg side. - Det skal brukes RSS objekter i blogg Ikke funksjonelle krav - Skal vises som tekst og eventuelt bilder. 5.5 Feeds Funksjonelle krav - Når man velger delsystemet Feeds skal informasjon hentes fra en RSS feed på Norsk Regnesentrals hjemmeside. - Det skal brukes RSS objekter Ikke-funksjonelle krav - Vises som tekst. Side 45

46 5.6 Mail Abonnering/Subscription Funksjonelle krav - Det skal opprettes en html-form som et mellomledd for å registrere en epost-adresse til Norsk Regnesentrals mailingliste. 5.7 Kontakt NR Funksjonelle krav - Kontakt informasjon skal ligge lagret på applikasjonen og hentes derifra Ikke-funksjonelle krav - Siden skal være ryddig og strukturert. - Overskriften for hver seksjon skal være h1 eller h2. - Tittel for ansatte skal være boolean. 5.8 Kart Funksjonelle krav - Applikasjonen skal koble seg til Googles karttjeneste. - Kartet skal vises i applikasjonen. - Lokasjon til Norsk Regnesentral skal vises. - Lokasjon til bruker skal kunne velges på applikasjonen. Side 46

47 6. Logisk datamodell Under ser man en overordnet skisse av systemet og funksjonenes tilgjengelighet. Side 47

48 7. Krav til opplæring i bruk av systemet I dette kapittelet vil man gå igjennom hvilke forutsetninger det er satt for de personer som skal bruke, administrere og drive opplæring av systemet. Administrasjon Ansvar for å koordinere tid for opplæring med henhold til systemet. Beherske norsk eller engelsk Applikasjonen skal kunne administreres på to språk og det er bestemt av oppdragsgiver at det ikke er behov for flere språkvalg en norsk og engelsk. Det er derfor viktig at de som bruker systemet kan beherske ett av to språk som applikasjonen er designet med. Innføring i systemet Oppdragsgiver eller ansatte skal kunne være tilgjengelig for innføring i systemet. Prosjektgruppen skal gi en innføring for oppdragsgiver og aktuelle ansatte i bedriften om hvordan systemet fungerer. Opplæring av ansatte De personene som har fått innføring i systemet vil kunne opplære andre ansatte som har behov for innføring. Tilgang til smartphones Systemet er ment for smarttelefoner, og det er derfor nødvending at brukere innehar eller har tilgang til en smarttelefon. Kunnskap Det er en forutsetning at de som driver opplæring i systemet har kjennskap til Android Market og Apple Appstore for nedlasting av applikasjoner. 9. Krav til dokumentasjon Produktet skal kunne dokumenteres igjennom dokumentasjon. Denne dokumentasjonen skal inneholde all nødvendig informasjon om produktet, hvordan det er utviklet og hvordan det brukes. Dokumentasjonen som legges ved rapporten er: 1. Prosessrapport 2. Produktdokumentasjon 3. Testrapport 4. Kravspesifikasjon 5. Brukerdokumentasjon Side 48

49 Side 49

50 1. Forord Denne produktdokumentasjonen skal kunne leses som et selvstendig dokument. For den som har lest forprosjektet, kravspesifikasjonen eller kjenner godt til prosjektet, er det ikke nødvendig å lese kapittel tre og fire med underkapitler. Leseren kan da begynne i fra kapittel fem, hvis ikke et annet kapittel faller mere interessant. Hvis den som leser dette ikke kjenner til prosjektet anbefaler vi å lese dokumentet i sin helhet. I denne produktdokumentasjonen vil det i hovedsak bli beskrevet hvordan applikasjonen er bygget opp. Den er delt opp i to deler. Beskrivelsen av produktet for ios og Android. Tekniske utrykk som brukes i beskrivelsene og forklaringene for applikasjonene er lagt til som vedlegg i ordlisten. Denne er anbefalt å ha bruke hvis det skulle være ord og utrykk som er uforståelig. Dokumentasjonen er interessant for personer som har til hensikt å videreutvikle, installere, vedlikeholde og modifisere systemet på et senere tidspunkt. Det vil også være interessant for personer som har til hensikt å markedsføre eller skal drive brukerstøtte. Mer detaljert informasjon om hvilke løsninger, valg og utfordringer vi har hatt under produksjonen av applikasjonene, kan du lese mer om i prosessdokumentasjonen. Detaljert beskrivelse av krav vil fremkomme i kravspesifikasjonen. Ettersom det er to applikasjoner vi har utviklet, vil applikasjonene og hvordan vi har utviklet disse være beskrevet noe forskjellig selv om de har mye til felles. I dokumentet kan man lese om hvilke verktøy og programmeringsspråk vi har brukt for å utvikle ios(i operative systems) og Android. ios og Android er mobile operativsystem og er de mest brukte i markedet. Det vil bli vist eksempler på bilder og kode vi har brukt til å utvikle begge produktene. For å få fult utbytte av denne dokumentasjonen er det en fordel av man har kunnskap og erfaring med programmeringsspråkene Object C og Java samt utviklingsplattformene Xcode og Eclipse, selv om dette ikke er en nødvendighet. Side 50

51 2. Innholdsfortegnelse 1. Forord Innholdsfortegnelse Innledning Om Prosjekt Gruppen Om Oppdragsgiver Dagens situasjon Mål Overordnet beskrivelse av produktet ios Teknologier Applikasjonens struktur og oppbygning Meny Nyheter Om NR Kontakt NR Blogg Feeds Mail Abonnering Kart Utvikling videre Android Teknologier Applikasjonens struktur og oppbygning Meny Nyheter Om NR Kontakt NR Blogg Feeds Mail Abonnering Side 51

52 6.2.8 Kart Utvikling videre Side 52

53 3. Innledning I dette kapittelet har det blitt skrevet om prosjektgruppen, hvem de er, hvor de kommer i fra og litt om bakgrunnen til hver enkelt. Det er også skrevet om hvem arbeidsgiver er, historie, hvor mange ansatte og hva deres arbeid går ut på. Senere i kapittelet vil det bli sagt litt om dagens situasjon hos arbeidsgiver, kort om rammebetingelser og hvorfor prosjektgruppen har fått dette oppdraget. Til slutt i dette kapittelet vil det bli en kort overordnet beskrivelse av systemet. 3.1 Om Prosjekt Gruppen Prosjektgruppen er satt sammen i fra høgskolen i Oslo og Akershus og består av 5 studenter. Vi er tre studenter i fra studiene dataingeniør, en student i fra anvendt it og en student i fra informasjonssystemer og it-ledelse. Alle studentene er i fra forskjellige nasjonaliteter: Norge, Spania, Etiopia, Syria og Iran. 3.2 Om Oppdragsgiver Oppdragsgiver er Norsk Regnesentral, et forskningsinstitutt som har 70 ansatte hvor 60 av disse er forskere. Norsk Regnesentral er en uavhengig, ideell og allmennyttig privat stiftelse som utfører oppdragsforskning for næringsliv, offentlig sektor og private organisasjoner både i Norge og internasjonalt. Forskningsområdene er IKT og statistisk modellering, og NR er ett av Europas største miljøer innen anvendt statistikk. Største anvendelser er petroleum, finans/forsikring, jordobservasjon, miljø, helse, forvaltning og bildeanalyse. Innen IKT arbeides det med informasjonssikkerhet, universell utforming og smarte informasjonssystemer. Prosjektgruppen jobber i samarbeid med Institutt for Anvendt forskning i Informasjonsteknologi. Siden NR ble stiftet i 1952 til 1970 har NR hatt en viktig rolle i å utføre matematiske beregninger for andre organisasjoner. NR har jobbet med statistikk, fjernmåling, datakommunikasjon, internett vitenskap, multimedia, geostatistikk, petroleum, marine ressurser, strømpriser og finans. Selskapet ble først et selvstendig institutt i 1985 og i 1988 flyttet den til sin nåværende lokasjon. NR er blant annet kjent for oppfinnelsen av programmeringsspråket Simula. Side 53

54 3.3 Dagens situasjon Norsk Regnesentral har per dags dato tre typer informasjonskanaler. Igjennom e-post, sms og en webside formidler de informasjon til sine ansatte og det offentlige. De ønsker å utvide dette slik at Norsk Regnesentral kan forenkle informasjonsformidlingen til sine ansatte, privatpersoner og bedrifter som er interessert i å få informasjon om Norsk Regnesentral og deres tjenester. Dette igjennom å utvikle en applikasjon som støtter Android og ios som er de mest brukte mobiloperativsystemene på markedet. Dette har dannet grunnlaget for hovedprosjektet som Høgskolen i Oslo og Akershus har kunnet videreformidle til studenter og hvor vi har valgt dette som hovedprosjekt. 3.4 Mål Vi har etter oppdragsgivers ønske og etter beste evne utviklet et produkt som Norsk regnesentral kan anvende nå og videreutvikle på et senere tidspunkt. Målet vårt var å utvikle en applikasjon som var brukervennlig og oppfylte de krav som oppdragsgiver hadde gitt og som man kan lese mere om i kravspesifikasjonen. Vi føler vi har klart oppgaven og nådd de målene vi har satt i sammen med oppdragsgiver. Side 54

55 4. Overordnet beskrivelse av produktet Hensikten med systemet skal være å gi brukere av smarttelefoner informasjon, slik at de til enhver tid har mulighet til å være oppdatert med den nyeste informasjonen som er utgitt i fra Norsk Regnesentral. Dette skal komme i form av en applikasjon, et tilleggsprogram som håndterer informasjonen som norsk regnesentral vil formidle på en enkel og strukturert måte. Applikasjonene skal være to-språklig, norsk og engelsk. De skal inneholde funksjonene Om NR, Nyheter, Blogg, Feeds, Mail Abonnering, Kontakt NR og Kart og hvor disse skal vises som rader. Applikasjonene og funksjonene er beskrevet detaljert i kravspesifikasjonen. Under vil man se en grafiskfremstilling av applikasjonen og hvordan man navigerer seg fram i fra hovedmenyen og til de forskjellige emnene. Nyheter Feeds Om NR Meny Blogg Kontakt NR Mail Abonnering Kart Figur 1. Side 55

56 5. ios Dette kapittelet tar for seg sluttproduktet av applikasjonen for ios. Vi velger først å beskrive noen av teknologiene som ligger bak som vil være til hjelp når vi beskriver de ulike delene av applikasjonen. Etter vi har tatt for oss programmet vil det til slutt bli et kapittel som kan være til hjelp for utvikling videre. 5.1 Teknologier I utviklingen av applikasjonen har vi brukt Apple sitt utviklingsmiljø Xcode for Mac. Dette er et program som kan lastes ned gratis for alle brukere av Mac med en Apple ID. Med i dette utviklingsmiljøet er en egen simulator som vi har brukt til å teste applikasjonen mens vi har kodet. 5.2 Applikasjonens struktur og oppbygning Vår applikasjon bygger på en navigasjonskontrollør objekt som sørger for strukturen i programmet. Det er denne som holder styr på navigasjonen mellom meny og delfunksjonene, og er synlig i de blå navigasjonstoppene du ser øverst på hvert View i applikasjonen. Vi bygde denne applikasjonen på et eget template i Xcode hvor navigasjonskontrolløren, første tabellside og en tom linket side allerede var satt. Vi endret på tabellen og lagde sidene på nytt, men navnene på klassene har blitt beholdt. Dette er de to ViewController ene med spesielle navn. I tillegg har det blitt med en egen AppDelegate klasse som styrer handlinger som skal skje ved spesielle handlinger ved selve applikasjonen. Vi har ikke lagt til noe ekstra i denne. Denne applikasjonen har åtte klasser: - AppDelegate - MasterViewController - DetailViewController - NRFeeds - FeedView - NRNews - NRBlog - NRMap De syv siste er ViewControllere. I tillegg har vi to logo filer og to localizable.strings filer som bestemmer applikasjonslogoen og tekstspråket respektivt. Xcode har også lagt ved Side 56

57 egne filer som skal være med i kjøringen av applikasjonen. Det eneste ekstra vi har lagt ved er MapKit for å få kart til å bruke Googles karttjenester. MainStoryBoard brukes til å få utviklingen visuelt framstilt og er innebygd i Xcode. Under er det vist strukturen på prosjektmappen. Figur 2. Side 57

58 5.2.1 Meny Figur 3. ViewController : MasterViewController. Synkroniserte Objekter: Etiketter med navn, tabellradene under etikettene og navigasjonstoppen. Når meny starter vil alle etikettene som vises i de forskjellige radene og navigasjonsteksten kalle på en lokal streng som inneholder teksten som skal vises. Det valgte språket på mobilen bestemmer om dette er den engelske eller norske versjonen av localizable.string som blir kalt på. Teksten som vises på bilde over er plassholdere som symboliserer hvor disse feltene er, for å gjøre det lettere for oss å vite hva som går hvor. Radene har blitt delegert til å åpne et nytt View når de blir trykket på som inneholder den ønskete funksjonen. Navigasjonstoppen får også en annen blåfarge i oppstart av menyen. Vi har slått av alle tilgjengelighets innstillinger for selve etikettene, slik at disse ikke leses opp som statiske tekster. Radene har vi endret innstillinger til å leses som knapper med samme lokaliserte tekst som for etikettene. Tekstlokaliseringene og fargeendringen foregår i klassens ViewDidLoad funksjon. Tabellen og plasseringen av etikettene er definert i MainStoryBoard. Side 58

59 5.2.2 Nyheter Figur 4. ViewController: NRNews. Synkroniserte Objekter: Navigasjonstopp og WebView. Lokasjon i oppstart av klassen gjør at navigasjonsetiketten skifter til rett navn. I WebView sender vi inn en html streng som vi bygger selv basert på kildekode hentet fra Norsk Regnesentrals nyhetsside. Vi lager denne strengen ved en funksjon som leser innholdet av en gitt URL og spesifiserer tegnkoden til å være NSISOLatin1StringEncoding. Dette vil være html-koden som ligger bak URL en i vårt tilfelle. Denne strengen splittes opp i en liste basert på funn av tegnene <h. En ny streng som inneholder html koden vi ønsker å vise bygges opp fra innholdet til listen. Vi har selv telt via kildekoden hvor nyhetsartiklene på Norsk Regnesentrals side starter. Første artikkel og utover settes i denne nye strengen, hvor vi foran hver artikkel også må plassere de to tegnene vi brukte til å lage listen. Side 59

60 Figur 5. Skulle denne kalte delen av listen være tom, antar vi at brukeren ikke har tilkobling til internett og gir en lokalisert strengtekst med beskjed om dette i stedet. Den forhåndsbestemte innstillingen om å skalere websiden til å passe mobilvinduet slås av når det ikke er internett for å vise denne beskjeden mer tydelig. Side 60

61 5.2.3 Om NR Figur 6. ViewController: DetailViewController. Synkroniserte Objekter: Navigasjonstopp og tekstfelt. Om NR er en av tre funksjoner vi mente var såpass små at de ikke trengte en egen klasse for utførelse. I ViewDidLoad på DetailViewController blir navigasjonsetikettet og innholdet av tekstfeltet satt ved lokasjonsstrenger. Her har også tekststørrelsen blitt skrudd opp fra 14 til 18 på tekstfelt objektet. Side 61

62 5.2.4 Kontakt NR Figur 7. ViewController: DetailViewController. Synkroniserte Objekter: Navigasjonstopp og WebView. I Kontakt NR blir navigasjonsetikettet satt ved lokasjon og i WebView sender vi inn en lokasjonsstreng som inneholder kontaktinformasjon. Denne har vi selv skrevet ved html kode og DetailViewController sin ViewDidLoad kjører koden her. Side 62

63 5.2.5 Blogg Figur 8. ViewController: NRBlog. Synkroniserte Objekter: Navigasjonstopp og WebView. Etikettet til Blogg endres også her ved hjelp av lokasjon. Som nyheter tar vi her html koden som ligger bak URL en til Norsk Regnesentrals blogg og lager en streng av koden med tegnsettet NSUTF8StringEncoding. Vi deler denne strengen etter teksten <div id= node- i en liste, og henter ut alle forekomstene i en ny streng. I tillegg tar vi med hele html-header (<head></head>) og CSS informasjonen der med i den nye html strengen for å få det visuelle oppsettet i orden. Resten av strengen definerer vi som html body. Denne html strengen bruker vi i WebView for å vise blogg. Hvis listen er tom, antar vi at det ikke er internett forbindelse og sender ut en streng med informasjon om dette. Vi slår også av skaleringsinnstillingen på WebView. Side 63

64 5.2.6 Feeds Figur 9. ViewController: NRFeeds for listevisning av feeds. FeedView for å vise innholdet. Synkroniserte Objekter: NRFeeds: Navigasjonstopp. FeedView: WebView. Etikettittelen endres i NRFeeds ViewDidLoad funksjon. For å hente inn alle feeds fra Norsk Regnesentral lagrer vi innholdet av RSS filen deres som en lang tekststreng med NSISOLatin1StringEncoding. Denne konverteres til en NSUTF8StringEncoding ved å lagre strengen som en data fil med NSISOLatin1StringEncoding tegnkode og lage en ny streng av denne med NSUTF8StringEncoding. Vi splitter opp i en liste denne strengen ved ordet <item>. Atom RSS som Norsk Regnesentral strukturerer sine feeds på denne måten: <item> </item> <title> </title> <link> </link> <description> </description> Side 64

65 På alle objektene i lista tar applikasjonen ut tittel og beskrivelse, og legger dette i to egne private lister. Dette gjøres ved å finne startposisjonen og sluttposisjonen til de tilhørende taggene, og ta ut innholdet mellom. Til slutt fjernes mellomrom i starten og slutten av tittel strengene. Om strenglisten er tom eller bare inneholder teksten som kommer før <item>, antas det at det ikke er internettforbindelse. Alt dette foregår i ViewDidLoad metoden for NRFeeds klassen. NSArray *arrayfeeds = [sourcefeeds componentsseparatedbystring:@"<item>"]; int nfeeds = [arrayfeeds count]; titles = [[NSMutableArray alloc] init]; descriptions = [[NSMutableArray alloc] init]; if(nfeeds < 2) { } else { [titles addobject:nslocalizedstring(@"nointernettfeed", nil)]; [descriptions addobject:@""]; for(int i = 1; i < nfeeds; i++) { NSRange starttitle = [[arrayfeeds objectatindex:i] rangeofstring:@"<title>"]; NSRange endtitle = [[arrayfeeds objectatindex:i] rangeofstring:@"</title>"]; [titles addobject:[[arrayfeeds objectatindex:i]substringwithrange:nsmakerange(starttitle.location + 7, endtitle.location - starttitle.location - 8)]]; NSRange startdesc = [[arrayfeeds objectatindex:i] rangeofstring:@"<description>"]; NSRange enddesc = [[arrayfeeds objectatindex:i] rangeofstring:@"</item>"]; [descriptions addobject:[[arrayfeeds objectatindex:i]substringwithrange:nsmakerange(startdesc.location, enddesc.location - startdesc.location)]]; } Side 65

66 nfeeds = [titles count]; for(int j = 0; j < nfeeds; j++) { [titles replaceobjectatindex:j withobject:[[titles objectatindex:j]stringbytrimmingcharactersinset: [NSCharacterSet whitespaceandnewlinecharacterset]]]; } } For å vise tabellen som er dynamisk lagd i View-et spesifiserer vi egenskapene i funksjoner i NRFeeds klassen. Vi har satt antall seksjoner til alltid å være en. Antall rader er spesifisert til å være like mange som antall titler i tittellisten. For hver rad setter vi både tilgjengelighet og rad tekst til å være tittelen på feedet som ligger bak. Når en rad velges, åpnes et XIB vindu med en opprettet FeedView klasse bak. I denne klassen setter vi de private variablene title og description til å være teksten i innholdet av tittel og beskrivelse listenes indeks, som er den samme som den raden. Denne teksten vises i en WebView i FeedView som en html side. Side 66

67 5.2.7 Mail Abonnering Figur 10. ViewController: DetailViewController. Synkroniserte Objekter: Navigasjonstopp og WebView. Mail Abonnering åpner en lokal html fil i WebView som sender informasjon videre til en mailchimp webside. Denne siden har blitt lagd for Norsk Regnesentral til håndtering av deres påmelding for nyhetsbrev. Vi har lagd stikkordsform av alle tekstene som vises på siden og bruker string replace med lokasjonstekst for å oversette mellom norsk og engelsk. Navigasjonstoppen skilles også ved hjelp av lokasjon. Brukeren skriver inn -adressen sin i tekstfeltet som vises på siden og trykker på abonner knappen. Hvis det ikke er internettforbindelse vil en vanlig feilside om dette vises i vinduet. Skulle det være feil med -adressen vil mailchimp sin side gi beskjed om dette. Hvis en ble sendt vil Mailchip si ifra at adressen ble registrert. Disse tilbakemeldingene vises kun på mobiltelefonen og ikke emulator. Side 67

68 5.2.8 Kart Figur 11. ViewController: NRMap. Synkroniserte Objekter: Navigasjonstopp og MapView. Vi har importert en kartpakke som kaller på Googles karttjenester for å få kart til å virke. Navigasjonstoppen endres etter lokasjon. Vi har slått på innstilling for å vise din egen posisjon på MapView objektet og lagret latitude og longitude for midten av Oslo og Norsk Regnesentrals kontor. Kontoret har vi markert på kartet og vi bruker Oslos posisjon til å definere regionen kartet viser. I ViewDidLoad: _MapLabel.title = NSLocalizedString(@"MapLabel", nil); CLLocationCoordinate2D nrlocation; CLLocationCoordinate2D oslo; oslo.latitude = ; Side 68

69 oslo.longitude = ; nrlocation.latitude = ; nrlocation.longitude = ; MKPointAnnotation *annotationpoint = [[MKPointAnnotation alloc] init]; annotationpoint.coordinate = nrlocation; annotationpoint.title Regnesentral"; annotationpoint.subtitle = NSLocalizedString(@"MapText", nil); [_MapView addannotation:annotationpoint]; MKCoordinateSpan span = {0.1, 0.1}; MKCoordinateRegion region = {oslo, span}; [_MapView setregion:region]; Side 69

70 5.2.9 Utvikling videre For videreutvikling av dette prosjektet trenger du Xcode og et eksemplar av prosjektmappen. Prosjektet åpnes ved filen NR.xcodeproj du finner i prosjektmappen. 6. Android Dette kapittelet tar for seg sluttproduktet av applikasjonen for Android. Vi velger først å beskrive noen av teknologiene som ligger bak som vil være til hjelp når vi beskriver de ulike delene av applikasjonen. Etter vi har tatt for oss programmet vil det til slutt bli et kapittel som kan være til hjelp for utvikling videre. 6.1 Teknologier Vi har brukt Eclipse for utvikling av applikasjonen. Programmet lastes ned gratis for alle brukere. Vi måtte også laste ned Android SDK verktøy for å kunne utvikle Android prosjekter i Eclipse og den har Emulator for å vise og teste ut hvordan ser applikasjonen ut på en mobiltelefon. 6.2 Applikasjonens struktur og oppbygning Applikasjonen er bygd på Java klasser og XML-filer. Den har ni klasser: - AndroidprojectActivity - about - blogg - contact - feeds - FeedView - maillist - map - news Og ni XML filer: - main Side 70

71 - about - blogg - contact - feeds - feedview - maillist - map - news I tillegg er det drawable mapper som inneholder logobilde og markørbilde, og values mapper som inneholder strenger for språk. Figur 12. Side 71

72 6.2.1 Meny Klasse: AndroidprojectActivity.java Layout: main.xml Meny er lagd i et LinearLayout med knapper på XML-filen. Hver knapp har en egen identifikasjon og tekst satt av lokasjon. I klassefilen har hver knapp en OnClickListener som åpner en ny Activity med tilhørende klasse Nyheter Figur 13. Klasse: news.java Layout: news.xml Nyheter starter ved å slå på Javascript i WebView. Vi starter også et loading bilde som skal vise at applikasjonen jobber. Vi har valgt å slå på nettverksjobbing i bygge tråden, så vi endrer policy til Android for denne siden til å godta dette. En ny runnable kjører innlasting og visning av websiden. Side 72

73 En try-catch metode bestemmer hva som blir vist. Vi prøver å bruke en BufferedReader til å lese teksten som ligger bak URL en til Norsk Regnesentrals webside. InputStreamReader har vi satt til å lese tegnkoden ISO (latin1). Teksten leses linje for linje og settes inn i en StringBuffer. En streng blir lagd fra denne bufferen og teksten deles opp i en liste mellom alle funn av tegnene <h. Figur 14. Indeks fire og utover settes inn i en streng ved hjelp av StringBuilder, hvor tegnene som blir borte etter å ha splittet teksten settes med i tillegg. Boksen som viser at applikasjonen jobber slås av, vi konverterer strengen til base64 med en innebygd funksjon i Android SDK og vi viser resultatet i WebView med dens loaddata funksjon. Den konverterte strengen, text/html; charset=iso og base64 sendes med som parametere. Hvis det kommer noen feil underveis sendes en html side med en feilmelding i WebView. Side 73

74 6.2.3 Om NR Figur 15. Klasse: about.java Layout: about.xml Vi har brukt LinearLayout for Om NR delfunksjon og MediumTextView for innholdet. Teksten ble lagret som streng i values mappen for å kunne oversette den. Denne teksten er satt i XML-filen. Side 74

75 6.2.4 Kontakt NR Figur 16. Klasse: contact.java Layout: contact.xml Kontakt NR åpner en nettside i WebView med lokasjonsstreng som innhold, text/html; charset=utf-8 som type og null som tegnkoding. Side 75

76 6.2.5 Blogg Figur 17. Klasse: blogg.java Layout: blogg.xml I WebView endrer vi innstillinger til å ha Javascript slått på og rullefelt utenfor vinduet. Videre setter vi URL en som åpnes til Norsk Regnesentrals bloggside. En meldingsboks viser at siden laster og stopper når denne er ferdig. Hvis det er feil gir WebView beskjed om dette. Side 76

77 6.2.6 Feeds Figur 18. Klasser: feeds.java og FeedView.java Layout: feeds.xml og feedview.xml I layout til Feeds er det satt en tom TableLayout med id tablelayfeeds. I klassefilen er nettverksoperasjoner slått på som policy og en privat TableLayout settes til å være den samme som brukt i layout. Før radene lages, hentes RSS filen til Norsk Regnesentral ned som en streng og fra denne lages en liste med feeds ved å skille mellom <item> tagger. Ut ifra disse lages to private strenglister hvor tittel og beskrivelse for hver feed settes inn i samme rekkefølge. Dette gjøres ved å lage en understreng med start og slutt tagger for <title> og <description> som parametere for hvert feed i listen. For titler fjernes mellomrom i starten og slutten av teksten. Når dette er gjort lages radene i TableView programmessig. Det blir lagd like mange rader som det er feed titler. Hver rad får satt et nummer som id og en tekst. Teksten blir satt til å være tittelteksten på feedet og en OnClickListener settes på teksten til å åpne FeedView Side 77

78 med tittel og beskrivelse på feedet. Teksten settes inn i pakken som sendes med til FeedView i to strenger. Tekststørrelse blir satt til 20 og en padding på 15 pixler blir satt på raden. Raden settes til slutt inn i TableView. Hvis dette slår feil ut vil det i TableView lages en rad med en feiltekst. Under er det vist et bilde av FeedView klassen. Figur 19. FeedView åpnes som egen Activity når brukeren har klikket på teksten til et feed. FeedView har et layout med en WebView. Tittel og tekst på feedet hentes fra pakken som ble sendt med da FeedView aktiviteten startet. Html kode lages med tittel som h2 og teksten i en egen paragraf, og denne koden vises i WebView. Side 78

79 6.2.7 Mail Abonnering Figur 20. Klasse: maillist.java Layout: maillist.xml Mail Abonnering setter en lokasjons streng med html kode inn i et WebView, i tillegg til parameterer for html med UTF-8 tegn og ingen base64 tegnkode. Side 79

80 6.2.8 Kart Figur 21. Klasse: map.java Layout: map.xml I layoutfilen ligger en API nøkkel som Google sin karttjeneste bruker for å vise kart i Android. Denne er lagd av hver unike signeringsnøkkel med MD5 nummer og passer bare til enten den signerte apk pakken eller det utviklingsmiljøet med debug keystore som brukes. I klassen slås på innstillinger for å vise forstørrelse- og forminsknings-knapper og satellitt bilde. Kartet forhåndstilles til å være over Norsk Regnesentrals kontor og en markør plasseres på dette stedet. En markør for brukeren settes også på kartet og funksjonene for View -ets OnPause og OnResume funksjoner brukes for å slå av og på brukerens posisjon. Denne vises på Android mobiltelefoner hvor det er godtatt at posisjonen for mobiltelefonen brukes. Side 80

81 6.3 Utvikling videre Utvikling videre vil kreve et utviklingsmiljø og Androids SDK pakke. Vi anbefaler nyeste versjonen av Eclipse til dette. Androids utviklerside viser hvordan man installerer denne[1]: [1] Viktig å huske på for Android: - Kart trenger en egen API nøkkel for å vises. Denne må genereres fra MD5 nummeret til signeringsnøkkelen for applikasjonen. Nummeret finner du ved å bruke Javas Keytool på.keystore filen du signerer applikasjonen med. - Klasser åpnes som aktiviteter. Disse aktivitetene må legges til i Android Manifest filen. Klassene trenger layout XML-filer for å vises. Side 81

82 Testdokumentasjon Side 82

83 1. Innledning Dette er en testrapport som er laget for å teste applikasjonene for ios og Android plattformer. Den vil være delt opp i 4 deler. Den første delen tar for seg test av funksjonalitet. Den andre delen tar for seg brukertest. Den tredje delen vil en statistikk over de resultater som har blitt generert bli presentert. Til slutt vil det bli presentert en tilgjengelighetstest. Selve testingen er blitt gjort av studenter, prosjektgruppen, oppdragsgiver og enkelt personer som har blitt spurt om de kan være med på å teste applikasjonene. Dette vil være interessant for personer som har til hensikt å drifte og vedlikeholde programmet. Formålet med testene har vært i hovedsak å prøve å finne feil eller forbedringer som gjør at funksjonalitet eller brukervennlighet blir avklart, slik at det er mulig å forbedre. De type testene som er utført på applikasjonene er funksjonstesting, brukertesting og tilgjengelighetstesting.. Side 83

84 2. Innholdsfortegnelse 1. Innledning Innholdsfortegnelse Test av funksjonalitet ios & Android Test av ios-applikasjonen Test av Android-applikasjonen Brukertest Resultat av brukertest ios Resultat av brukertest Android Tilgjengelighetstest ios Android Side 84

85 3. Test av funksjonalitet ios & Android I dette kapittelet vil det bli beskrevet hvordan vi gjennomførte tester av de funksjoner som finnes i applikasjonene. Under ser man tabeller på de tester vi har utført på emnenes funksjoner. Vi har testet om funksjonene fungerer ved å komme ut og inn på hvert delsystem tilhørende hvert emne. Tiden er i ca tid og er relative på grunn av hvilke forutsetninger som hvor god internett forbindelse og versjoner av operativsystem som blir brukt. Tiden er også i ca fordi Vi har brukt WIFI ved testingen. Til slutt er det beskrevet om det er tilfredsstillende eller ikke. 3.1 Test av ios-applikasjonen. Type funksjon Funksjonell Ca tid inn i app/emner målt i sek. Ca tid ut av app/emner målt i sek. Tilfredsstillende ja/nei Meny Ja 0,5 0,2 Ja Nyheter Ja 2 0,2 Ja Om NR Ja 0,2 0,2 Ja Kontakt NR Ja 0,2 0,2 Ja Blogg Ja 1 0,2 Ja Feeds Ja 0,2 0,2 Ja Abonnering Ja 0,2 0,2 Ja Kart Ja 1 0,2 Ja Side 85

86 3.2 Test av Android-applikasjonen. Type funksjon Funksjonell Tid inn målt i sek. Tid ut målt i sek. Tilfredsstillende ja/nei Meny Ja 0,2 0,2 Ja Nyheter Ja 2 0,2 Ja Om NR Ja 0,2 0,2 Ja Kontakt NR Ja 1 0,2 Ja Blogg Ja 2 0,2 Ja Feeds Ja 0,5 0,2 Ja Abonnering Ja 0,2 0,2 Ja Kart Ja 1 0,2 Ja Som man ser har man ikke store forskjeller mellom tidene mellom funksjonaliteten og tiden det tar å gå inn i emnene. Den største forskjellen er i Nyheter som det tar to sekunder å få kommet inn på og få all informasjon ut i fra. Dette på grunn av at man må lese all informasjon som er i kildekoden på nett. Den andre funksjonen er tilhørende blogg og bruker ett sekund i ios. Grunnen til at den bruker litt mer tid, er på grunn av at man henter headere i fra kildekoden til websiden til NR. I Android er vi usikre på hvorfor det tar lengere tid. En mulighet er at det er forskjellig operativsystem. Side 86

87 4. Brukertest Under er det lagt frem en brukertest som er blitt utført på applikasjonene. Det ble stilt ti spørsmål til brukerne om applikasjonenes brukervennlighet og funksjonalitet. 1. Gå inn på applikasjonen og finn en nyhetsartikkel. Hvor lett var dette i fra en skala fra1 til 5, hvor 1 er dårligst og 5 er best? 2. Finn et blogginnlegg. Hvor lett var dette i fra en skala fra1 til 5, hvor 1 er dårligst og 5 er best? 3. Finn når Norsk Regnesentral ble stiftet? Hvor lett var dette i fra en skala fra1 til 5, hvor 1 er dårligst og 5 er best? 4. Finn ut av hvor Norsk Regnesentral ligger? Hvor lett var dette i fra en skala fra1 til 5, hvor 1 er dårligst og 5 er best? 5. Finn kontakt informasjon for Norsk Regnesentrals IT-Leder. Hvor lett var dette i fra en skala fra1 til 5, hvor 1 er dårligst og 5 er best? 6. Finn et feeds innlegg. Hvor lett var dette i fra en skala fra1 til 5, hvor 1 er dårligst og 5 er best? 7. Abonner på Norsk Regnesentrals nyhetsbrev. Hvor lett var dette i fra en skala fra1 til 5 hvor 1 er dårligst og 5 er best? 8. Hva synes du om teksten som ble vist under de forskjellige emnene i fra en skala fra 1 til 5, hvor 1 er dårligst og 5 er best? 9. Hvor fornøyd er du med responstid på valgte emner i applikasjonen i fra en skal i fra 1 til 5 hvor, 1 er dårligst og 5 er best? 10. Ville du brukt applikasjonen? Side 87

88 4.1 Resultat av brukertest ios Under ser man resultatet av spørsmålene i brukertesten. Man ser at det ikke er så store forskjeller på de forskjellige svarene foruten på spørsmål åtte. Her ble det sagt at teksten på nyheter kunne vært større og lettere å lese. Det samme kommenterte de på blogg. Noen andre kommenterte at man skulle kunne lese dette på bred skjerm og at de synes det var verst å lese teksten her da denne var veldig liten. Noen ønsket å slippe å forstørre teksten og at denne automatisk skulle vise teksten i en behagelig størrelse. På spørsmål om brukeren ville brukt applikasjonen sa alle ja. Sp1 Sp2 Sp3 Sp4 Sp5 Sp6 Sp7 Sp8 Sp9 Pers Pers Pers Pers Pers Pers Pers Pers Side 88

89 4.2 Resultat av brukertest Android Under ser man resultatet av spørsmålene i brukertesten. Man ser at det ikke er så store forskjeller på de svarene som har blitt stil foruten på spørsmål tre og fem. Her ble det sagt at denne disse sidene kunne vært mer oversiktlig og lettere å lese. På spørsmål om brukeren ville brukt applikasjonen sa alle ja. Sp1 Sp2 Sp3 Sp4 Sp5 Sp6 Sp7 Sp8 Sp9 Pers Pers Pers Pers Pers Pers Pers Pers Side 89

90 5. Tilgjengelighetstest 5.1 ios Først testet vi hvordan Voice Over fungerte på en iphone 4 og simulatoren på Mac. Dette gjorde vi ved å sette på den innebygde funksjonen i innstillinger. Dette fungerte etter våre forventninger ved å lese tekst og innhold i applikasjonen. Den klarte å skille mellom funksjonell og vanlig statisktekst. 5.2 Android På Android testet vi dette i versjon ved å laste ned en applikasjon som heter Talkback. Vi brukte da denne applikasjonen med den vi har utviklet, men dette viste seg ikke å fungere. Grunnen til dette er fordi Androids Talkback er ufullstendig og trenger mer utvikling før dette kan fungere. Android 4 kommer med forbedringer når det gjelder tilgjengelighet. Side 90

91 Brukerhåndbok For Brukere av iphone Side 91

92 1. Forord Denne brukerdokumentasjonen er ment som et hjelpemiddel for brukerne av NRs applikasjon på en iphone. Man trenger ingen større IT-kompetanse for å kunne bruke å forstå dette dokumentet, men det er en rekke forutsetninger for å bruke disse som er beskrevet nedenfor. Dokumentet er ment for alle brukere av applikasjonen. Det er forutsatt at man har kunnskap om hvordan man laster ned applikasjoner fra AppStore. Det er nødvendig at brukeren har AppleID for å laste ned applikasjonen for iphone. Det er også forutsatt at man innehar en iphone. Det er også forventet at man er kjent med mobiltelefonens innstillinger for eventuelle endringer av språk. For at karttjenestene i applikasjonen skal fungere, er det forventet at man har stedstjenester i innstillinger slått på. Det er også forutsatt at man har internettforbindelse og at dette er tilgjengelig på mobiltelefonen i form av WIFI eller 3G. Side 92

93 2. Innholdsfortegnelse 1. Forord Innholdsfortegnelse Meny Språk Nyheter Om NR Kontakt NR Blogg Feeds Mail abonnering Kart Forstørre innhold Opplesning av innhold/voice over Side 93

94 Slik ser applikasjonen ut på telefonen når den er latet ned på mobiltelefonen. Side 94

95 3. Meny Under er det vist hvordan applikasjonen ser ut når du har kommet inn på den. Det første som vies er en meny med syv valgmuligheter. Applikasjonen er vist i norsk og engelsk. Her i fra kan man navigere seg fram til det emnet som er ønskelig avhengig av hva slags informasjon man er ute etter. Bilde 1. Bilde 2. Side 95

96 4. Språk På bildet under er det vist at man kan velge språk. Applikasjonen blir vist i det språket som mobiltelefonen er satt til i innstillinger. Side 96

97 5. Nyheter Under er det vist et bilde av hvordan innholdet i emnet, Nyheter ser ut. Her kan man holde seg oppdatert om prosjekter NR foretar seg, eller finne informasjon om seminarer og konferanser som NR arrangerer. Side 97

98 6. Om NR Under ser man et bilde av hvordan informasjonen Om NR ser ut på telefonen. Her finner man informasjon som samarbeidspartnere og generelt om bedriften. Side 98

99 7. Kontakt NR Under ser man tre bilder. Det første bildet viser hvordan kontaktinformasjonen til NR ser ut på telefonen. Her finner man telefonnumre og epostadresser til NR sine ansatte. På bilde nummer to, ser man at vi har lagt til rette at man kan ringe direkte fra applikasjonen. På bildet nummer tre, er det vist at det er mulig å sende epost. Bilde 1. Bilde 2. Bilde 3. Side 99

100 8. Blogg På bildet under ser man to bilder. Det første bildet viser hvordan innholdet i emnet blogg, ser ut på telefonen. Her vil det bli vist en rekke blogg innlegg. Ved å trykke på linken i bloggen, vil hele blogg siden vises. På bildet nummer to, er det vist at man kan forstørre bildet slik at teksten blir større og lettere å lese. Bilde 1. Bilde 2. Side 100

101 9. Feeds På bildet under ser man to bilder. Det første bildet viser innholdet i emnet feeds. Etter å ha trykket på ønsket feed, kommer man på en ny side hvor innholdet i den feeden du har valgt blir vist. Dette er vist i bildet nummer to. Bilde 1. Bilde 2. Side 101

102 10. Mail abonnering På bildet under ser man innholdet i emnet Mail Abonnering. Her kan man abonnere på NR sine nyhetsbrev. På bildet er det vist et tekstfelt hvor man skriver inn sin epostadresse. Man skriver inn sin epostadresse, sender den også får man en forespørsel i fra NR som ber om en bekreftelse på om du vil abonnere på nyhetsbrevet deres. Denne aksepteres hvis det er ønskelig. Side 102

103 11. Kart Under ser man fire bilder. Det første bildet viser en forespørsel i fra applikasjonen. NR må ha tillatelse i fra brukeren for å få og bruke informasjon om din posisjon. Når du har bekreftet dette, vises din posisjon på kartet. Hvis du ikke tillater applikasjonen informasjon om din posisjon vil bare NR sin posisjon vises som du kan se på bildet nummer to. På det tredje bildet er det vist av man har forstørret NR sin posisjon. Tillater man applikasjonen informasjon om din posisjon, vil man se hvor posisjonene til begge er i forhold til hverandre. Dette er vist på bilde nummer fire som en rød prikk og en blå. Den blå prikken er din posisjon. Bilde 1. Bilde 2. Bilde 3. Bilde 4. Side 103

104 12. Forstørre innhold Under er det vist et bilde. Bildet viser at man har forstørret innholdet i applikasjonen. Dette gjøres enkelt ved å trykke to ganger på skjermen og dra fingeren over det innholdet du vil ha forstørret. Side 104

105 13. Opplesning av innhold/voice over Det er lagt til rette at man kan bruke opplesning av innholdet på applikasjonen. Under ser man 3 bilder. Alle bildene viser at det innholdet som er markert blir lest opp. Dette gjøres ved å aktivere opplesning av innhold, i innstillinger på telefonen. Bilde 1. Bilde 2. Bilde 3. Side 105

106 Brukerhåndbok For brukere av Android mobiltelefoner Side 106

107 1. Forord Denne brukerdokumentasjonen er ment som et hjelpemiddel for brukerne av NRs applikasjon på Android. Man trenger ingen større IT-kompetanse for å kunne bruke å forstå dette dokumentet, men det er en rekke forutsetninger for å bruke applikasjonen. Disse er beskrevet nedenfor. Dokumentet er ment for alle brukere av applikasjonen. Det er forutsatt at man har kunnskap om hvordan man laster ned applikasjoner i fra Market. Det er nødvendig at brukeren har en gyldig e-postadresse for å laste ned applikasjonen for Android. Det er også forutsatt at man innehar en Android mobiltelefon. Det er også forventet at man er kjent med telefonens innstillinger for eventuelle endringer av språk. For at karttjenestene i applikasjonene skal fungere er det forventet at man har stedstjenester i innstillinger slått på. Det er også forutsatt at man har internettforbindelse og at dette er tilgjengelig for mobiltelefonen i form av WIFI eller 3G. Side 107

108 2. Innholdsfortegnelse 1. Forord Innholdsfortegnelse Språk Meny Nyheter Om NR Kontakt NR Blogg Feeds Mail abonnering Kart Side 108

109 3. Språk Under ser man 2 bilder. Den viser at Applikasjon i engelsk og norsk. Dette gjøres i telefonens innstilliger. Bilde 1. Bilde 2. Side 109

110 4. Meny Under er det er en illustrasjon av applikasjonens meny. Det er syv valgmuligheter som blir vist på menyen. Her i fra kan man navigere seg fram til det emnet som er ønskelig avhengig av hva slags informasjon man er ute etter. Side 110

111 5. Nyheter På det første bildet under ser man at informasjonen lastes ned i telefonen. På det andre bilde er det vist hvordan innholdet av nyheter ser ut. I dette emnet informeres du om prosjekter, informasjon om seminarer og konferanser som NR arrangerer. Bilde 1. Bilde 2. Side 111

112 6. Om NR I dette emnet finner man informasjon om NR. Under er det vist hvordan det ser ut på telefonen på engelsk og norsk. Bilde 1. Bilde 2. Side 112

113 7. Kontakt NR Her er det vist at man kan finne informasjon om adressen og kontaktpersoner på NR. Side 113