Kandidatnummer(e): Kristoffer Strøm Bergset (1709), Terje Nilsson Wallem, Johan Alexander de Lima Hessen

Transkript

1 Hovedprosjekt Tittel: D1304: Mobil-app til støtte av kurs og undervisning Kandidatnummer(e): Kristoffer Strøm Bergset (1709), Terje Nilsson Wallem, Johan Alexander de Lima Hessen Dato: Fagkode: Fagnavn: Dokument tilgang: ID Hovedprosjekt - Data og automasjon Studium: Ant sider/vedlegg: Bibl. nr: Bachelor i ingeniørfag - datateknikk 92 / 4 Veileder(e): Mikael Tollefsen Sammendrag: Dette prosjektet omhandler videreutviklingen av en e-læringsapplikasjon utviklet for Høgskolen i Ålesund i et tidligere prosjekt. Hensikten med e-læringsapplikasjonen er å være et støtteverktøy i undervisningen for både studenter og forelesere. E-læringsapplikasjonssystemet består av en mobilapplikasjon for Android enheter og en webapplikasjon laget for Java Enterprise Edition plattformen. Målet med dette prosjektet er å forbedre applikasjonen ved å gjøre den mer stabil og fleksibel. ønsker vi å integrere utvalgte funksjoner fra Fronter, BibSys og TimeEdit i applikasjonen. I tillegg Resultatet ble en stabil e-læringsapplikasjon hvor man kan legge til og fjerne innhold og funksjoner på en fleksibel måte. Den kan også søke etter bøker i skolens bibliotek, vise timeplanen for en gitt klasse eller fag, og fra Fronter kan den presentere meldinger fra lærere, vise tilgjengelige dokumenter og status på innleveringer. Denne rapporten inneholder en beskrivelse av hvilke teknologier som ble brukt, prosjekts fremgangsmåte, resultatet av prosjektet, brukerdokumentasjon for mobilapplikasjonen og webapplikasjonen, drøftingen av resultatet og konkluderer med at målene ble oppfylt. Denne oppgaven er en eksamensbesvarelse utført av studenter ved Høgskolen i Ålesund. Postadresse Høgskolen i Ålesund N-6025 Ålesund Norway Besøksadresse Larsgårdsvegen 2 Internett Telefon Epostadresse postmottak@hials.no Telefax Bankkonto Foretaksregisteret NO

2 Hovedprosjekt Side 2 INNHOLD 1 INNLEDNING 7 2 TEORETISK GRUNNLAG Arkitekturer, teknologier og konsepter Systemintegrasjon Robots.txt Model View Controller Web Services AJAX Programmering Java Regulære uttrykk og Java Java EE / EJB Bibliotek Programverktøy NetBeans GlassFish Git Android MATERIALER OG METODE Data Fronter TimeEdit BibSys Verktøy Materialer Smartelefon - Galaxy Nexus Tablet - Nexus Server Utviklingssyklus Framgangsmetode Fronter TimeEdit BIBSys Videreutvikling av applikasjonene Arbeidsprosessen RESULTATER Mobilapplikasjonen Sammenligning med det gamle systemet Git statistikk Installasjonsinstrukser

3 Hovedprosjekt Side Forklaring av brukergrensesnittet Serviceprossesen Datainnlasting Fragmenter/Moduler Webapplikasjonen Git statistikk Installasjonsinstrukser Administrasjonsgrensesnitt Modulært fragmentsystem ER modell REST tjenester Systemintegrasjon TimeEdit Lovlige hensyn Utvikling av løsning Integrering av TimeEdit i mobil-applikasjonen Fronter BibSys DRØFTING Systemintegrasjon Integrasjon i webapplikasjon vs mobilapplikasjon Fronter TimeEdit Webscraping Løsning BibSys Implementasjon av API Valg av struktur Mobilapplikasjonen Android app versus webapplikasjon i nettleser Webapplikasjonen Systemarkitekturen ER modellen Serversikkerhet Manglende eller ikke-implementert mulig funksjonalitet Gjenværende bugs Fremtid KONKLUSJON 84 7 REFERANSER Prosjektlinker A VEDLEGG 91

4 Hovedprosjekt Side 4 SAMMENDRAG Dette prosjektet omhandler videreutviklingen av en e-læringsapplikasjon utviklet for Høgskolen i Ålesund i et tidligere prosjekt. Hensikten med e-læringsapplikasjonen er å være et støtteverktøy i undervisningen for både studenter og forelesere. E-læringsapplikasjonssystemet består av en mobilapplikasjon for Android enheter og en webapplikasjon laget for Java Enterprise Edition plattformen. Målet med dette prosjektet er å forbedre applikasjonen ved å gjøre den mer stabil og fleksibel. I tillegg ønsker vi å integrere utvalgte funksjoner fra Fronter, BibSys og TimeEdit i applikasjonen. Resultatet ble en stabil e-læringsapplikasjon hvor man kan legge til og fjerne innhold og funksjoner på en fleksibel måte. Den kan også søke etter bøker i skolens bibliotek, vise timeplanen for en gitt klasse eller fag, og fra Fronter kan den presentere meldinger fra lærere, vise tilgjengelige dokumenter og status på innleveringer. Denne rapporten inneholder en beskrivelse av hvilke teknologier som ble brukt, prosjekts fremgangsmåte, resultatet av prosjektet, brukerdokumentasjon for mobilapplikasjonen og webapplikasjonen, drøftingen av resultatet og konkluderer med at målene ble oppfylt.

5 Hovedprosjekt Side 5 TERMINOLOGI Begreper Aktiviteter og Fragmenter - I Android er hvert skjermbilde bygd opp av en aktivitet og kan inneholde flere fragmenter. Aktiviteten styrer fragmentene og kan hente fram, vise disse og skjule dem igjen. Et fragment kan være ett helt skjermbilde eller bare en del av ett, så et skjermbilde kan være oppbygd av flere fragmenter. [ 1 ] I dette prosjektet brukes begrepet fragment også til å beskrive moduler med informasjon i webapplikasjonen og mobilapplikasjonen. Bug - Dette er en feil i kildekoden som resulterer i et uventet og ofte uønsket resultat. [ 2 ] Chen notasjon - Et sett med teknikker utviklet av Peter Chen for å lage entity-relationship modeller (ER modeller). [ 3 ] Commit - Dette begrepet refererer i sammenheng med denne rapporten til å bidra med kildekode til revisjonskontrollsystemet Git(se begrepet GitHub ). [ 4 ] E-læringsapplikasjon - Dette begrepet beskriver hele systemet som denne rapporten omhandler GET - En metode for å hente data over HTTP protokollen. [ 5 ] [ 6 ] GitHub - en gratis hostingtjeneste for prosjekter som bruker revisjonskontrollsystemet Git. Git brukes for å dele prosjektfiler mellom utviklere under produksjonen. For mer informasjon om Git se teoretisk grunnlag. GUI - Graphical User Interface, eller grafisk brukergrensesnitt er en betegnelse på en grafisk representasjon av data på en skjerm Mobilapplikasjon - Dette begrepet beskriver android applikasjonen som denne rapporten omhandler. VMWare vsphere cluster - Et virtualiseringsmiljø som kan inneholde mange virtuelle maskiner med forskjellige operativsystemer. [ 7 ] [ 8 ] Webapplikasjon - Dette begrepet beskriver serversiden av systemet som denne rapporten omhandler Serialisering - Konvertering av data fra objekter i minne til en bitstrøm som kan lagres i en fil eller sendes over et nettverk. [ 9 ] Sømløst grensesnitt - Dette beskriver et grensesnitt hvor to eller flere tjenester kommer sammen i et grensesnitt uten at det oppleves som man bruker forskjellige tjenester. [ 10 ] Web scraping - Dette er en teknikk for innhenting av data fra en nettside. Man henter ut dataene man vil ha ved å prosessere HTML-koden som vises på en nettside direkte. Med denne teknikken kan man hente ut data fra nesten hvilken som helst nettside. Ulempene med metoden er at den er treg å implementere, og er veldig sårbar for visuelle forandringer hos kildenettsiden. [ 11 ]

6 Hovedprosjekt Side 6 Web crawler - En web crawler er et program som systematisk går igjennom alle nettsider på Internett. Denne kan ha mange hensikter, men vanligvis er hensikten å indeksere sidene og er typisk for store søkemotorer som Google, Bing og Yahoo. [ 12 ] Forkortelser AJAX APK CSS DOM EJB ER GUI HTML Java EE JAX-RS JSF JSON JSP JVM NTNU POJO Regex REST SDK SRU URI URL WAR Asynchronous JavaScript and XML Android application package file Cascading Style Sheets Document Object Model Enterprise JavaBeans Entity Relationship Graphical User Interface HyperText Markup Language Java Enterprise Edition Java API for RESTful Web Services JavaServer Faces JavaScript Object Relation JavaServer Pages Java Virtual Machine Norges Teknisk-Naturvitenskapelige Universitet Plain Old Java Object Regular Expression Representational State Transfer Software Development Kit Search/Retrieval via URL Uniform resource identifier Uniform resource locator Web application ARchive

7 Hovedprosjekt Side 7 1 INNLEDNING Våren 2012 ble det startet et prosjekt for å lage en e-læringsapplikasjon for Android mobiltelefoner og en medfølgende webapplikasjon for å administrere innholdet i mobilapplikasjonen. Dette prosjektet var utviklet av elevene i faget ID Mobile og distribuerte applikasjoner [ 13 ] der Mikael Tollefsen var lærer og prosjektleder og Harald Yndestad var prosjekteier. Elevene i dette prosjektet var Kristoffer Strøm Bergset, Terje Nilsson Wallem, Johan Alexander de Lima Hessen og Lena Urkedal. Resultatet av dette prosjektet var en prototype av mobilapplikasjonen og webapplikasjonen med begrenset funksjonalitet. Bergset, Wallem og Hessen fikk tilbud av Tollefsen om å videreutvikle systemet høsten 2012 i et eget prosjekt. Som i det første prosjektet var Tollefsen prosjektleder og Yndestad prosjekteier. Dette prosjektet ble finansiert av studierådet etter en søknad om midler. Det ble avgjort at mobilapplikasjonen skulle utvikles fra bunnen igjen, basert på erfaringer gjort under utviklingen av prototypen. Hensikten med denne avgjørelsen var å utvikle en mer stabil og fleksibel løsning. Sluttproduktet fra dette prosjektet var en uferdig og ustabil versjon av mobilapplikasjonen og webapplikasjonen med det meste av basisfunksjonaliteten implementert. Da utviklingen av e-læringsapplikasjonen ikke ble ferdigstilt i de to tidligere prosjektene, ble det avgjort at utviklingen skulle fortsette som en del av hovedoppgaven til de tre prosjektdeltagerne/studentene. I tillegg skulle enkelte funksjoner fra skolens forskjellige datasystemer integreres i applikasjonen. Problemstillingene som dette prosjektet er ment å løse er da følgende: Det finnes ingen samlet tilgang til skolens mange separate IT løsninger Mobilapplikasjonen som ble utviklet høsten 2012 er ikke ferdig utviklet og ustabil Disse problemstillingene ønsker vi å løse ved å videreutvikle og lage en stabil og brukbar versjon av systemet. I tillegg ønsker vi å implementere noen av skolens egne datasystemer i mobilapplikasjonen. Systemene vi ønsker å integrere er studentsystemet Fronter, timeplansystemet TimeEdit og bibliotekdatabasen BibSys. Her følger en overordnet struktur over hvordan skolens systemer skal integreres.

8 Hovedprosjekt Side 8 Figur 1.1: Diagram som viser forholdet mellom mobilapplikasjonen, webapplikasjonen og Fronter, BibSys og TimeEdit Om man begynner fra toppen av illustrasjonen, har man de tre systemene fra skolen som skal implementeres. Serveren(midterste nivå av illustrasjonen) henter inn data fra disse tre tjenestene etter behov, og leverer dem til mobilapplikasjonen(nederste nivå av illustrasjonen) hvor de presenteres til brukeren. Målene som dette prosjektet ønsker å nå: Å fullføre utviklingen av den eksisterende e-læringsapplikasjonen Å gjøre den nye versjonen av e-læringsapplikasjonen mer fleksibel Å integrere utvalgte funksjoner fra de eksterne systemene TimeEdit, Fronter og BibSys i e-læringsapplikasjonen Denne rapporten beskriver teknologiene og materialene som ble brukt under prosjektet, hvordan det ble gått frem for å løse problemstillingene, drøfting av valg og alternative løsninger, løsningen som ble utviklet, og resultatet av prosjektet oppsummert i en konklusjon.

9 Hovedprosjekt Side 9 2 TEORETISK GRUNNLAG Denne seksjonen beskriver de viktigste begrepene, konseptene og teknologiene som er brukt som grunnlag for utvikling, gjøre vurderinger samt å beskrive metode og resultat i prosjektet. Noen av beskrivelsene vil også inneholde bilder eller kodeeksempler. 2.1 Arkitekturer, teknologier og konsepter Denne delen tar for seg de forskjellige teknologier, arkitekturmodeller og konsepter som er benyttet som designgrunnlag for prosjektet og er ellers omtalt i rapporten. Inndelingen av seksjoner er satt opp hierarkisk (dvs. at f.eks teknologier som tilhører en annen teknologi befinner seg i en underseksjon), og lineært oppbyggende. Det sistnevnte innebærer at den tidligere delen av seksjonen gir grunnlag for å enklere forstå senere deler Systemintegrasjon Definisjon Systemintegrasjon er å få to eller flere systemer til å samhandle. Det har også blitt definert som "å bringe subsystemer sammen i et system, og forsikre at subsystemene arbeider sammen i systemet" [ 14 ]. Systemintegrasjon kan gjennomføres ved å få de aktuelle systemene til å snakke med hverandre, det ene snakker til det andre(som en slags monolog). I situasjoner hvor det er mer enn to systemer kan det være en kombinasjon av de to løsningene. Det kan også forekomme at det mellom to(eller flere) systemer blir det implementert et tredje program som har som oppgave å koordinere de andre. I systemintegrasjon snakker man ofte om cohesion, eller grad av avhengigghet. Dette refererer til hvor mye de forskjellige subsystemene er avhengige av hverandre. Man ønsker å ha så lav cohesion som mulig samtidig som at systemet må kunne utføre de oppgavene som kreves av det. [ 15 ] I systemintegrasjon finnes det en del forskjellige måter for programmer å samhandle. Her følger en kort beskrivelse av de vanligste mekanismene: Data Scraping Data-scraping er en teknikk som involverer bruken av software-program til å hente ut spesifikk og meningsfull [ 16 ] [ 17 ] data fra et annet datasett formatert for å presentere menneskeleselig data. Begrepet menneskeleselig beskriver informasjon formatert på en måte beregnet for å kunne vises til og forstås av en sluttbruker. Dette innebærer ofte at den relevante informasjonen man søker er omsluttet av irrelevant eller redundant data, eller befinner seg uforutsigbart plassert i datasettet. Fordi datastrukturen dermed ikke egner seg for overføring av data mellom programmer, skiller data-scraping fra syntaktisk [ 18 ] data-analyse eller parsing som benytter seg av etablerte formateringsregler. Man kan si at data-scraping går ut på å gjøre ellers utilgjengelig data tilgjengelig for forståelse av programmer, eller å sette ustrukturert data i system. Web-scraping (se begreper) er en mer spesifikk teknikk innen data-scraping for å lokalisere og hente ut data fra nettsider som inneholder ustrukturert data. En nettside svarer typisk med data formatert som HTML,

10 Hovedprosjekt Side 10 og selve scraping-delen vil da bestå i å filtrere vekk unødvendig data, og plukke ut og sortere relevant data programmatisk. API Et API (Application Programming Interface) er et grensesnitt som gir eksterne brukere og applikasjoner tilgang til en annen applikasjons eller systems tjenester, funksjoner og data. [ 19 ] Ved bruk av API kan man bygge store modulære systemer. Dette vil også si at om man vil endre måten programmet fungerer på, så kan man det uten at det påvirker andre program som avhenger av det så lenge man beholder den samme API en. [ 20 ] Fil-dump baserte systemer Eldre datasystemer hadde ofte ikke tilgang på store mengder minne. Variabler og mellomlagring av data måtte derfor skrives til disk. Dette gjorde at om man ville hente inn data fra et fil-dump basert program, måtte man lese fra disse filene. Den største ulempen med denne metoden er at disk IO er veldig tregt i forhold til IO fra minne, så disse operasjonene var generelt ganske trege. Et annet problem var samtidighet mellom flere kilder når de vil lese og/eller skrive til/fra den samme kilden. Om et program skriver til en fil samtidig som et annet leser fra den, kan det oppstå feil. Dette er riktignok håndtert automatisk i nyere operativsystemer, men det kan fortsatt oppstå feil hvor et program ikke gir fra seg rettighetene til å lese/skrive til en fil. Selv om dette er en lite brukt måte å utvikle systemer på idag, finnes det fremdeles i bruk i bedriftsmarkedet Robots.txt Dette er en protokoll som brukes av nettsider til å fortelle nettjenester om de få lov til å innhente data automatisk. De vanligste tjenestene som bruker denne sjekken er søkemotorer(google, yahoo etc.), men den er aktuell for alt og alle som vil innhente data fra en nettside eller tjeneste. Protokollen kan forby tilgang til deler av sin egen mappestruktur, eller for å blokkere spesifikke tjenester(ofte blokkere søkemotorer). Det er viktig å merke seg at denne protokollen ikke aktivt blokkerer noe som helst, men fungerer som internettets trafikkskilt. Det vil si at protokollen ikke hindrer deg i å gjøre noe, men den viser om det er lov eller ikke.

11 Hovedprosjekt Side Model View Controller Figur 2.1: Model View Controller-modellen Model View Controller (MVC) er en arkitektur for programvare som begrenser hvilke deler av programmet brukeren interagerer med. "Model"-delen er kjernen i applikasjonen og består av dataen til applikasjonen (databasen), applikasjonslogikk, metoder og funksjoner. "View"-delen består av den informasjonen fra modelllaget som er tiltenkt brukeren som for eksempel tekst, bilde, lyd osv. "Controller" delen består av håndtering av brukerens input for å styre de to andre lagene. [ 21 ] Web Services En web service, eller nett-tjeneste, er en mekanisme som muligjør kommunikasjon eller tilbyr tilgang til funksjoner [ 22 ] over et nettverk [ 23 ]. Slike nett-tjenester bruker typisk HTTP/HTTPS over internett, og er dermed en form for distribuert system hvis tilhørende komponenter tilgjengelig for en bred rekke av enheter [ 24 ]. Det finnes [ 25 ] [ 26 ] flere typer nettjenester og kan deles grovt i to grupper, SOAP- og REST-baserte nett-tjenester. REST REST (Representational State Transfer) er en ikke-protokoll-spesifikk dataoverførings-arkitektur bestående av klienter og servere. Denne arkitekturen beskriver en del begrensinger som når benyttet i et distribuert system [ 27 ] fører til nyttige egenskaper som loose coupling og horisontal skalerbarhet. En typisk REST transaksjon kan beskrives på følgende måte; en klient sender en forespørsel til en server, som bearbeider forespørselen og sender tilbake data. Måten dette foregår på, metodene og standardene som benyttes er hva begrensningene definerer. Nettjenester som er designet i tråd med REST s arkitektur-prinsipper kalles "RESTful services". Grunnleggende arkitekturprinsipper i REST: Addressability Ethvert objekt or enhver ressurs i et system skal være tilgjengelig gjennom en unik identifikator. (URI) The Uniform, Constrained Interface Kun operasjoner som er definert innenfor protokollen tjenesten bruker er tillatt. Det skal med andre ord ikke opprettes egne funksjoner for handlinger i URI en. I eksempelvis HTTP begrenser man seg til

12 Hovedprosjekt Side 12 metodene som GET, PUT, DELETE, POST, etc... Formålet med dette er b.la å gjøre tjenesten lettere forståelig ved å bygge på eksisterende terminologi og funksjonalitet. Representation-Oriented En ressurs skal representeres i en dataoverføring tilbudt av en nett-tjeneste. En hent-operasjon skal gi tilbake en representasjon av ressursen, og en endrings-operasjon skal sende en representasjon av ressursen som skal endres. Stateless communication Det skal ikke lagres sesjonsdata på serveren. Serveren skal kun håndtere tilstanden til resursser som er tilbudt gjennom nett-tjenester. HATEOAS (Hypermedia As The Engine of Application Sate) Dataformatet skal styre tilstandsendringe i applikasjonen. Hvis det er nødvendig å begrense tilgang eller aksessere tjenesten på en spesiell måte, skal dette håndteres av hypermedia (f.eks en nettside) REST bruker API-ressurslinker (URI) for å aksessere resursser, eksempel på dette kan være: URL for å hente en kunde med ID 32133: 1 http : / / customers. myintranet. com/ customers /32133 URI-design En URI tjener som en identifikator til endepunkt i et system som tilbyr web-services. Defineringen og utformingen av disse URI ene har dermed mye å si for de som vil aksessere disse endepunktene, enten om de er programvareutviklere eller vanlige brukere. I et RESTful system vil en URI sørge for addressability-prinsippet, og en RESTful URI burde derfor følge arkitekturprinsippene så langt det er anvendbart. [ 28 ]

13 Hovedprosjekt Side 13 Dataformater Denne delen beskriver forskjellige dataformat som har blitt benyttet i prosjektet og er relevant ellers for denne rapporten. JSON JSON (JavaScript Object Notation) er et lettvekts dataformidlingsformat basert på delsyntaks fra JavaScript. Enkelheten i JSON ligger i at det er lettlest og lettskrevet av mennesker, noe som gjør jobbing med JSON til en relativt enkel oppgave sammenlignet med formater med lignende funksjonsområder. (b.l.a XML). I hovedsak er JSON basert på nøkkel/verdi-par og lister som har en nøkkelverdi som identifikasjon. Som nøkkelverdier bruker JSON strenger som demonstrert i figuren nedenfor: 1 { 3 day : "Man", date : "7 jan ", 5 l e c t u r e s : [ { 7 l e c t u r e S t a r t : " 0 8 : 1 5 ", lectureend : " 1 0 : 0 0 ", 9 type : " F o r e l e s ", c l a s s I d : "AU1, DA1, AU y1, DA y1", 11 room : " Borgundfjorden ", t e a c h e r s : "Blom Martin ", 13 comment : n u l l, c o u r s e s : [ 15 { coursename : " Fysikk og kjemi ", 17 courseid : n u l l } 19 ] ] 21 } Kodesnutt 2.1: (JSON-formatert data) Verdiene som er knyttet til en nøkkel kan være av følgende typer: Strenger Boolske verdier (true/false) Matriser Objekter (en liste med nøkkel/verdi-par) Null-verdier JSON blir ofte brukt til serialisering av data som skal sendes mellom server- og klientapplikasjoner. JSON [ 29 ] [ 30 ] [ 31 ] er plattform-uavhengig. XML XML er et dataformat som er ment å kunne leses både av mennesker og av maskiner. Mange nettjenester [ 32 ] [ 33 ] bruker formatet til å representere og strukturere svardata for deres API er.

14 Hovedprosjekt Side AJAX AJAX (Asynchronous JavaScript and XML) er en gruppe teknologier brukt til å lage asynkrone klientsidefunksjoner i webapplikasjoner. Dette vil si at med AJAX kan nettsider laste inn og sende data etter innlastingen av selve nettsiden, dette kan forenkle flyten i webgrensesnittet ved at brukeren kan gjøre endringer uten å måtte [ 34 ] [ 35 ] laste hele siden på nytt. 2.2 Programmering Denne delen tar for seg de forskjellige programspråkene og teknikkene som er benyttet i prosjektet Java Java er et objektorientert programmeringsspråk originalt utgitt av Sun Microsystems i Det er et språk hvor alt behandles som objekter, og hvor objektene kan samhandle for å utføre oppgaver. Språket er mest kjent for sin evne til å fungere på alle plattformer uten å måtte rekompilere koden. Dette prinsippet kalles Write Once, Run Anywhere(WORA), og det var Java som var først ute med denne løsningen. [ 36 ] Språket er utviklet med fem hovedmål [ 37 ] : Det skal være enkelt, objektsorientert og kjent(ligne på andre språk) Det skal være robust og sikkert Det skal være plattform uavhengig Det skal ha høy ytelse Det skal tolkes, genereres tråder og være dynamisk i sanntid Java brukes i dag til alt ifra til et bredt spekter av formål og til mange forskjellige typer enheter. Dette innebærer bruk som webtjenere(nettsider etc.), enkeltstående applikasjoner(normale programmer) og innebygde systemer(vaskemaskiner, kaffemaskiner etc.). Teknisk Java applikasjoner, eller programmer kjører på en virtuell maskin som heter Java Virtual Machine(JVM). Dette vil si at på toppen har man applikasjonen. Denne kjører på en virtuell maskin. Dette vil si at uansett hvilken fysisk maskin applikasjonen kjører på, vil alltid maskinen se lik ut for applikasjonen. Om det gjøres systemkall til operativsystemet, oversetter den virtuelle maskinen dette for applikasjonen. [ 38 ] Regulære uttrykk og Java Et regulært uttrykk (ofte forkortet "regex") er en streng med karakterer som utgjør et mønster, som igjen [ 39 ] beskriver eller matcher en eller flere strenger. Et slikt uttrykk brukes for å søke etter grupper av sammenhengende tekst, som da kan behandles på ønsket måte. Med unntak av spesielle karakterer, vil et regulært uttrykk beskrive en streng karakter for karakter, hvor f.eks det regulære uttrykket "regex" vil matche det første tilfellet av strengen "regex" i en annen tekststreng. De spesielle karakterene definert i syntaksen oversettes til en spesiell handling eller kan alene definere flere karakterer i en tekststreng. Syntaksen i et regulært uttrykk varierer med implementasjonen da programmeringspråk eller programmer som har støtte for regulære uttrykk benytter seg av forskjellige prosesserings-motorer, eller har sin helt egen variant

15 Hovedprosjekt Side 15 av konseptet. Til tross for dette, er likevel syntaksen svært lik hvis ikke helt identisk i de fleste tilfeller hvor de regulære uttrykkene baserer seg på Perl. Eksempelvis i Java er det noen slike forskjeller, som siden versjon 4 har støtte for regulære uttrykk vært tilbudt gjennom java.util.regex pakken, og baserer seg på Perl s implementasjon. Et regulært uttrykk i Perl kan være strengen "\\w", en spesiell karakter, som vil beskrive enhver streng med én bokstav, bindende punktuasjon eller ett tall. Java "\\w" Tabell 2.1: Sammenligner regex på Java og Perl Perl "\w" Rekkevidde [A-Za-z0-9_] uten Unicode Rekkevidde [A-Za-z0-9_] pluss Unicode Som figuren ovenfor illustrerer, vil Java s dobbel-sitering for strenger og bruk av bakvendt skråstrek for å definere spesialkarakterer gjøre det nødvendig med ekstra tegnsetting for å oppnå et ekvivalent regulært uttrykk. I tillegg mangler dette spesielle utrykket støtte for Unicode i Java, som også er en viktig forskjell med stor betydning for resultat Java EE / EJB Enterprise JavaBeans arkitekturen er designet for å lage komponent-baserte applikasjoner, der hver komponent kan representere en samling prosesser. Applikasjoner utviklet i Enteprise Java Beans arkitekturen er skalerbare og kan publiseres på alle webapplikasjon-plattformer som støtter Enterprise JavaBeans spesifikasjonen. [ 40 ] JavaServer Faces JavaServer Faces (JSF) er en teknologistandard for å bygge grafiske brukergrensesnitt i serversiden, JSF blir ofte brukt i Java EE webapplikasjoner. En JSP (JavaServer Pages) fil kan inneholde standard HTML kode og JSF templates eller moduler kalt Facelets. JSF komponentene kan gjengis forskjellig på forskjellige klientenheter. Formålet med JSF er å forenkle bygging av grafiske brukergrensesnitt for webapplikasjons-utviklere og å separere applikasjonslogikk og presentasjonslaget for modulær og teamvennlig utvikling. JSF gjør det også lettere for utviklere å kommunisere mellom applikasjonslogikken og presentasjonslaget. [ 41 ] Primefaces Primefaces er komponentbibliotek for JavaServer Faces som blir brukt til å lage dynamiske og funksjonsrike grafiske webgrensesnitt. Primefaces er lett å bruke, lett å implentere, har innebygd AJAX støtte og har åpen kildekode. [ 42 ] JAX-RS JAX-RS er et Java API for RESTful Web-services som har som mål å være enkelt og intuitivt. [ 43 ] API et ble formelt anmodet utviklet i 2007, og ferdigstilt neste år i 2008 av JCP (Java Community Process). Målsetningen som var satt ble oppnådd ved å bruke Java-annotasjoner istedenfor å kreve implementering av Java-interface klasser eller gjøre det nødvendig med flere konfigurasjonsfiler. Dette betyr at ressursklasser som bruker JAX-RS er regelrett POJO-klasser, som i seg selv fjerner behovet for flere base-klasser og gir økt modularitet i systemet. JAX-RS spesifikasjonen forhindrer på ingen måte bruk av grunnleggende java-teknikk som abstraksjon eller arv, og en JAX-RS støttet klasse kan benyttes på lik linje med ethvert POJO.

16 Hovedprosjekt Side 16 Annotasjonene i JAX-RS benyttes for å binde HTTP-metoder og spesifikke URI er til individuelle funksjoner i klassen, eller til og med hele java-klassen. I tillegg til dette har JAX-RS API et god støtte for marshalling og unmarshalling av egendefinerte dataobjekter til diverse dataformater, mapping av exceptions til HTTPresponskoder og svar, i tillegg til å kunne håndtere avansert HTTP-forhandling. Nedenfor er et eksempel på JAX-RS i en Java-klasse, med forskjellige Java-annotasjoner som reflekterer ( "/ r e s o u r c e " ) 2 p u b l i c c l a s s r e s o u r c e C l a s s { ( "/ o b j e c t /{ i d }" ) ({ MediaType. APPLICATION_JSON}) p u b l i c Response getobjectbyid ( " i d " ) S t r i n g i d ) { r e t u r n responseobjectbasedonmethodimplementation ; 12 ( "/ o b j e c t /" ) ({ MediaType. APPLICATION_JSON}) p u b l i c Response createnewobjectfromjson ( InputStream inputstream ) { r e t u r n responseobjectbasedonmethodimplementation ; 20 ( "/ o b j e c t /name/{name } : \\w{1,10} " ) ({ MediaType. APPLICATION_JSON}) p u b l i c Response getobjectfrom Name( InputStream inputstream ) { r e t u r n responseobjectbasedonmethodimplementation ; 28 } 30 } Kodesnutt 2.2: (Eksempel på REST-tjenester med JAX-RS) Kodesnutten ovenfor viser to metoder som begge er tilgjengelig via en URI som er definert i ovenfor klassen og metodene. er "id" en variabel som kan benyttes for å hente ut et spesifikt objekt. spesifiserer hvilken mediatype (her JSON) som skal produseres og tolkes respektivt. har også støtte for regulære uttrykk [ 44 ], som muligjør flere typer URI-matching. Den tredje funksjonen i figur (FIGUR HER) demonstrerer dette, hvor det regulære uttrykket \\w1,10 vil i Java matche enhver streng med sammenhengende karakterer med maksimal lengde 10. Dette gjør at man i praksis begrenser name-parameteren til 10 karakterer. Har nameparameteren en lengde på 11 eller mer, vil kun en 404-feil returneres. Fra endepunktet s perspektiv (den endelige URI en)kan også det JAX-RS definerer som matrise-elementer benyttes, som består av forhåndsdefinerte strenger (@MatrixParam) som etterfølger med ett semikolon (;). Denne funksjonaliten fører til økt fleksibilitet da man oppnår flere kombinasjoner

17 Hovedprosjekt Side Bibliotek Denne delen beskriver relevante tredjeparts støttebibliotek for Java. JSoup JSoup er et bibliotek for Java som blir brukt til å håndtere HTML kode fra nettsider i sanntid. Dette gjøres ved bruk av en relativt enkel API. JSoup henter ned koden fra en nettside, og så kan man navigere gjennom HTML koden for å hente ut den delen av koden man trenger. [ 45 ] Dette er en enkel metode å web-scrape en nettside. Ulempen med denne metoden er at man må vite nøyaktig hvordan kildekoden til nettsiden man er ute etter ser ut. Man kan for eksempel hente ut info som ligger mellom spesifikke HTML notasjoner, eller man kan hente ut data ved bruk av en spesiell id. En annen funksjon er å strippe vekk alle html notasjoner, slik at man står igjen med et rent dokument. [ 46 ] Figur 2.2: Et eksempel på hvordan man kan bruke JSoup RibbonMenu Ribbonmenu er et bibliotek for Android som brukes til å presentere data i en meny som kan "skli" inn fra siden av skjermen. Dette biblioteket etterligner den samme funksjonen som man finner i menyen på applikasjonene FaceBook og Google+. Fordelen med å bruke denne typen meny er at man har plass til mye informasjon og store ikoner i menyen, uten å bruke mye plass på skjermen når man ikke bruker den. En annen fordel er at den følger Google sine retningslinjer om komformitet i applikasjonsdesign. Det finnes et standard bibliotek fra Google med mye av den samme funksjonen, men denne var ikke tilgjengelig da utviklingen av applikasjonen startet. [ 47 ] Dette biblioteket heter Navigation Drawer.

18 Hovedprosjekt Side Programverktøy Denne delen av rapporten detaljerer de forskjellige programverktøyene som ble benyttet under utviklingen av prosjektet NetBeans NetBeans er et integrert utviklings miljø(integrated Development Environment) som brukes til å utvikle datasystemer. Netbeans er i stand til å ta seg av alle trinnene av utviklingen, som sjekk av syntaks, kompilering av kode og feilsøking av kode. I tillegg finnes det mange moduler som kan legges til som utvider funksjonaliteten. Netbeans blir hovedsakelig brukt til utvikling av Java, HTML5, PHP og C/C++, men kan brukes til andre språk også, avhengig av hvilke moduler som er installert. [ 48 ] GlassFish Glassfish er en applikasjonsserver for Java Enterprise Edition webapplikasjoner. Glassfish støtter alle Java Enterprise Edition teknologiene som: JavaServer Faces, JavaServer Pages, Enterprise JavaBeans osv. [ 49 ] Git Git er et distribuert versjonskontrollsystem for programvareutvikling. [ 50 ] Git er ideelt til teambasert programmering da det gjør det mye letter å slå sammen filer og endringer gjort av de individuelle teammedlemmene. Et Git prosjekt består av en mappe der alle endringer blir lagret som revisisjoner (commits). Disse revisjonene blir organisert med full historikk slik at bidragsyterene i prosjektet kan se hvem som har gjort hvilke endringer [ 51 ] [ 52 ] og "rulle tilbake" endringer som ikke er ønskelige Android Beskrivelse Android er et operativsystem hovedsaklig beregnet for mobile og små enheter med berøringsskjerm. Det er [ 53 ] verdens mest brukte operativsystem på mobile enheter, og er stadig i vekst. Mye av populariteten til [ 54 ] Android kommer av at det er tilgjengelig på et bredt utvalg av maskinvare og i alle prisklasser. For produsentene sin del er Android populært da det er hovedsakelig åpen kildekode [ 55 ] og dermed billig å levere med sine enheter. Mange av produsentene modifiserer også operativsystemet noe for å gjøre det til sitt eget, men dette er hovedsakelig grafiske forandringer. Android er populært hos utviklerene da det er et mer åpent operativsystem. Dette gjør at det er lettere å utvikle applikasjoner, og at de kan bli bedre integrert i den totale brukeropplevelsen ved telefonen. [ 56 ] Teknisk Android er basert på en åpen kildekode linux kjerne og er skrevet i C, C++ og Java. Alle applikasjoner som blir levert til Android er skrevet i Java og og bruker XML. Dette blir kompilert om for bruk i Android sin Dalvik virtual Machine(som er Android sin version av Java Virtual Machine). Android applikasjoner er bygd opp av to hovedkomponenter. Disse er såkalte "aktiviteter" [ 57 ] og "tjenester"(service) [ 58 ]. En aktivitet er den delen som vises på skjermen, og kjører kun så lenge den blir vist på skjermen. En typisk applikasjon består av flere aktiviteter hvor man kan navigere mellom disse. I tillegg kan hver aktivitet ha flere "fragmenter". Et fragment kan inneholde logikk og et grafisk grensesnitt, men må alltid

19 Hovedprosjekt Side 19 være en del av en aktivitet. Flere fragmenter kan kombineres for å lage en samling med forskjellige brukergrensesnitt i samme skjermbilde. [ 59 ] En tjeneste er en bakgrunnsprosess som kan kjøre selv om man bytter mellom aktiviteter. Tjenestene blir ofte brukt til ting som IO og mellomlagring av globale variabler.

20 Hovedprosjekt Side 20 3 MATERIALER OG METODE I denne seksjonen beskrives alt som ble brukt under utviklingen, og hvilke metoder som ble brukt til å løse hovedproblemstillingene, og for å styre gruppen. 3.1 Data Fronter Fronter er en kompleks læringsplattform for bruk på skoler. Den tilbyr en omfattende grunnpakke som elever og lærere kan bruke for å kommunisere og samarbeide om skolearbeid. Dette innebærer funksjoner som beskjeder fra lærere, tilgjengeliggjøring av dokumenter og læringsmateriell, innleveringer og prøver, og chat. Fronter tilbyr også en rekke utvidelsesmoduler for spesielle behov, som enkel bilderedigering, SMS og plagiatkontroll. [ 60 ] Fronter sin salgsmodell er en såkalt SaaS modell. Dette vil si at Fronter selger lisenser for bruk av sin programvare, men at de er vert for sine egne web servere. På denne måten trenger ikke kundene å drifte sine egne servere. Dette gjør fronter til et godt alternativ både for små og store institusjoner da det eneste som kreves av kunden er tilgang til en nettleser for sine brukere TimeEdit Timeplan administrasjonssystemet TimeEdit er et system brukt av store institusjoner for å administrere og allokere lokaler. Tjenesten tillater brukerne å se timeplanen for en person, klasse, studieretning eller lokale for et ønsket tidsintervall. Høgskolen I Ålesund bruker TimeEdit versjon [ 61 ] hvor alle tjenestens data lagres og administreres lokalt på skolens servere BibSys Biblioteksystemet BibSys er et arkiveringssystem for bøker og annen media relatert til driften av norske bibliotek. Systemet tillater brukere å søke etter, låne ut, levere inn og reservere bøker ved alle norske bibliotek tilknyttet systemet. Systemet er underlagt Kunskapsdepartementet, men blir administrert ved NTNU i Trondheim. [ 62 ] 3.2 Verktøy Alle gruppemedlemmene brukte Netbeans som IDE til programmeringen av både Android applikasjonen og Java EE webapplikasjonen. Til utviklingen av Android applikasjonen ble også det offisielle Android SDKet (Software Development Kit) brukt. For å få støtte til Android prosjekter i NetBeans brukte vi tredjeparts pluginen NBAndroid [ 63 ]. Glassfish Server Open Source Edition ble brukt som plattform for webapplikasjonen. Vi ønsket å bruke LaTeX til å skrive prosjektrapporten, men fant ingen prosjektmal fra skolen. Derfor utviklet vi vår egen mal basert på skolen eksisterende prosjektmaler i andre format. Denne malen ligger offentlig tilgjengelig på GitHub. [ 64 ]

21 Hovedprosjekt Side Materialer Smartelefon - Galaxy Nexus En av de to enhetene som ble brukt til å teste mobilapplikasjonen under utviklingen var smarttelefonen Galaxy Nexus, produsert av Samsung [ 65 ]. Denne modellen går også under modellnavnet GT-I9250. Gruppen hadde 3 slike telefoner til rådighet(en for hvert gruppemedlem). Telefonene kjørte under utviklingen Android versjon 4.2.1, kodenavn Jelly Bean Tablet - Nexus 7 Dette nettbrettet er et 7 tommers nettbrett produsert av Asus for Google. Det var helt nytt under produksjonsfasen, og tilbød veldig gode spesifikasjoner [ 66 ] til en fornuftig pris. Nettbrettet ble brukt til testing av applikasjonen for andre skjermstørrelser(sammenlignet med Galaxy Nexus), og for demonstrasjon. Nettbrettet kjørte Android versjon under utviklingen Server Prosjektet fikk tildelt en virtuell Ubuntu linux server på skolens VMWare vsphere cluster. På denne ble glassfish installert og webapplikasjonen publisert. Figur 3.1: Bilder av serveren

22 Hovedprosjekt Side Utviklingssyklus Under prosjektet tok gruppen utgangspunkt i SCRUM rammeverket, men det ble fort etablert en egentilpasset samarbeidsstil som passet til gruppen. Denne nye stilen innebærte bi-ukentlige statusmøter, daglige statusrapportering blant gruppemedlemmene dog ikke nødvendigvis ved starten av dagen og ikke like formelt som i SCRUM. For arbeidet i seg selv ble det brukt to online løsninger som gjorde det mulig å sammarbeide på det samme prosjektet samtidig. For programmeringen var det kildekode-delingstjenesten GitHub som ble brukt. Med denne tjenesten kunne alle gruppemedlemmene sitte med hver sin kopi av arbeidet, og når det ble gjort fremskritt ble dette sendt tilbake til serveren slik at den nye koden blir tilgjengelig for alle. For prosjektrapporten ble det brukt tekstbehandleren Google Docs. Denne gjør at alle gruppens medlemmer kan jobbe med det samme dokumentet samtidig, og se hva de andre skriver i sanntid. I tillegg har Google Docs innebygd chat funksjon og mulighet til å legge igjen kommentarer i teksten. Grunnen til at disse to tjenestene ble valgt var at alle gruppens medlemmer har god erfaring med dem, og at de tillater en stor grad av sammarbeid uavhengig om deltakerne fysisk befinner seg på samme sted. I sluttfasen av prosjektrapporten ble teksten fra Google Docs gjort om til LaTeX format for å kunne bedre kontrollere utseende til den endelige rapporten. 3.5 Framgangsmetode Denne delen av rapporten omhandler prosjektgruppens framgangsmetode for å løse hovedproblemstillingene Fronter Fronter er et lukket system og derfor måtte vi ha tilgang til APIet for å hente informasjon fra det. Informasjonen vi ønsket å hente var meldinger fra lærere, dokumenter og innleveringsstatus fra de individuelle rommene i Fronter-systemet. For å løse dette skulle mobilapplikasjonen gjøre relevante foresprsler mot en REST basert API på webapplikasjonen. Webapplikasjonen skulle så hente ut relevante data fra Fronter, og returnere det til mobilapplikasjonen, hvor de blir presentert til brukeren TimeEdit Vi ønsket å implementere en enkel utgave av skolens timeplansystem i e-læringsapplikasjonen. Det skulle være mulig å se dagens fag på en enkel måte. Planen var å skaffe tilgang til TimeEdit sitt API, og innhente data derifra via serveren vår ved hjelp av enkle spørringer basert på REST og JSON. Mobilapplikasjonen skulle altså kunne gjøre et kall mot serveren hvor den ba om informasjon om dagens timer/fag for et studieprogram, og så skulle serveren gjøre kallet videre til TimeEdit BIBSys Det kom tidlig frem at BiBSys hadde et API som var tilgjengelig til bruk for studenter og andre utviklere. Dette kunne man se fra antall student-utviklede applikasjoner ved NTNU. Utifra dette ville vi forsøke å få tilgang til APIen og implementere det i webapplikasjonen. Vi ønsket å implementere boksøk med utlånsstatus. Dette var en del av prosjektet vi forventet ville gå relativt raskt og uten problemer.

23 Hovedprosjekt Side Videreutvikling av applikasjonene I den forrige versjonen av systemet var strukturen hardkodet inn i mobilapplikasjonen. Vi ønsket å gjøre systemet mer fleksibelt slik at det kunne tilpasses de individuelle fagene og studienes behov for data. Vi ville at strukturen på mobilapplikasjonen skulle defineres for hvert objekt i webapplikasjonen Arbeidsprosessen Arbeidet i prosjektet skulle i utgangspunktet (ved prosjektstart) være styrt av aktivitetsplanen samt prosedyrer for avvik som ble definert i forprosjektsrapporten [ 67 ]. Diagrammet som følger beskriver den faktiske tidsfordelingen mellom de forskjellige delprosjektene. Figur 3.2: Dette Gantt diagrammet viser når de forskjellige deloppgavene i prosjektet ble utført Ved prosjektstart under den initielle planleggingsfasen (ref. Forprosjektsrapport [ 68 ] ) ble det klart at å først utvikle en stabil versjon av systemet var nødvendig, og dermed ble arbeid med både web-applikasjon og mobilapplikasjon prioritert først. Under videreutviklingen av systemet ble også ett sett med nye funksjoner inkludert, b.la et fragmentsystem (beskrevet i senere i rapporten) felles for mobil og web-applikasjon, samt nytt design for web-applikasjonens nettleser-grensesnitt. Det meste av arbeidet gjort her går likevel under stabilisering av applikasjonene ved å rette bugs og utbedre logisk flyt i systemet. Parallelt med dette startet vi også å undersøke tilgangsforholdene rundt de forskjellige tjenestene (TimeEdit, BibSys, Fronter) som vi skulle integrere i applikasjonen. Korrespondanse med leverandørene og eierene av datasystemene for å få tilgang til systemenes API tok lengre tid enn forventet, og det ble relativt tidlig (ca. uke 3) klart at vi måtte gå vekk fra den originale tidsplanen. Målsetningen med å ha utført prosessene A1-B2 går likevel i orden da innsamling av data så langt det var mulig og planlegging av arbeid videre ble gjort innenfor satt tidsfrist. TimeEdit blir prioritert under denne fasen da vi kunne starte forarbeidet umiddelbart med å forsøke alternative løsninger for innhenting av data, noe som også var innenfor det vi hadde forventet (ref. avvik forprosjektsraport). Milepæl #1 nås imidlertid ikke da undersøkings-delen (pkt.2 i figur 3.2) tok lengre tid enn forventet, og fra dette punktet av omorganiseres prosjektets framdriftsplan helt. Den nye prosjektorganiseringen var vellykket da det var tid som var den begrensende ressursen, og ikke arbeidskraft.

24 Hovedprosjekt Side 24 4 RESULTATER I denne seksjonen presenterer vi resultatet av prosjektet. Seksjonen er delt i tre deler, webapplikasjonsdelen hvor forandringene på serversiden blir presentert, mobilapplikasjonsdelen hvor forandringene i mobilapplikasjonen blir beskrevet og systemintegrasjonsdelen der vi presenterer løsningene til de integrerte systemene. Diagrammet under viser den overordnede strukturen til hele systemet som ble utviklet. Som man kan se er det et stort system med mange deler. Hver del er i seg selv bygd opp av mange komponenter som vil bli beskrevet i mer detalj senere i seksjonen. Det er verdt å merke seg at kildekoden til prosjektet består av over linjer med kode, så den følgende beskrivelsen vil hovedsakelig omhandle hvordan systemet gjennomfører oppgavene sine, og ikke nøyaktig hvordan koden fungerer. Figur 4.1: Oversikt over hele systemet

25 Hovedprosjekt Side Mobilapplikasjonen (a) På en mobiltelefon (b) På ett nettbrett Figur 4.2: Skjermbilder av mobilapplikasjonen - fremsiden Mobilapplikasjonene er laget for Android operativsystemet og bruker Android SDK versjon 14. Med unntak av slidingmeny funksjonen brukt i TimeEdit implementasjonen er all teknologien i applikasjonen inkludert i Android SDKet eller utviklet av prosjektmedlemmene. Med unntak av logoene til høgskolen, fronter og bibsys er ikonene til fragmentene hentet fra en åpen ikonpakke på nettet. Resten av grafikken er standard i Android SDKet. Endringer i mobilapplikasjonen fra forrige versjon (høsten 2012): Ikke lenger statiske fragmenter / data. I den forrige versjonen var alle fragmentene tilstede på alle sidene, selv om de ikke hadde innhold. Dette gjorde at alle lagen i applikasjonen så helt like ut og forvirret brukere. Full omskriving av metodene for innlasting av data. Bruker nå kun et GET (se begreper) kall for å laste ned et studie/fag/etc. I forrige versjon var det en GET kall for hvert fragment/side. Dette gjorde at datainnlastingen tok lengre tid. Full omskriving av JSON parsingen. I den tidligere versjonen var parsingen av objektene gjort i samme klasse som datainnlastingen. Nå har hver av dataklassene en konstruktør for JSON data og håndterer derfor parsingen selv. Dette har gjort det lettere å feilsøke parsingen og å legge til nye dataklasser.

26 Hovedprosjekt Side 26 Stabilitet. Bedre feilhåndtering og forenklet logikk har bidratt til å gjøre mobilapplikasjonen mye mer stabil. Integrasjon av de eksterne tjenestene TimeEdit og BibSys. Mer om dette senere i rapporten. Figur 4.3: Viser objektene på hvert lag i mobilapplikasjonen og flyten mellom lagene Mobilapplikasjonen er delt inn i tre lag. Lag 1 er fremsiden av applikasjonen og det første brukeren ser når applikasjonen startes. Her vises fragmentene som er knyttet til fremside objektet på webapplikasjonen som ikoner. På dette laget er det meningen å ha informasjon relatert til skolen i seg selv, for eksempel en spørreundersøkelses quiz eller nyheter om skolen. Når brukerene trykker på et av ikonene åpnes dette fragmentet og viser dets innhold. Får å komme tilbake til fragmentoversikten kan brukeren trykk på back knappen i android eller bruke rullegardin-menyen øverst i skjermbildet. Systemet kan bare ha en fremside. Når brukeren velger et studie fra studieliste-fragmentet går applikasjonen ned til neste lag. Lag 2 er studielaget, som på fremsiden vises fragmentene som er knyttet til studie i webapplikasjonen. Når brukeren velger et fag fra fagliste-fragmentet går applikasjonen videre til det siste laget. Lag 3 er faglaget, som de andre lagene inneholder dette laget fragmenter definert av webapplikasjonen. Fag-laget inneholder i tillegg ekstra datafelt for eksamener, innleveringer og tema med oppgaver.

27 Hovedprosjekt Side 27 Grunnen til at denne strukturen ble valgt er at den ble spesifisert av kunden da systemet ble bestilt i Kravspesifikasjonen hvor strukturen ble beskrevet ble fremlagt og produsert av Harald Yndestad. Denne kravspesifikasjonen spesifiserte systemet som ble utviklet opp til starten av dette prosjektet Sammenligning med det gamle systemet Figur 4.4: Viser flyten i det gamle systemet I det gamle systemet hadde alle objektene på alle lagene de samme sidene. På fremsiden måtte ressurslinkene til informasjonen på serveren hardkodes inn i mobilapplikasjonen og kompileres hver gang det skulle gjøres en endring. Dette gjorde det gamle systemet veldig tungvint å vedlikeholde og gjorde systemet veldig sårbart mot systemkrasj om ressurser på serveren ble slettet. På lagene under (studier og fag) var informasjonen lagret som attributter i lag-objektet. Det vil si at hvert lag måtte ha en og bare en av hvert type dataobjekt (artikkel,

28 Hovedprosjekt Side 28 videoer osv). Om lag-objektet manglet en ressurslink for et objekt eller linken til ressursen var ugyldig krasjet applikasjonen Git statistikk Statistikk for endringer i mobilapplikasjonens github repository siden prosjektstart: Antall commits: 60 Antall linjer lagt til: 5513 Antall linjer slettet: 7474 Totalt antall linjer alle filer: Totalt antall linjer - Java kode: 8625 Totalt antall linjer - XML: Installasjonsinstrukser For å installere mobilapplikasjonen på mobiltelefonen eller nettbrettet ditt trenger du minst versjon 4.0 (Ice Cream Sandwich) av Android operativsystemet. Siden applikasjonen ikke er tilgjengelig på Google Play butikken må den installeres manuelt, for å gjøre dette må du først tillate installering av eksterne applikasjoner gå inn på innstillinger -> sikkerhet og skru på ukjente kilder. Etter det er det bare å åpne den kompilerte.apk filen i prosjektmappen (Muldvarp/bin/Muldvarp-Debug.apk). Denne filen er også linket til på fremsiden av webapplikasjonen.

29 Hovedprosjekt Side Forklaring av brukergrensesnittet Figur 4.5: Forklaring for brukergrensesnittet 1. Knapp for å få fram sidemenyen. Sidemenyen inneholder timeplan funksjonen. 2. Tittelen på fragmentetsiden du er på nå. Trykk her for å få opp en rullegardin-meny der du kan navigere til de andre fragmentene i laget. 3. Søkeknapp. Trykk her når du er i en liste for å filtrere listen med søkeordet ditt. 4. Oppdateringsknapp / Refresh. Oppdaterer og laster ned informasjonen om siden du er på nå på nytt. 5. Diverse. Her finner du innloggingsknappen (ikke ferdig implementert) og en om oss knapp som popper opp et vindu med diverse informasjon om høgskolen som for eksempel postaddresse. 6. Tittelen på laget du befinner deg på. I dette tilfellet fremsiden. Når du er på studie eller fag nivået vises navnet til studiet / faget. 7. Fragmentene på laget. Trykk på ett fragment for å navigere til den siden. 8. Informasjon om applikasjonsversjonen og når dataen for laget du befinner deg på sist ble lastet inn. 9. Tilbake-knapp. Standard i Android operativsystemet. Trykk her når du er på fragmentoversikten for å bevege deg opp et lag, trykk på knappen når du befinner deg i en fragmentside for å gå tilbake til fragmentoversikten. 10. Hjem-knapp. Standard i Android operativsystemet. Trykk her for å ut av applikasjonen. Applikasjonen lukkes ikke men legges i bakgrunnen. 11. Applikasjonsvelger-knapp. Standard i Android operativsystemet. Trykk her for å velge applikasjoner som kjører i bakgrunnen.

30 Hovedprosjekt Side Serviceprossesen Serviceprossesen er en egen prosses som kjører parallelt med applikasjonens hovedprosses. Den har ansvar for å hente data fra serveren, parse dataen og lagre dataobjektene i minne Datainnlasting Mobilapplikasjonen laster inn data fra webapplikasjonen via REST tjenestene på serveren. Tjenestene leverer dataen i JSON format som blir parset og lagret i minnet av serviceprosessen. Figur 4.6: Viser flyten mellom webapplikasjonen og mobilapplikasjonen Først lager hovedprosessen en tilkobling til serviceprosessen og sender en førespørsel om dataen den trenger. Så laster serviceprosessen ned og parser dataene hovedprosessen forespurte. Når informasjon er ferdig parset av serviceprosessen, sender den en melding til hovedprosessen om at informasjon er klar til bruk. Deretter henter hovedprosessen informasjonen fra serviceprosessen og gjør den tilgjengelig for bruk av fragmentene. For eksempel så vil første innlasting av data til mobilapplikasjonen bestå av kall til frontpage for å få fragmentene til fremsiden, programme for å hente en liste av alle studiene, articles/news for å få nyhetene og timeedit/<klasseid> for å hente brukerens timeplan. Senere vil mobilapplikasjonen sende førespørsler etter mer data etter behov. Se seksjonen om webapplikasjonen i resultatdelen for nærmere oversikt over de forskjellige tjeneste-kallene Fragmenter/Moduler Mobilapplikasjonen er bygd opp av flere lag der hvert lag har flere fragmenter (se begreper) eller sider med forskjellig informasjon. Disse fragmentene styres av laget (aktiviteten, se begreper) som henter frem og viser fragmenter etter behov. Hvilke fragmenter som er på hvilket lag og objekt er definert av webapplikasjonen. Her er en oversikt over de forskjellige typene fragmenter. Lister Store deler av applikasjonens sider består av lister over andre objekter. Disse listene kan inneholde alle de forskjellige dataobjekt typene. I disse listene kan brukerene filtrere listen med et søkeord med forstørrelsesglass knappen i toppmenyen

31 Hovedprosjekt Side 31 Artikkel / Nyheter (a) Liste med nyheter (b) En artikkel Figur 4.7: Skjermbilder av mobilapplikasjonen - artikkel-funksjonen Artikkel fragmentet viser en HTML side fra webapplikasjonen i et standard WebView i Android. Nyhetsfragmentet viser en liste med artikler fra valgt kategori, når du velger en får du samme visning som artikkel fragmentet.

32 Hovedprosjekt Side 32 Studier / Fag (a) En liste med studier filtrert med søkeordet "data" (b) Startsiden til studie-laget Figur 4.8: Skjermbilder av mobilapplikasjonen - studie/fag-funksjonen Viser en liste over alle studier / fag i valgte studie. Når du velger et studie eller fag går du ned et lag til det valgte studie / faget. Her vises studielisten filtrert med søkeordet data og fremsiden til det valgte objektet i studielaget.

33 Hovedprosjekt Side 33 Dokumenter (a) Detaljesiden til et dokument (b) Et dokument Figur 4.9: Skjermbilder av mobilapplikasjonen - dokument-funksjonen Inneholder en liste over alle dokumentene knyttet til fragmentet. Når klikker på et dokument i listen får du opp en oversiktsside med informasjon om det valgte dokumentet. Trykk på Open for å åpne dokumentet i mobilen/nettbrettets standard dokumentvisnings-applikasjon. Trykk Download for å laste ned filen til mobilen/nettbrettes standard nettlastingsmappe

34 Hovedprosjekt Side 34 Video (a) Videoliste (b) Åpnet YouTube-video Figur 4.10: Skjermbilder av mobilapplikasjonen - video-funksjonen Video fragmentet inneholder en liste av alle videoer knyttet til fragmentet. videoprogrammet på mobilen, i dette tilfellet YouTube Når du velger en video åpner

35 Hovedprosjekt Side 35 Quiz Quiz-seksjonen av mobil-applikasjonen tilbyr quizzer eller andre type spørringer til brukerene. Av de forskjellige typene er kun de som ikke kommuniserer svar tilbake til server implementert grunnet mangel av sentralt brukersystem. Quiz-fragmentet som tilgjengelig fra hovedsiden inneholder en liste over quizzer som er knyttet til hovedsiden s lagtype - fag, kurs eller genere (a) Startsiden til en quiz (b) Et dokument Figur 4.11: Skjermbilder av mobilapplikasjonen - quiz-funksjonen Etter å ha valgt en quiz får du opp startskjermen med informasjon om quizzen. Her står det en kort beskrivelse av innholdet, og antall spørsmål quizzen inneholder. Quizzen startes herfra ved å trykke på Start Quiz!. Oppgavene eller spørsmålene kan være flervalgs eller enkeltvalgs-typer, og advarsler vil komme opp dersom ingen alternativ er valgt. Navigasjon mellom alle spørsmålene er også mulig, og ved siste vil man å en advarsel om at er i ferd med å avslutte Quizzen og gå til resultatskjermen. Man er også i stand til å avslutte Quizzen når som helst, og dette vil forkaste alle svar.

36 Hovedprosjekt Side 36 (a) Viser dine svar (b) Viser korrekte svar (c) Oppsummering Figur 4.12: Skjermbilder av mobilapplikasjonen - quiz-funksjonen Etter man har svart på alle spørsmålene kommer man til en oppsummeringsside. Her vises ett sammendrag av alle spørsmålene og hvilke alternativer som ble valgt. Ved å trykke på se fasit knappen nederst på siden får man opp de riktige alternativene, som viser hvilke svar du har valgt og om de er riktige eller gale. Kjent fargekoding forklarer visuelt gale/riktige svar. Videre kan man trykke oppsummeringsknappen for å se en opptelling riktige svar mot hvor mange som var mulig å få riktig, og eventuelt en vurdering

37 Hovedprosjekt Side Webapplikasjonen Figur 4.13: Oversikt over webapplikasjonen Webapplikasjonen er laget på Java Enterprise Edition 6 plattformen. Arkitekturen er basert på Model View Controller-modellen, men avviker noe fra modellen (mer om dette senere i rapporten). Webapplikasjonen har en nettsidefrontend for administrasjon og et sett med REST tjenester for å gjøre dataen lett tilgjengelig for eksterne applikasjoner som mobilapplikasjonen. I dette prosjektet publiserte vi webapplikasjonen på en GlassFish Open Source Edition server, men den kan også publiseres på andre webapplikasjonsservere som støtter Java Enterprise Edition 6 webapplikasjoner. Teknologier brukt i webapplikasjonen: Java Enterprise Beans - Plattformen webapplikasjonen er utviklet på. JavaServer Faces - Brukt til frontenden/nettsiden. PrimeFaces - Komponentbibliotek til JavaServer Faces. Brukt til redigeringssidene og navigasjonssystemet i frontenden. JSoup - Brukt til parsing av HTML og XML i TimeEdit og BibSys implementasjon REST - Brukt til å eksponere data (API) til mobilapplikasjonen JSON - Brukt som dataformat i REST tjenestene For mer informasjon om teknologiene, se teoretisk grunnlag.

38 Hovedprosjekt Side 38 Endringer i webapplikasjonen siden forrige versjon (høsten 2012) Dynamisk fragment system. Nå defineres fragmentene på mobilapplikasjonssiden i webapplikasjonen. Dette står for den største delen av oppgraderingen i den nye versjonen. Stabilitet og feilfiksing. Den forrige versjonen var full av krasjbugs og feil i relasjonsdatabasen. Mye arbeid ble gjort for å finne og fikse feilene. For mer informasjon om relasjonsdatabasefeilene se seksjonen om drøfting. Grafisk oppussing. Laget ny template og css stil. Samkjørt grafikken med mobilapplikasjonen. Laget ny fremside, med presentasjon av applikasjonens funksjoner og nedlastingslink til mobilapplikasjonen. Skrevet om redigeringssidene. Redigeringssidene for lagobjektene er helt skrevet om for å bruke det nye fragmentsystemet. Laget dokumentasjonsider Git statistikk Statistikk for endringer i webapplikasjonens github repository siden prosjektstart: Antall commits: 101 Antall linjer lagt til: Antall linjer slettet: 9963 Totalt antall linjer Totalt antall linjer Java-kode: 8167 Totalt antall linjer xhtml / jsf: Installasjonsinstrukser Webapplikasjonen kompileres til en.war fil. Denne filen kan publiseres på flere typer webapplikasjonsservere. I vårt prosjekt brukte vi GlassFish Open Source Edition som vår webapplikasjonsplattform, derfor er disse instruksjonene kun for GlassFish. Sette opp databasen: 1. Trykk på Resources i venstremenyen 2. Trykk på JDBC Connection Pools 3. Trykk New 4. I feltet Pool Name skriv MuldvarpPool 5. Under Resource Type velg javax.sql.datasource 6. Under Database Driver Vendor velg JavaDB 7. Trykk Next 8. Under Additional Properties i bunnen av siden fyll inn feltene som vist på bildet

39 Hovedprosjekt Side Trykk Finish 10. Gå til JDBC Resources i venstremenyen 11. Trykk New 12. I feltet JNDI Name skriv jdbc/muldvarp 13. Under Pool Name velg MuldvarpPool 14. Trykk OK Sette opp administratorbruker Figur 4.14: JDBC innstillinger Webapplikasjonen bruker også security-constraint funksjonen i Java EE for å begrense tilgang til sidene i /admin/ mappen. For å konfigurere administratorbrukeren: 1. Trykk på server-config under Configurations i venstremenyen 2. Under Security velg Realms og så file 3. Skriv inn Admin i feltet Assign Groups 4. Trykk Save 5. Trykk på Manage Users 6. Trykk New for å legge til en ny bruker Figur 4.15: Viser hvor file realm er

40 Hovedprosjekt Side Skriv Admin i feltene User ID og Group List 8. Skriv inn valgfritt passord 9. Trykk Save Publiser applikasjonen 1. Gå til Applications i venstremenyen 2. Trykk Deploy 3. Under Packaged File to Be Uploaded to the Server trykk velg fil og velg.war filen (MuldvarpWeb/target/MuldvarpWeb-1.1-TEST.war) 4. Under Context Root skriv hials (Dette blir adressen til webapplikasjonen) 5. Om applikasjonen allerede er publisert kryss av på Force Redeploy for å overskrive den 6. Trykk OK Applikasjonen er nå klar til bruk og kan nås med adressen Om glassfish ikke kjører på port 80 må du legge til portnummeret i adressen (eg. Sett webapplikasjonen til standardapplikasjon For at webapplikasjonen skal visest i rot-adressen (eg. webapplikasjonen som standardapplikasjon eapp.uials.no) må du gjøre følgende steg for å sette 1. Trykk på server-config under Configurations i venstremenyen 2. Trykk på Virtual Servers 3. Trykk på server 4. Under Default Web Module velg MuldvarpWeb-1.1-TEST 5. Trykk Save Nå er webapplikasjonen tilgjengelig på rot-adressen til serveren Administrasjonsgrensesnitt Administrasjonsgrensesnittet er utviklet i JavaServer Faces og bruker spesielt funksjoner og komponenter fra Primefaces biblioteket. Grensesnittet er delt inn i flere faner, en fane for hvert type objekt i systemet

41 Hovedprosjekt Side 41 Fremside Figur 4.16: Skjermbilde av webapplikasjonen - Viser framside-redigeringssiden Her kan tittelen og hvilke fragmenter som skal vises på fremsiden av mobilapplikasjonen styres. Her får også administratoren en forhåndsvisning av hvordan dette vil se ut på mobilapplikasjonen.

42 Hovedprosjekt Side 42 Studier Figur 4.17: Skjermbilde av webapplikasjonen - Viser listen over studier Her vises en liste over alle studier i systemet. Her kan nye studier opprettes og eksisterende studier redigeres. Figur 4.18: Skjermbilde av webapplikasjonen - Studie-redigeringssiden Redigeringssiden for studier. Her kan studiets navn og brødtekst defineres. Resten av siden er delt inn i tre seksjoner

43 Hovedprosjekt Side 43 Figur 4.19: Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Studiebeskrivelse I studie beskrivelsesseksjonen kan mer detaljert tekst om studiet skrives inn. Figur 4.20: Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Valg av fag Her velger administratoren hvilke fag som er i studiet.

44 Hovedprosjekt Side 44 Fag Figur 4.21: Skjermbilde av webapplikasjonen - Studie-redigeringssiden - Fragmenter Her velges fragmentene som skal visest for det valgte studiet i mobilapplikasjonen. Figur 4.22: Skjermbilde av webapplikasjonen - Fag-redigeringssiden Redigeringssiden for fag. Her defineres fagets navn, brødtekst og bilde. Her visest også hvilke studier faget tilhører. Resten av siden er delt inn i underkategorier der fagets tema og oppgaver, obligatoriske innleveringer,

45 Hovedprosjekt Side 45 eksamener og hvilke fragmenter som skal vises på mobilapplikasjonen defineres. Dokumenter Som i de andre fanene vises først alle dokumentene i systemet i en liste. Figur 4.23: Skjermbilde av webapplikasjonen - Dokument-redigeringssiden Redigeringssiden for dokumenter. Her legges inn navnet til dokumentet, URL eller lenke til dokumentet (i denne versjonen av systemet er ikke filopplasting / lagring støttet, derfor må filene lastes opp til en annen server/tjeneste og linkes til) og en liten tekstbeskrivelse av dokumentet.

46 Hovedprosjekt Side 46 Quizzer Som vanlig vises først en liste over alle quizzen i systemet. Figur 4.24: Skjermbilde av webapplikasjonen - Quiz-redigeringssiden Redigeringssiden til en quiz. Her defineres quizzens tittel, type, en kort beskrivelse og spørsmålene med alternativer. Typene quiz er feedback, remote, remote med feedback og guide. Meningen med disse forskjellig typene er som følge Tabell 4.1: Viser de forskjellige quiz typene Quiztype Feedback Remote Remote med feedback Guide Mening Brukeren får vite resultatet på quizzen Brukeren får ikke vite resultatet på quizzen, men det blir sendt til læreren/forelesere Brukeren får vite resultatet på quizzen, og resultatet blir sendt til læreren/forelesere Her avhenger hvert spørsmål av det forrige. På denne måten kan man dirigere brukeren mot for eksempel riktig studieretning etc Av disse typene er det kun feedback som er ferdig implementert grunnet tidshensyn. De andre typene ligger der da de er delvis implementert og kan gjøres ferdig i fremtide

47 Hovedprosjekt Side 47 Figur 4.25: Skjermbilde av webapplikasjonen - Quiz-redigeringssiden - Spørsmål Redigeringssiden til et valgt spørsmål. Her kan administratoren legge til alternativer og velge hvilke som er riktig svar. Videoer Først vises en liste over alle videoene i systemet. Figur 4.26: Skjermbilde av webapplikasjonen - Video-redigeringssiden

48 Hovedprosjekt Side 48 Redigeringssiden for videoer. Her legges inn / redigeres navnet til videoen, typen (youtube eller videofil), URL / link til videoen, brødtekst, beskrivelse, URL til bildefil for videoens ikon i mobilapplikasjonens listevisning og et thumbnail bilde Artikler Som vanlig vises en liste over alle artiklene i systemet. Figur 4.27: Skjermbilde av webapplikasjonen - Artikkel-redigeringssiden Redigeringssiden for artikler. Her legges inn / redigeres artikkelens tittel, forfatter, kategori (brukt til å sortere artikler for nyhetsfunksjonen), dato, beskrivelse, ingresstekst og selve artikkelen. Artikkelens tekst bruker en WYSIWYG editor og lagrer artikkelen i HTML format. Administratoren kan også legge inn egendefinerte HTML kode. Stien til artikkel siden er: server.no/faces/article.xhtml?articleid=<id> der <ID> er artikkelens interne I

49 Hovedprosjekt Side 49 Brukere Viser en liste over brukerene i systemet. Figur 4.28: Skjermbilde av webapplikasjonen - Bruker-redigeringssiden Redigeringssiden for brukere. Her fylles inn diverse informasjon om brukeren. I denne versjonen av applikasjonen har brukersystemet ingen funksjon. Brukerfunksjonen var planlagt som både et brukersystem med rettigheter og eierskap av objekter i systemet, og som et oppslagsverk for lærere / ansatte i skolen for skolens eleve

50 Hovedprosjekt Side 50 Dokumentasjon Figur 4.29: Skjermbilde av webapplikasjonen - Dokumentasjon Hjelpeside for webapplikasjonen. Her finnes instruksjoner for bruk av de forskjellige delene av administrasjonsgrensesnittet Modulært fragmentsystem I tidligere versjoner av mobilapplikasjonen var fragmentene (se begreper) eller sidene på hvert lag statisk programmert inn i mobilapplikasjonen. I dette systemet hadde alle objektene på et lag (fremside, studieretninger, fag) de samme sidene, en av hvert type fragment. Det var ikke alle tilfellene dette passet med objektets tilgjengelige informasjon, og derfor ble det besluttet at sidene på hvert objekt skulle bli styrt av webapplikasjonen. Med det nye systemet kan administratorene definere nøyaktig hva som skal vises på mobilapplikasjonen. Dette systemet var også laget for å kunne lett utvides med nye moduler. Se kapittelet om mobilapplikasjonen for oversikt over de forskjellige fragmentene

51 Hovedprosjekt Side ER modell Figur 4.30: Entity Relationship diagram ER modellen er bygd opp med det logiske lagene på topp (fremside, studier, fag) der hver av disse inneholder dynamiske fragmenter, som igjen inneholder data objektene (artikler, dokumenter, videoer osv). Topplagene er knyttet til fragmenter via one to many relasjon som betyr at for eksempel et studie har flere unike fragmenter. Fragmentene er knyttet til data objektene med many to many relasjon. Dette vil si at for eksempel flere fragmenter kan være knyttet til de samme videoene og omvendt. I det gamle systemet hadde hvert av lagene (fremside, studie, fag) relasjoner direkte til dataobjektene. Det vil si at hvert lag hadde en instans av hvert fragment. Med det nye fragmentsystemet kan hvert lag ha flere instanser av samme type fragment REST tjenester For at eksterne applikasjoner som mobilapplikasjonen skal kunne bruke dataen i systemet har vi et sett med RESTful tjenester. Disse leverer begrenset informasjon basert på hva klientapplikasjonen spør om. Her er en oversikt over hvilke tjenester som er i bruk av denne versjonen av applikasjonen.

52 Hovedprosjekt Side 52 Tabell 4.2: Viser de tilgjengelige REST tjenestene URL/Forespørsel (domene.no/services/ + frontpage programme programme/<id> articles/news course/<id> article/<id> timeedit/coursecode/<kode> timeedit/classcode/<kode> bibsys/<søkeord> fronter/room/<id> Data / respons Henter fremsiden Henter alle studier Henter studiet med valgt ID Henter artikler med kategori news Henter kurset med valgt ID Henter artikkel med valgt ID Henter timeplanen for valgt fagkode (eks ID102012) Henter timeplanen til valgte klasse (eks DA1) Finner alle bøker som matcher søkeordet Hente data fra fronter rom med ID (siden fronter implementasjonen ikke ble fullført returnerer dette bare dummy data) 4.3 Systemintegrasjon TimeEdit Den første oppgaven ved integreringen av TimeEdit var å bestemme hvilke av tjenestene som TimeEdit tilbyr var nyttig for applikasjonen s bruksområde. TimeEdit som implementert av HIALS tilbyr bla. Booking av rom. [ 69 ] Krever HIALS brukernavn/passord Timeplan over planlagte forelesninger [ 70 ]....basert på : Studieløp Enkeltfag Forelesere Rom Hovedfokuset i applikasjonen er sentrert rundt studier og enkelt-fag, og dermed er den mest relevante tjenesten oppslag på nettopp dette. TimeEdit kan supplere den eksisterende funksjonaliteten i mobil-applikasjonen ved å tilby dypere innsikt i og bredere oversikt over studier og enkeltfag. Mer konkret skal en bruker av mobilapplikasjonen være i stand til å slå opp et fag eller studie, og så ha muligheten til å få servert en ferdig formatert og relatert time-plan. Det å kunne enkelt reservere rom fra applikasjonen er forsåvidt også noe som har klar nytteverdi, men er ikke like godt knyttet opp mot applikasjonen s hovedfokus. Dermed ble booking av rom ikke tatt med i funksjonsimplementeringen.

53 Hovedprosjekt Side 53 Utvikling Når hvilke tjenester fra TimeEdit som skulle implementeres i applikasjonen ble fastslått, gjensto det å bestemme metoden for å oppnå integreringen. Denne delen beskriver hvilke valg-alternativ vi kom fram til at vi hadde, sammenligning og den endelige vurderingen. TimeEdit er som tidligere beskrevet en tjeneste utviklet av selskapet Evolvera som tilbys brukeren gjennom en nettleser. Basert på kun denne kunnskapen kunne vi ramse opp tre metoder for å implementere skolens timeplanløsning i applikasjonen. Disse tre (med begrunnelse) er: 1. Bruk av eksisterende API tilknyttet TimeEdit For en slik data-sentrert tjeneste er det sannsynlig at en API-løsning er utviklet, da dette er vanlig for moderne geskjefter. [ 71 ] 2. Web-scraping av HIALS TimeEdit s nettside Som beskrevet i delen om Web-Scraping under Teoretisk Grunnlag, er det mulig å parse en nettside for relevant data og rekonstruere den i et mer anvendbart format. 3. Vise TimeEdit s nettside direkte gjennom Android s eksisterende funksjoner Dette er et klart valg-alternativ som er gjennomførbart. En oppsummeringsliste med ulemper/fordeler ved disse valgmulighetene er tilgjengelig lengre nede i denne seksjonen, i tillegg til hvilken som ble valgt. Av disse tre alternativene er direktevisning av TimeEdit s nettside enklest å implementere, da dette kun innebærer å lage en container i applikasjonen(ved bruk av Android WebView) som peker til siden. Ulempen med denne metoden er at nettsiden til TimeEdit ikke er designet for visning på små skjermer. Dette innebærer at det må mye navigering (zooming, scrolling, leting) til for å komme fram til riktig data, noe som er lite ønskelig fra et brukerperspektiv. Gruppen benyttet Galaxy Nexus-enhetene til å besøke og navigere HIALS TimeEdit s nettside, med dårlig brukeropplevelse som forventet. Dataene var presentert uoversiktlig og de små skjermene gjorde det vanskelig å utbedre dette. Dermed ble det tidlig klart at å vise TimeEdit s nettside direkte var langt i fra et ønskelig alternativ, selv om tilnærmings-metoder som det å bruke en WebView til å ha en egen-definert CSS-fil for å endre layout ble inkludert i vurderingen. Trolig kunne vi ha fått til bedre visning på små skjermer, men dataene ville likevel vært utilgjengelig for oss dersom vi ikke benyttet oss av web-scraping-teknikker for å strukturerere de. Den foretrukne metoden er å bruke TimeEdit s eget API. Ved bruk av et API vil applikasjonen være tildels beskyttet mot små forandringer i koden til TimeEdit, og dataene ville kunne bli presentert i applikasjonen med det samme gjennomgående utseende/temaet som de andre funksjonene. Ulempene med denne metoden i forhold til å bare vise nettsiden til TimeEdit er at det er noe mer arbeid å grafisk presentere dataene i applikasjonen. Web-scraping er det mest tidkrevende av de tre alternativene fordi det legger til ekstra steg med arbeid for å få hentet ut dataene. I tillegg til å hente og presentere dataene, er det nødvendig å utvikle en metode for å filtrere ut kun riktig data fra TimeEdit s nettsider. En annen ulempe er at løsningen er sårbar for forandringer på TimeEdit sine nettsider. Basert på det ovennevnte kan vi hevde følgende fordeler og ulemper: 1. Bruk av eksisterende API tilknyttet TimeEdit + Sikker + Allerede utviklet og ummiddelbart anvendbar - Avhengig av en tredjepart

54 Hovedprosjekt Side Web-scraping av HIALS TimeEdit s nettside + Mer frihet til å definere løsning - Usikker - Tidkrevende da ekstra arbeid er nødvendig 3. Vise TimeEdit s nettside direkte + Enklest å implementere - Kanskje vanskeligst å implementere godt - Lite presenterbar på mobile applikasjoner - Ingen kontroll eller strukturering av relevante dataene Etter å ha vurdert disse tre metodene ble gruppen enige om å bruke TimeEdit s API. Grunnlaget for dette er at det fremsto som det alternativet som ville enklest gi oss et strukturert datasett å jobbe med, da både alternativ 2 og 3 krever web-scraping for å ekstrahere nyttig data. Hvis dataene var allerede tilgjengelig i et API kunne mye arbeid unngås. Enkeltheten ved å vise TimeEdit s nettside direkte så ikke ut til å være verdt presentasjonsproblemene som ville forekomme. Dermed følger prioriteringen for ønsket metode samme nummerering som listen over. For å gå frem med denne løsningen tok vi kontakt med Geir Halsvik, som er leder for IT seksjonen ved Høgskolen i Ålesund. Av han fikk vi vite at ansvarlig for TimeEdit ved høyskolen er Nils Roald, og at systemet driftes av Kenneth Opedal. Vi ble også informert om at skolen er i gang med å implementere en stor oppdatering av TimeEdit systemet. Den nye versjonen av TimeEdit(versjon 3.x) vil bli betydelig forskjellig fra dagens utgave, både på frontend og backend. Dette gjør at vi møter en ny problemstilling - skal applikasjonen lages for dagens system, og bli avleggs om noen måneder, eller skal vi prøve å få tak i tilgang til den nye versjonen? Gruppen ble enige om å kontakte Evolvera(de som utvikler systemet) ångående API for den nye versjonen. Etter første runde med undersøkelser fikk vi vite at det er nødvendig med en sertifisering for å få tilgang til systemet. Etter dette bestemte gruppen seg for å ta kontakt med Evolvera direkte, da et slikt kurs ville måtte ta sted i Sverige, og gruppen har hverken tid eller ressurser til et slikt kurs. I mellomtiden skulle gruppen utforske web-scraping som et alternativ i tilfelle det ikke var mulig å få API tilgang uten kurs. Som en siste utvei kan problemet løses ved å presentere TimeEdit sin nettside i applikasjonen. Dette har fordelen med at man kan bare forandre ressurslinken når det nye systemet kommer i drift. Ulempen med dette er at nettsidene ikke er tilpasset liten skjerm som diskutert tidligere. Forsøk på aksessere TimeEdit s API uavhengig av noe kurs for sertifisering med prøving-og-feiling i nettleseren lyktes heller ikke. Løsningen som ble valgt var å implementere en web-scraping-mekanisme på serversiden av applikasjonen som tilbød strukturert data gjennom et egetutviklet API (web service). Mobil-applikasjonen er i stand hente de dataene den trenger fra web-applikasjonen ved behov. Dette løser også problemstillingen med at HIALS skulle implementere en ny versjon av TimeEdit, da det ikke blir nødvendig å oppdatere samtlige mobile enheter for å kompensere for endringen. For brukerne vil ikke opplevelsen bli noe forskjellig med den gamle TimeEdit løsningen og den nye TimeEdit løsningen Lovlige hensyn Med den løsningen som ble valgt var det viktig å vite at innhentingen av dataene ikke bryter med noen lover om opphavsrett, da spesifikt åndsverksloven [ 72 ]. Etter å ha undersøkt dette, hovedsakelig ved bruk av internett

55 Hovedprosjekt Side 55 kom vi frem til konklusjonen at innhentingen av data ikke bryter med lover eller retningslinjer for opphav av data. Dette er basert på de to følgende argumentene; Dataene er produsert og administrert av skolen, og er derfor skolens eiendom. Evolvera(selskapet som leverer og eier TimeEdit), leverer kun løsningen som presenterer dataene. Robots.txt filen som ligger ved timeplanen tilsier at automatiske tjenester kan innhente data fra alle kataloger for domenet timeedit.hials.no [ 73 ]. Dette er en vedlagt fil/protokoll som viser hva automatiske tjenester har tilgang til Utvikling av løsning Da det var bestemt at vi skulle benytte oss av web-scraping for å søke etter og hente ut behandlingsklar informasjon, begynte vi med analyse av TimeEdit-tjenesten som tilbudt sluttbrukeren via nettsiden [ 74 ]. Figur 4.31: Et skjermbilde av TimeEdtit s nettside for søk på klasser Nettsiden i Figur 1.31 er grensesnittet til tjenesten som vi skal integrere. Den er aksesserbar fra hvilkensomhelst nettleser via HIAL s hjemmeside [ 75 ] og inneholder de funksjonene fra TimeEdit som vi ønsker å integrere i e-læringsapplikasjonen. Selve dataene vi ønsker befinner seg i tekstformat i en eller annen del av kildekoden. Kildekoden kan granskes enkelt ved hjelp av en nettleser eller ved å laste ned siden og åpne den med et tekstredigeringsprogram. Vi benyttet oss av nettleseren for å granske kildekoden. Kildekoden består av

56 Hovedprosjekt Side 56 svært mye tekst, og det vil ikke legges ved denne rapporten, men kan undersøkes ved å laste ned nettsiden selv. Der det er nødvendig vil vi vise utdrag. Ved å se nærmere på kildekoden finner man at nettsiden består av standard HTML, og benytter seg av Javascript for å endre side-innhold via å manipulere og sende input-parametere via HTML-forms. f u n c t i o n addobject ( i d ) { 2 var r e l o a d i n g d i v = document. getelementbyid ( r e l o a d i n g ) ; r e l o a d i n g d i v. s t y l e. d i s p l a y = ; 4 document. form. wv_addobj. value = i d ; document. form. submit ( ) ; <INPUT type = hidden name= wv_addobj value= Kodesnutt 4.1: Utdraget av HTML kildekoden til TimeEdit ovenfor viser en JavaScript-funksjon og en input-tag. Dette foregår ved at brukeren interagerer med elementer i nettsiden (knapper, søkefelt (input forms) o.l) som er bundet tl JavaScript funksjoner. På denne måten kan nettleseren tolke brukeren s ønsker, og TimeEdit vil svare med mer HTML og JavaScript som inneholder en timeplan. Bruker-input lagres som parametere i HTML input-forms som tolkes som parametere ved sending. Disse parameterene sendes med HTTP GET, og dette betyr at bruker-inntastet data er synlig i URLen. Det er da enkelt å hente ut ønsket innhold uten å måtte benytte seg av Javascript eller å hente innhold mer enn en gang. Ønskede parametre kan settes som strenger i etter den eksisterende URLen, og ønsket innhold kan hentes direkte dersom man har kjennskap til strukturen. På denne måten unngår vi bruk av TimeEdit s nettside helt. Neste steg er derfor å skaffe seg kjennskap til og forståelse av strukturen i TimeEdit s nettleser-baserte tjeneste. Selve dataene som TimeEdit leverer og dets struktur (timeplan) må forstås, i tillegg til strukturen i det underliggende systemet og hvordan URLen kan manipuleres for å levere resultatet som inneholder dataene vi trenger.

57 Hovedprosjekt Side 57 Figur 4.32: En vanlig timeplan I selve timeplanen som presentert av TimeEdit, kan oversikts-perspektivet brytes ned i følgende tidsgrupperinger: 1. År (semestertimeplan) 2. Uker 3. Dager 4. Forelesninger (Tidsramme definert av klokkeslett) Forelesningene er det meste relevante for visining i E-lærings-applikasjonen og inneholder også det meste av informasjonen som knyttes opp til applikasjonen s innhold. (Fag, Studieløp etc) Dette utgjør måldataene som vi må produsere en metode for å pålitelig kunne hente ut. Neste steg var å finne ut hvordan TimeEdit s programstruktur gjør seg synlig via nettsiden, og hvordan dette kunne benyttes. Figur 4.33: Treff-element som vises etter søk i TimeEdit som presentert i en nettleser.

58 Hovedprosjekt Side 58 1 <a h r e f = j a v a s c r i p t : addobject (175000) ><img s r c = /img/ p l u s. g i f... > Kodesnutt 4.2: Utdrag av kildekoden til TimeEdit s nettside som vist i figur 1.32 Av kildekoden til TimeEdit og det assosierte elementet i nettleseren ovenfor, kan vi resonnere oss fram til at enheter i systemet som fag, lærere eller klasser er i systemet representert som objekt med tilhørende datafelt. Felles for alle objektene er en ID bestående utelukkende av tall på fem eller seks siffer som benyttes for å kunne gjøre oppslag i systemet. Dette ser vi fra JavaScript funksjonen i figur Disse informasjonsobjektene representerer f.eks fag, klasser eller rom, og danner grunnlaget for hvordan timeplanen skal formateres. Vi kan videre resonnere oss fram til at TimeEdit har dermed et eget system for håndtering og kontroll av informasjonsobjekter. Dette systemet ser ikke ut til å være direkte kompatibelt med systemet i E-lærings websiden eller Høyskolens andre systemer. Dette var forventet av gruppen, men presenterer også ett problem som må under utviklingen løses for at systemene skulle kobles sammen sømløst. Problemet er at vi ikke kan gjøre oppslag eller søk i TimeEdit s system med unike data-felt i vårt eller Høyskolen s system. Det neste steget går ut på å analysere URLen som brukes for å hente svar fra HIALS TimeEdit s server. URLen påvirker direkte svar-resultatet og kan i seg selv definere hva som skal hentes uten noe behov for å sende med ett objekt eller lignende. Nedenfor er en slik URL: 1 http : / / t i m e e d i t. h i a l s. no/4daction/webshowsearch/1/1 0?wv_type=5&wv_ts= T191704X3729& wv_search=&wv_startweek=1301&wv_stopweek=1318& wv_ first=0&wv_addobj=&wv_delobj=&wv_obj1 =174000&wv_text=Tekstformat Kodesnutt 4.3: En URL generert når man søker etter en timeplan for ett spesifikt fag Man kan lese av URLen og analysere de forskjellige parameterene. Parameterene er forøvrig alt som befinner seg etter spørsmålstegnet i URLen, og består av nøkkel-verdi par bundet sammen med likhetstegn. En parameter er separert fra en annen med tegnet ampersand. Selve parameterene med tilhørende verdier er skrevet på engelsk eller norsk, og disse ordene er forkortelser eller sammensetninger som også forteller om parameterens bruksområde. I tillegg matcher parameternavnene funksjonsnavnene i Javascript, som også gir videre grunnlag for å bestemme hva de gjør. Med enkel deduksjon og noe prøving og feiling, finner man fram hvilke parametre som gjør hva, hvilken rekkefølge de må stå i, og hvilke som er nyttige for E-lærings-applikasjonens bruk.

59 Hovedprosjekt Side 59 Tabell 4.3: Tabell over parametere i URLen separert som navn og verdi med tilhørende funksjon Navn Verdi Funksjon wv_type Tall Bestemmer hvilket type objekt som skal søkes etter. Fag/Kurs = 3 Klasse/Program = 5 Foreleser = 6 Rom = 7 wv_ts Dato + Streng Sesjon vw_search Streng Søk på navn tilhørende objekt vw_startweek vw_stopweek vw_obj1 (inkluderer wb_obj2, wb_obj3 etc) vw_text vw_addobj vw_delobj Streng bestående av 4 tall, siste to siffer fra år og ukenummer. Streng bestående av 4 tall, siste to siffer fra år og ukenummer. Tall-streng bestående av fem eller seks siffer. Spesifikk tekst-streng: tekstformat grafisk tekst Tall-streng bestående av fem eller seks siffer. Tall-streng bestående av fem eller seks siffer. Bestemmer når timeplanen skal starte. Bestemmer når timeplanen skal stoppe. Setter hvilke objekt i TimeEdit systemet som skal inkluderes i timeplanen. Bestemmer hvordan timeplanen skal representeres. Legger til ett objekt til listen. Fjerner ett objekt fra listen. Tabellen ovenfor ble utarbeidet ved å bruke TimeEdit s nettside i en nettleser, gjøre endringer og observere hva som blir endret, fjernet eller lagt tili URLen. Av parameterene ovenfor er har kun ett fåtall noen nytteverdi for vår bruk, noe som er svært heldig da det vil gjøre jobben med å implementere en løsning mindre komplisert. Vi vil med første øyekast kun ha bruk for parameterene som velger objekt for visning i TimeEdit-systemet, og parameterne som velger tidsrammen for timeplanen. Videre testing viser at de nødvendige parameterene vi må benytte må stå i følgende rekkefølge: 1. wv_obj1 Objektkoder går først, så mange som nødvendig (obj1, obj2 etc...). 2. startweek, stopweek Disse er valgfrie, men bør defineres for enkelhets skyld. 3. vw_text Med denne kunnskapen er det mulig å konstruere en URL som returnerer en ønsket timeplan gitt at man kan objektkoden tilhørende faget eller studieløpet i TimeEdit-systemet.

60 Hovedprosjekt Side 60 Valg av teknologi/støttebibliotek Følgende den initielle analysen av TimeEdit s presentasjonslag, gjenstår implementasjon av web-scraping løsning i server-delen av web-applikasjonen. Løsningen må benytte Java, være i stand til å hente ut og analysere websider samt være godt nok dokumentert til å kunne enkelt endres ved behov. Kravet for å enkelt kunne endres var nødvendig for å kunne svare på eventuelle endringer i Time-Edit systemet. I tillegg til en selv-utviklet løsning som benytter Java s HTTPClient pakke, eksisterer følgende løsninger utviklet av tredjeparter myntet på nettopp web-scraping: Jsoup [ 76 ] TagSoup [ 77 ] HTMLUnit [ 78 ] Web Harvest [ 79 ] jarvest [ 80 ] Tanken på utvikle en egen løsning via Java s eget HTTPClient bibliotek falt bort da det er mye enklere og tidsbesparende å benytte en eksisterende løsning som allerede er godt dokumentert. Noe testing med en egen løsning ble utført, men det skapte en større kodebase å vedlikeholde, noe som ikke var ønskelig og heller ikke nødvendig i dette tilfellet. Ved å lære og bruke en av de ovennevnte støttebibliotekene kunne gruppen dermed fokusere på den viktigste delen av løsningen - selve uthentingen og bearbeidingen av informasjonen. Gruppen som helhet analyserte de forskjellige alternativene som nevnt i listen ovenfor ved å gå gjennom dokumentasjon og presentasjon av funksjonalitet som bibliotekene hadde. Disse er alle nettbaserte. Gruppen konkluderte med at Jsoup var det enklest benyttbare alternativet. En av de viktigste grunnene til at gruppen kom til denne beslutningen var at Jsoup viste seg å være best dokumentert, fra både offisielt hold og tredjeparts bruk av Jsoup. En annen og minst like viktig grunn, var hvordan gruppen oppfattet enkelheten i syntaksen. For eksempel HTMLUnit imiterer en klient, og krever gjerne dypere kjennskap til kildekoden som skal analyseres, og har litt mer komplisert og noe for ordrik syntaks. For å f.eks hente ut en spesifikk tag i et HTML-dokument krevde HTMLUnit for mye. Jsoup og TagSoup imiterer HTML-hierarkiet på en logisk måde i kode-syntaksen, noe som gjorde det mer attraktivt en andre alternativer (Objektstrukturen i biblioteket hadde et hierarki som etterlignet HTML-hierarki-systemet). Dette ville gjøre koden mer lesbar, vedlikeholdbar og ikke minst skrivbar for gruppemedlemmene. TimeEdit og E-læringsapplikasjonen, to forskjellige systemer En metode for å kunne sette likhetstegn mellom to objekter i to forskjellige systemer, f.eks et fag som representert av E-lærings websiden og et fag som representert av TimeEdit var som tidligere nevnt nødvendig. TimeEdit støtter også søk med fritekst, og søk med fagkode eller klassekode gir som regel ett resultat som vist i bildet nedenfor - dette kan vi utnytte til å hente ut TimeEdit-objektkodene vi trenger.

61 Hovedprosjekt Side 61 (a) Fag (b) Klasse Figur 4.34: TimeEdits fritekstsøk for fag og klasse Som vist i figur 4.34 og kodesnutt 4.2 inneholder treff-elementet objektkoden, og herfra er det kun et spørsmål om hvordan man skal legge til dette søkesteget i løsningen. Utvikling av løsning i Java med Jsoup og JAX-RS Basert på analysen av TimeEdit og ved valg av støttebibliotek gjensto det kun å utvikle løsningen konkret. Generering av URL Basert på det som kom fram av analysen av TimeEdit tidligere, opprettet vi metoder i klassen TimeEditService i web-applikasjonen som genererte en korrekt formatert URL basert på relevante input-parametere. Kodesnutten i vedlegg 4 dem inneholder disse metodene, og vi vil ikke gå mer i dybde mer enn nødvendig - hovedpoenget her er å demonstrere at vi benytter dataene vi samlet inn til å generere URLer. Testing av disse ble gjort ved å lime inn resultatet fra nettleseren og verifisere resultatet. Parsing i Jsoup Med Jsoup som støttebibliotek kan henting, parsing og REST-funksjonalitet skrives inn i en og samme klasse, en EJB om nødvendig. Jsoup er kompakt, funksjonsrikt og lettbrukt nok til at dette er mulig uten å gjøre koden uleselig. For å beholde modulariteten i systemet, utviklet vi TimeEdit-løsningen som en enkelt støttet REST root resource klasse, som beskrevet i seksjonen Teoretisk Grunnlag - REST tjenester. Et utdrag fra denne klassen er vist nedenfor: import javax. e j b. S t a t e l e s s ; 3 import javax. ws. r s.get; import javax. ws. r s. Path ; 5 import javax. ws. r s. PathParam ; S t a t e l e s ( " t i m e e d i t " ) 9 p u b l i c c l a s s TimeEditService { //Maximum number o f o b j e c t r e q u e s t s that w i l l be parsed by geturl ( ) 11 p r i v a t e s t a t i c i n t MAX_OBJECT_REQUESTS = 1 0 ; } Kodesnutt 4.4: Kodesnipp fra klassen TimeEditService, som er grovt kortet ned.

62 Hovedprosjekt Side 62 I første omgang var det viktigst å få gjort en tilkobling via HTTP til TimeEdit for å få hentet ut et HTMLdokument og skape en logisk struktur av de nødvendige dataene som kunne behandles programmatisk. For å få til en slik struktur, ble en del indre klasser opprettet for representere forskjellige objekter som speilet TimeEdit s innordning av objekter og tidsrammer. Strukturen her kan beskrives som hierarkisk da en overordnet klasse vil innehold lister (java.util.list) av den underordnede klassen. Disse klassene er kun nyttig i sammenheng med midlertidig organisering av data, og har ikke nytte utenfor klasse-skopet. Figur 4.35: Diagram over Klassen TimeEditService med indre klasser. En forbindelse mellom vår EJB og TimeEdit er enkelt opprettet som illustrert av kode-utraget nedenfor: 1 p u b l i c TimeEditSchedule gettimeeditschedule ( S t r i n g siteurl ) { TimeEditSchedule timeeditschedule = new TimeEditSchedule ( ) ; 3 Document doc = n u l l ; t r y { doc = Jsoup. connect ( siteurl ). get ( ) ; 7 } catch ( IOException ex ) { Logger. getlogger ( TimeEditService. c l a s s. getname ( ) ). l o g ( Level.SEVERE, n u l l, ex ) ; 9 } Kodesnutt 4.5: Et utdrag av en metode i TimeEditService som viser hvordan Jsoup benyttes for å hente ut ett enkelt dokument Document-objektet doc kan så enkelt gjennomgås ved hjelp av løkker og if-setninger som utnytter vår kjennskap til kildekoden til HTML-dokumentet som returneres av TimeEdit. Eksempelet nedenfor viser hvordan

63 Hovedprosjekt Side 63 man kan gå gjennom HTML via Jsoup og hente ut data: 1 i f (! tablecolumns. get ( i ). getelementsbytag ( " f o n t " ). isempty ( ) ) { s t r i n g D a t a = tablecolumns. get ( i ). getelementsbytag ( " f o n t " ). f i r s t ( ). t e x t ( ) ; 3 i f ( s t r i n g D a t a. c o n t a i n s ( "Uke" ) ) { // c r e a t e new week and break loop i f the f i r s t element c o n t a i n s Uke 5 // System. out. p r i n t l n ("NEW WEEK: " + s t r i n g D a t a ) ; } Kodesnutt 4.6: Utdrag fra klassen TimeEditService i web-applikasjonen Kodesnutten ovenfor viser en if-setning som sjekker om det eksisterer et element i HTML-koden som har taggen "font", og at denne ikker tom. Deretter henter sjekker den innholdet i elementet. Selve arbeidet er utelatt av plasshensyn. HTML-dokumentet som returnert av TimeEdit sorterer informasjonen vi trenger ved hjelp av standard tabeller med rader og kolonner. Framgangsmetoden vi benyttet for å hente ut dataene gikk dermed ut på å gå gjennom hver rad og hente ut tekstdataene i hver kolonne. Som demonstrert i figur 1.32 er informasjonen av lik type i alle samsvarende kolonner - dvs at i envher rad vil f.eks kolonne nummer 5 alltid vil inneholde samme type data. Hovedtabellen er merket med en class-tag ( booking ), og med Jsoup hentes tabellen enkelt ut og man kan iterere over innholdet og ekstrahere data med en switchcase nummerert etter hver kolonne. Noe forkortet illustrasjon fra funksjonen gettimeeditschedule i klassen TimeEditService følger: Element content = doc. getelementsbyclass ( " booking " ). f i r s t ( ) ; 3 Elements rows = content. getelementsbytag ( " t r " ) ; f o r ( Element row : rows ) { 5 Elements tablecolumns = row. getelementsbytag ( " td " ) ; f o r ( i n t i = 0 ; i < tablecolumns. s i z e ( ) ; i ++) { switch ( i ) { 9 c a s e 2 : //Dag (Man, Tir, Ons e t c ) day = new ScheduleDay ( s t r i n g D a t a ) ; 11 break ; } Kodesnutt 4.7: Utdrag fra klassen TimeEditService fra no.hials.muldvarpweb.v2 1 <TABLE c l a s s = booking border = 0 c e l l p a d d i n g = 5 c e l l s p a c i n g = 0 > Kodesnutt 4.8: Utdrag fra HTML-kildekoden til nettsiden i figur 4.32 Med dette fikk vi organisert hele timeplanen inn i en struktur som vi senere kunne behandle programmatisk.

64 Hovedprosjekt Side 64 Spørring på fagkode og klassekode Som tidligere nevnt var det også nødvendig å kunne hente ut en timeplan basert på fagkode eller klassekode. Dette løste vi ved å bruke to HTTP-spørringer, ett for å finne riktig TimeEdit objektkode basert på TimeEdit s fritekstsøk, og ett siste for å hente ut den faktiske timeplanen som benyttet metoden vi har utviklet ( " c o u r s e c o d e /{ c o u r s e c o d e }{ s t a r t w e e k : ( / s t a r t w e e k /[^/]+?)?}{ stopweek : ( / stopweek /[^/]+?)?}{ date : ( / date /[^/]+?)?} " ) ({ MediaType. APPLICATION_JSON}) p u b l i c Response getschedulebycoursecode ( " c o u r s e c o d e " ) S t r i n g coursecode, ( " s t a r t w e e k " ) S t r i n g ( " stopweek " ) S t r i n g stopweek, ( " date " ) S t r i n g date ) { 9 System. out. p r i n t l n ( " c o u r s e code : " + coursecode ) ; S t r i n g [ ] objectcodes = getobjectcodefromcoursecode ( coursecode ). s p l i t ( "/" ) ; 11 System. out. p r i n t l n ( " objectcode [ 0 ] : " + objectcodes [ 0 ] ) ; r e t u r n getresponse ( objectcodes, date, startweek, stopweek, t r u e ) ; 13 } Kodesnutt 4.9: Utdrag fra en JAX-RS annotert REST resource metode i klassen TimeEditService 1 p u b l i c S t r i n g getobjectcodefromquery ( S t r i n g query, i n t type ) { S t r i n g searchurl = TIMEEDIT_HIALS_URL + TIMEDIT_PARAM_SEARCH_TYPE + "=" + type + "&" + TIMEDIT_PARAM_SEARCH + "=" + query ; Document doc = n u l l ; 3 t r y { doc = Jsoup. connect ( searchurl ). get ( ) ; 5 } catch ( IOException ex ) { Logger. getlogger ( TimeEditService. c l a s s. getname ( ) ). l o g ( Level.SEVERE, n u l l, ex ) ; 7 } Elements elements = doc. s e l e c t ( "a" ) ; 9 System. out. p r i n t l n ( " Elements s i z e : " + elements. s i z e ( ) ) ; Pattern p a t t e r n = Pattern. compile ( " j a v a s c r i p t : addobject \ \((\\ d { 6 } \\ d {7}) \\) " ) ; 11 Matcher matcher ; f o r ( Element e : elements ) { 13 S t r i n g c u r r e n t S t r i n g = e. a t t r ( " h r e f " ) ; i f ( c u r r e n t S t r i n g!= n u l l &&! c u r r e n t S t r i n g. isempty ( ) ) { matcher = p a t t e r n. matcher ( c u r r e n t S t r i n g ) ; 15 i f ( matcher. f i n d ( ) ) { S t r i n g r e t V a l = matcher. group ( ). r e p l a c e ( " j a v a s c r i p t : addobject ( ", "" ) ; r e t V a l = r e t V a l. r e p l a c e ( " ) ", "" ) ; 17 r e t u r n r e t V a l ; } 19 } } 21 r e t u r n "" ; } Kodesnutt 4.10: objektkoder Nytte-funksjon i klassen TimeEditService som bruker regulære uttrykk for å hente ut Ovenfor er en funksjon fra TimeEditService som utfører en HTTP-forbindelse via Jsoup til TimeEdit, og bruker Java s regex-bibliotek til å finne å identifisere søketreffene som inneholder riktig TimeEdit-kode. Som vist i kapittelet om analyse av TimeEdit, befinner TimeEdit-koden seg som variabel inne i et kall til en javascriptfunksjon. Da vi har navnet til denne funksjonen, addobject(), trenger vi regex til å matche denne funksjonen. Dette ble fullført med regex-strengen under:

65 Hovedprosjekt Side 65 j a v a s c r i p t : addobject \\((\\ d { 6} \\ d {7}) \\) Kodesnutt 4.11: Utdrag fra kildekoden i figur 4.32 som vil matche all tekst som inneholder denne javascript-funksjonen, og som et ekstra lag med sikkerhet kun variabler som har en lengde på seks eller sju siffer. I Java regex noterer \\d et tall (uten dobbel kvotering og java-spesifikke spesielle karakterer), hvorav etterfølgende krøllparanteser ({}) som inneslutter et tall noterer lengde. I sammenheng med symbolet som betyr OR, velger vi da å matche innhold med enten seks eller sju siffer. Dette kunne også oppnås ved å notere lengde ved å endre uttrykket til "\\d{6,7}". Etter dette kan man enkelt skrelle vekk teksten i javascript-funksjonen og hente ut selve tallet (TimeEdit objektkode) med Java s String replace-funksjon. Deretter kan man benytte den samme metoden vi utviklet for å hente ut timeplaner basert på objektkoder. Videre skulle det også å ha vært mulig å lagre klasse-kode og TimeEdit objektkodene, slik at det kun ville ha vært nødvendig å gjøre to HTTP-spørringer en gang for hver kode, eller muligens kjøre gjennom alle fagkodene for å hente ut TimeEdit objektkodene. Dette kunne oppnås ved å legge til ett datafelt i Course og Programme JPA-klassene som representerer en TimeEdit kode. En web-scraping-løsning for dette måtte i så fall utvikles, og denne kunne basere seg på arbeidet gjort så langt. Løsningen dette resulterte i kunne gjøre HTTP-kall mot TimeEdit s nettside og motta svar, analysere og ekstrahere svaret for å så strukturere dataene. Alt dette kunne baseres på TimeEdit objektoder Fagkoder (innenfor HIALS s system) Klassekoder (innenfor HIALS s system)

66 Hovedprosjekt Side 66 Design av API Denne delen omhandler hvilke grunnlag vi la til rette for å utvikle vår API for TimeEdit samt hvilke resultater vi endte opp med. API API et er utviklet kun med tanke for bruk av e-læringsapplikasjonen for mobile plattformer. Med dette blir dokumentasjon og svar-type mindre viktig og arbeidet kan fokuseres på å kunne produsere riktige og konsistente resultater. Det blir heller ikke nødvendig å produsere svar i mer enn en type dataformat, og gruppen ble enige om å bruke JSON siden det fremstår som mer lettlest og ikke unødvendig ordrikt. Dette betyr midlertidig ikke at flere dataformat kan tilbys om nødvendig i framtiden. Utforming av URI URI-en til TimeEdit API-et som tilbudt av E-lærings-nettstedet ble utviklet med overflatisk simplisitet og lesbarhet som mål i henhold til seksjonen om URI-design under teoretisk grunnlag. Dette innebærer at vi bruker REST-arkitekturstilen også til utformingen av URIene. REST er beregnet for bruk med teknologier som har blitt populære grunnet enkelhet mtp. lesbarhet og anvendbarhet av mennesker, og med dette som grunnlag har vi rom for å hevde at en URI skal helst være: Beskrivende og meningsfull for mennesker URIen må beskrive ressursen URIen identifiserer. Dette innebærer også at ordbruken må være Ordlagt med substantiv og ikke verb (HTTP) I henhold med prinsippet om et uniformt begrenset grensesnitt og HTTP, må URIen også unngå å bruke verb fordi dette er allerede dekket av HTTP-protokollen. (GET, POST etc.) Logisk strukturert Rekkefølgen og oppbyggingen av URIen skal ikke vanskeliggjøre forståelse av hvilken ressurs som identifiseres, men heller gi mer innsikt jo lengre den er. Dette innebærer at URIen må forstås som logisk stykkvis oppdelt og relatert til det foregående elementet. Kompenserende for menneskelig feil Konsistent Dette betyr at man skulle kunne tolke og forstå hva som ønskes søkt av en spørring mot APIet kun ved å lese URIen uten nødvendigvis å ha dyp kjennskap til APIet. Formålet med dette er å gjøre API et lett å jobbe opp i mot, og å redusere tiden brukere av API et benytter for å skaffe innsikt i systemet samt for å redusere tiden brukt til feilsøking da feil vil forhåpentligvis forekomme sjeldnere. I tillegg skulle eventuelle feiltastinger eller annet feilbruk av API-et ikke taksere det underliggende systemet ved å gjøre unødvendig arbeid med spørringer som ikke vil gi noe nyttig resultat. Klart feilformaterte spørringer burde dermed forkastes, og bruker opplyses om dette. For å oppnå disse målsetningene benytter vi oss av Java s API for REST webservices, JAX-RS. Dette medfølger Java EE 6 som vi bruker, og det er da kun et spørsmål om å gjøre bruk av API et innenfor våre klasser og metoder. Som tidligere nevnt hadde vi opprettet en REST root resource service klasse (TimeEditService), hvor vi har annotert klassen og variabel timeedit, som gjør den gjeldende ressurs-stien til følgende:

67 Hovedprosjekt Side 67 Tabell 4.4: Base-URI pluss sti som defineres i web-applikasjonen. [SERVERPATH]/services/timeedit/ Deretter vil enhver funksjon annotasjon innenfor klasse-skopet benytte ressurs-stien ovenfor, i tillegg til sin egen-definerte variabel. Navnet "/services/" innenfor URIen gjør det klart at alt som etterfølger er "services", eller på norsk, "tjenester" - dette har som henskit å gjøre det klart for brukeren hva som kan foventes av svar. Basert på behovet som definert tidligere kom vi fram til at API et måtte tilby minst følgende tjenester: Henting av timeplan basert på... timeedit objekt-koder fagkode klassekode I tillegg skulle det være mulig å definere en start-uke og stopp-uke eller dato i timeplanen for å avgrense svar-innholdet. For å tilfredsstille behovet ovenfor (og evt. ekstra behov), opprettet vi parmetere for webservices: Tabell 4.5: Tabell over ikke-absolutte URIer, tilknyttet funksjon med JAX-RS og en Funksjonsnavn Beskrivelse / getschedulebymultipleobjectid getparams /simple/ Aksepterer TimeEdit objektkoder og svarer med fullt formatert timeplan getsimpleschedulebymultipleobjectid Aksepterer TimeEdit objektkoder og svarer med enkelt formatert timeplan /coursecode/ getschedulebycoursecode Aksepterer kurskoder og svarer med enkelt formatert timeplan /classcode/ getschedulebyclasscode Aksepterer fagkoder og svarer med enkelt formatert timeplan /params/ getschedulebymirrorparameters Speiler TimeEdit sitt parametersystem, aksepterer også fulle URLer /query/ getschedulebyquery Ikke implementert Som vist tabell 4.5 er ordene som benyttes i URIen i lowercase, og på engelsk. Dette bidrar til at URIen blir konsistent da de eksisterende URIene i applikasjonen for fag, studier etc... allerede er på engelsk. Hvis en bruker vet at alt er i lowercase, reduserer det sannsynligheten for skrivefeil da man ikke trenger å bekymre seg over tegnsetting. Noe som også forhåpentlig vil bidra til mindre skrivefeil er at forholdsvis korte men beskrivende ord brukes. Så langt har vi oppnådd en logisk struktur også, i og med at f.eks timeedit er overordnet alle parametere som kommer etter i URIen.

68 Hovedprosjekt Side 68 Figur 4.36: Demonstrerer Web-servicene som registrert i NetBeans Disse ressurs-endepunktene vil naturligvis ikke dekke hele TimeEdit s funksjonsbredd, men er mer en tilstrekkelig for vår ( "{ o b j e c t s t r i n g : ( ( \ \ d {6} \\ d {7}) /?)+}{ s t a r t w e e k : ( / s t a r t w e e k /[^/]+?)?}{ stopweek : ( / stopweek /[^/]+?)?}{ date : ( / date /[^/]+?)?} " ) 3 p u b l i c Response getschedulebymultipleobjectid ( " o b j e c t s t r i n g " ) S t r i n g o b j e c t S t r i n ( " s t a r t w e e k " ) S t r i n g startweek, ( " stopweek " ) S t r i n g ( " date " ) S t r i n g date ) { 7 S t r i n g [ ] objectcodes = o b j e c t S t r i n g. s p l i t ( "/" ) ; 9 r e t u r n getresponse ( objectcodes, date, startweek, stopweek, f a l s e ) ; } Kodesnutt 4.12: Utdrag fra klassen TimeEditService som viser en JAX-RS annotert funksjon. API URIen som kan defineres annotasjonen er ikke dynamisk, noe som forhindret oss i å nå målsetningen om en enkelt forståelig og brukbar API-URI. Fordi URIen er statisk definert, kan man ikke utelate deler av den. En funksjon URI som er definert slik: / r e s o u r c e /{ objectid }/ c o l o r /{ c o l o r }/ l e n g t h /{ l e n g t h } Kodesnutt 4.13: Eksempel på en statisk definert URI vil ikke kalles dersom rekkefølgen endres eller noe utelates. Det vil si at en URI formet slik: 1 http : / /www. s e r v e r. com/ r e s o u r c e /25/ l e n g t h /10 Kodesnutt 4.14: Eksempel på en URI vil kun gi tilbake en feilmelding eller Resource not found, da en av path-parameterene var utelatt. En løsning for å unngå nettopp denne typen scenarioer, er å opprette flere funksjoner som tar i hensyn forskjellige path-mønstre, men dette skaper overflod av kode. Derfor tok vi i bruk regex også støtter, og kom fram til en regex-streng som vist i i utdraget av figuren nedenfor: 1 { o b j e c t s t r i n g : ( ( \ \ d { 6 } \\ d {7}) /?)+}{ s t a r t w e e k : ( / s t a r t w e e k /[^/]+?)?}{ stopweek : ( / stopweek /[^/]+?)?}{ date : ( / date /[^/]+?)?} Kodesnutt 4.15: Selve strengen inne i variabel med regex I likhet med normal URI-sti definering matcher også denne metoden stien karakter for karakter, men med regex syntaks-regler. I regex-strengen ovenfor er fire PathParameter-variabler definert (innenfor krøllparanteser), og vi vil gjennomgå oppbyggingen stykkvis for å så presentere resultat: objectstring Streng med TimeEdit objektkoder på enten seks eller sju siffer, separert med skråstrek.

69 Hovedprosjekt Side 69 startweek Streng på fire tall-karakterer som setter startuka i semesteret. stopweek Streng på fire tall-karakterer som setter stoppuka i semesteret. date Streng som bestemmer hvilken dato spesifikt timeplanen skal hentes fra. Spørsmålstegnet (?) i regex er et symbol som gjør det foregående settet med karakterer valgfritt, (den matcher mønsteret ingen eller en gang) det vil si at f.eks PathParameter-variabelen date kan være valgfri i URIen, og at funksjonen vil kalles dersom den utelates. Dermed har vi oppnådd målsetningen om å skape en dynamisk og enkelt brukbar URI. Forhåpentligvis kan dette være noe kompenserende for feilbruk av APIet da resultat vil likevel returneres og bruker kan være fornøyd selv om noe utelates. I tilegg var det ønskelig å supplere flere TimeEdit objektkoder i en og samme URI, noe vi også løste med regex. Pluss-symbolet (+) i regex repeterer the forrige symbolet en eller flere ganger, så det kan plasseres bak en regex-gruppering som beskriver TimeEdit objektkoder. Da matcher regex TimeEdit objektkoden (inkludert skråstreker) flere ganger. Resultatet er at URIen kan støtte flere TimeEdit objektoder så lenge de kommer etter hverandre og er separert med skråstrek: 1 http : / /www. s e r v e r. com/ r e s o u r c e s / t i m e e d i t /183000/185000/187500/ s t a r t w e e k /1301/ stopweek /1315 Kodesnutt 4.16: Fungerende eksempel på en URI i APIet. Eksempelet ovenfor viser en gyldig URI som inneholder tre TimeEdit objektkoder, i tillegg til at date PathParameter-variablen er utelatt. Det finnes en øvre grense på hvor mange TimeEdit-koder som kan inkluderes som kan defineres i TimeEditService. Konvertering av klasser til JSON Når APIet var utformet gjensto det å konvertere klassene som holdt dataene til JSON. I seksjonen om JAX- RS i teoretisk grunnlag nevnes det at JAX-RS har egen støtte for nettopp konvertering av POJO-klasser (eller andre Java-API klasser som Response) til JSON, gitt at Getter-og-Setter funksjoner er definert. I klassen TimeEditService håndteres dette i metoden getresponse, som bruker Response-klassen i Java APIet til å genere svar. Eksempel på bygging av et slikt Response objekt ses nedenfor, hvor variabelen responseentity er en TimeEditSchedule-klasse. 1 r e t u r n Response. ok ( r e s p o n s e E n t i t i t y, MediaType.APPLICATION_JSON). b u i l d ( ) ; 1 { Kodesnutt 4.17: Oppsett av Response I tillegg til å kunne tilby en fullt formatert timeplan i JSON som vist i forkortet versjon nedenfor: scheduleyear : " 2013 ", 3 weekstart : "14", weeekend : "15", 5 numberofweeks : 2, weeks : 7 [ { 9 weekstring : "Uke 14, 2013 ", weekno : "14",

70 Hovedprosjekt Side days : [ 13 { day : "Ons", 15 date : "3 apr ", l e c t u r e s : 17 [ { 19 l e c t u r e S t a r t : " 0 8 : 1 5 ", lectureend : " 1 0 : 0 0 ", 21 type : " F o r e l e s, Ovinger ", c l a s s I d : "AU1, DA1, AU y1, DA y1", 23 room : " Borgundfjorden, L165 Datalab, L167 Prosjektrom ", t e a c h e r s : " Adrian Rutle ", 25 comment : n u l l, c o u r s e s : 27 [ { 29 coursename : " O b j e k t o r i e n t e r t programmering ", courseid : n u l l 31 } ] 33 }, { 35 l e c t u r e S t a r t : " 1 0 : 1 5 ", lectureend : " 1 2 : 0 0 ", 37 type : " Ovinger ", c l a s s I d : "AU1, DA1, AU y1, DA y1", 39 room : " L165 Datalab, L167 Prosjektrom ", t e a c h e r s : " Adrian Rutle ", 41 comment : n u l l, c o u r s e s : 43 [ { 45 coursename : " O b j e k t o r i e n t e r t programmering ", courseid : n u l l 47 } ] 49 } ] 51 }, {}, 53 {} ] 55 }, { 57 weekstring : "Uke 15, 2013 ", weekno : "15", 59 days : [ ] 61 } ] 63 } Kodesnutt 4.18: Forkortet JSON- av en fullt formatert timeplan som hentet fra TimeEdit og behandlet i webapplikasjonen kan også en enklere formatert timeplan returneres som kun returnerer dager /m forelesninger og involverte fag. Det vil si kun JSON-arrayet "days" som også er inkludert i kodesnutten ovenfor. Dette ble vurdert som hensiktsmessig siden det ikke var nødvendig å returnere hele og fullt formaterte timeplaner til de fleste av

71 Hovedprosjekt Side 71 funksjonene i mobil-applikasjonen Integrering av TimeEdit i mobil-applikasjonen Med ferdigutviklet metode for å koble sammen TimeEdit og vårt eget system for fag, gjensto det å implementere og presentere dataene i mobil-applikasjonen. Funksjonalitet for å gjøre HTTP-kall er allerede implementert i mobil-applikasjonen for Android, og dette bygger vi på. Mobil-applikasjonen er en såkalt rik applikasjon, som kortfattet betyr at applikasjonen bruker Android s API og retningslinjer for behanding og presentering av data. For å oppnå dette opprettet vi en domenestruktur i form av klasser på klientsiden (mobil-applikasjon), som kunne behandle dataene med egne funksjoner og metoder. Mobil-applikasjonen har en egen Domainstruktur, og kortfattet betyr dette at alle domene-klasser burder arve fra klassen Domain. Innholdet i disse klassene reflekterer stort sett innholdet i domeneklassene på web-applikasjonsbiten, men med funksjoner for deserialisering av JSON. Et eksempel på dette kan ses i kodesnutten under: 1 p u b l i c TimeEditSchedule ( JSONObject j s o n ) throws JSONException { i f ( j s o n. o p t S t r i n g ( " scheduleyear " ). isempty ( ) ) { 3 simpleformat = t r u e ; t h i s. days = ScheduleWeek. JSONArrayToDays ( j s o n. getjsonarray ( " days " ) ) ; 5 } e l s e { simpleformat = f a l s e ; 7 t h i s. scheduleyear = j s o n. g e t S t r i n g ( " scheduleyear " ) ; t h i s. weekstart = j s o n. g e t S t r i n g ( " weekstart " ) ; 9 t h i s. weekend = j s o n. g e t S t r i n g ( "weekend" ) ; t h i s. weeks= JSONArrayToWeeks ( j s o n. getjsonarray ( " weeks " ) ) ; 11 } } 13 p u b l i c s t a t i c L i s t <ScheduleWeek> JSONArrayToWeeks ( JSONArray jsonarray ) throws JSONException { 15 L i s t <ScheduleWeek> r e t V a l = new ArrayList <ScheduleWeek >() ; f o r ( i n t i = 0 ; i < jsonarray. l e n g t h ( ) ; i ++) { 17 r e t V a l. add ( new ScheduleWeek ( jsonarray. getjsonobject ( i ) ) ) ; } 19 r e t u r n r e t V a l ; } 21 Kodesnutt 4.19: To funksjoner fra Domain-klassen TimeEditSchedule i mobil-applikasjonen Integrering av TimeEdit ble gjort i henhold med den eksisterende lag-strukturen i applikasjonen som er diskutert tidligere i dette kapittelet i seksjonen om Mobilapplikasjonen. Grovt innebærer det at den nåværende konteksten i programmet skal styre innholdet som presenteres, dvs. at hvis man er inne på et fag, skal timeplanen være fra dette faget. Mye av presentasjonen i applikasjonen består av moduler som er internt kalt "fragmenter" som inneholder lister, visninger videoer eller andre funksjoner. Det ble bestemt at et fragment for TimeEdit skulle opprettes, og med dette var det nødvendig å tilpasse det nåværende listesystemet til å kunne vise en timeplan. Til dette formålet opprettet vi en ny type ListView og BaseAdapter som kunne sortere og presentere disse dataene, SectionedListView og SectionedListAdapter. Disse er definert som klasser som arver fra ListView og BaseAdapter, og det originale ListFragmentet ble utvidet med funksjonalitet til å håndtere disse nye klassene. Vi så det som nødvendig å gjøre dette fordi å presentere en tekst-tabell produserte ikke like pene og konsistente visninger som en liste, og en liste med objekter vil mye enklere kunne tilby rike brukeropplevelser. Resultatet var en scrollbar liste med seksjoner for uker og dager, hvor den gjeldende dagen/uken er limt i en egen seksjon fast øverst i listen for å enklere holde oversikt. Denne seksjonen kan animeres og gjemmes basert på scrolling, dvs. at hvis man scroller ned til man kommer til en ny uke, forsvinner den nåværende uken og erstattes med den nye. Listen kan i tillegg til dette akseptere trykk og annen interagering på lik linje med andre lister i mobil-applikasjonen.

72 Hovedprosjekt Side 72 I tillegg til dette kan man sjekke "dagens" timeplan fra hvor som helst i applikasjonen, som illustrert under: (a) Viser TimeEdit fragmentet på fremsiden (b) Viser innsiden av TimeEdit fragmentet (c) Viser TimeEdit i sidemenyen Figur 4.37: Skjermbilder av mobilapplikasjonen - TimeEdit-funksjonen TimeEdit-knappen er tilgjengelig fra hovedskjermen, og ved å trykke på den vil timeplanen for det gjeldende faget eller studiet vises fram på en lett-oversiktlig måte. I mobilapplikasjonen er TimeEdit-funksjonalitet også tilgjengelig ved å trykke på HIALS-ikonet oppe i venstre hjørne. En meny vil gli inn fra venstre side ut som viser dagens timeplan for en satt klasse, i dette tilfellet DA1. Trykk på HIALS-ikonet igjen eller Android-tilbakeknapp nederst i venstre hjørnefor å skjule sidemenyen.

73 Hovedprosjekt Side Fronter Figur 4.38: JSON fra REST-tjenesten til fronter - eksempeldata Vi ville hente meldinger fra læreren, dokumenter og innleverings-status fra rommen på fronter. Siden vi ikke fikk den nødvendige tilgangen til skolens frontersystem valgte vi å gjøre ferdig så mye som mulig av systemet slik at det enkelt kunne tas ibruk i fremtiden når en slik tilgang foreligger. Derfor lagde vi et fast sett med eksempel-data for å vise at vår side av APIet fungerer. Det eneste som gjensto var å parse APIet til fronter.

74 Hovedprosjekt Side 74 Fronter i appen (a) Viser Fronter fragmentet på fremsiden (b) Viser innsiden av Fronter fragmentet Figur 4.39: Skjermbilder av mobilapplikasjonen - Fronter-funksjonen Fronter fragmentet viser informasjon fra et valgt rom på fronter og kan kun legges til på fag laget. Siden implenentasjonen ikke ble fullført vises kun eksempeldata her. Om fronter implementasjonen blir fullført i fremtiden er integrasjonen i mobilapplikasjonen allerede klar til bruk BibSys Det første som måtte gjøres var å definere hvilke funksjoner som skulle implementeres. De mer gjennomførte søkesidene på nettet tilbyr mange muligheter for tilpassede søkekriterier, slik som tittel, forfatter, ISBN, bibliotek, etc. Gruppen ble enige om å begrense funksjonaliteten til et enkelt søk på tittel, begrenset til [ 81 ] beholdningen til biblioteket ved Høgskolen i Ålesund. Resultatet av dette søket skulle vises i en liste i mobilapplikasjonen. For å få tilgang til databasen til BIBSys tok vi kontakt med support på BIBSys ved hjelp av vår kontaktperson ved skolens bibliotek, Monica Marchant. Derifra ble det informert om at det grensesnittet de hadde som passet best til vårt var SRU(search/retrieve via URL). Dette er en metode hvor man setter søkeparametrene sine inn i en URL, og så svarer serveren med resultatet i form av et XML dokument. Først måtte vi altså lage en mal til URLen slik at vi kunne enkelt putte inn søkeparametrene vi ønsket. Ved hjelp av noen eksempler fra BIBSys sin support kom vi frem til følgende mal:

75 Hovedprosjekt Side 75 http : / / sru. b i b s y s. no/ s e a r c h / b i b l i o? v e r s i o n =1.2\& o p e r a t i o n=s e a r c h R e t r i e v e\&s t a r t R e c o r d=1\& maximumrecords=10\&query=bs. bibkode=xb\%20and\%20bs. t i t t e l=i b s e n I denne url malen er det noen faste og variable parametre. Disse er som følger: Tabell 4.6: Beskrivelse av parametere i søke-urlen til BibSys Parameter Betydning Fast/variabel maximumrecords=10 query=bs.bibkode=xb query=...bs.tittel=ibsen Dette parametret gir at det skal ikke returneres mer enn de 10 første resultatene Dette parametret begrenser søket til Biblioteket ved Høgskolen i Ålesund Dette parametret begrenser søket til bøker med tittel som ligner på order ibsen. Man søker på forskjellige titler ved å forandre på tittel parametret. Fast Fast Variabel Ved å bruke denne eksempel URLen i en nettleser vil man kunne se resultatene som blir returnert fra BibSys sine servere. Nå som vi visste hvordan man søker i BibSys sine databaser, og hva vi kunne vente oss tilbake, måtte vi avgjøre hva slags struktur systemet vårt skulle ha. Av tidligere erfaring fra alle de andre funksjonene som applikasjonen allerede tilbyr ble vi enige om at serveren skulle ta seg av spørringen til BibSys sine systemer og prossesere resultatet til et enklere format. Mobilapplikasjonen vil da kunne gjøre en enkel spørring mot serveren, og så tar serveren seg av spørringen og parsingen, og gir tilbake et enkelt resultat. På denne måten vil det også være enkelt å oppdatere løsningen i frtemtiden, da alle forandringer vil skje på serveren, og brukerne ikke trenger å oppdatere. Om det blir lagt til noen nye funksjoner, vil man alikevel måtte oppdatere mobilapplikasjonen.

76 Hovedprosjekt Side 76 Figur 4.40: Dataflyt ved en spørring mot BibSys Som man kan se er det veldig mye informasjon som blir returnert, så vi måtte finne en måte å hente ut kun de dataene som var relevante. For å løse dette valgte vi å bruke Javabiblioteket Jsoup som vi allerede hadde brukt tidligere for å hente ut data fra timeplansystemet TimeEdit. Dette var fordi biblioteket hadde vist seg å være ypperlig til å hente ut data fra store og kompliserte datasett. For å hente ut de relevante dataene, søkte vi igjennom xml filen, og hentet ut infoen som ligger ved tag id 245. Denne under-seksjonen inneholder navnet på forfatter, tittel, og undertittel.

77 Hovedprosjekt Side 77 Figur 4.41: Relevant del av XML responsen fra BibSys Her går koden igjennom seksjonen linje for linje, og skreller vekk alt som ikke skal være med. Til slutt lagres tittelen og forfatternavnet i en enkel entityklasse og settes inn i listen som skal returneres til mobilapplikasjonen. Man kan se tydelig hvordan jobben serveren gjør forenkler jobben for mobilapplikasjonen. Dataene serveren mottar fra BibSys er på venstre side, mens dataene serveren sender videre til mobilapplikasjonen etter å ha parset innholdet står på høyre. XML dokumentet har forøvrig blitt kortet ned med ca. 2/3 av plasshensyn. Figur 4.42: Data før og etter parsing BibSys APIet i webapplikasjonen er tilgjengelig via URLen: domene.no/services/bibsys/<søkestreng> der <søkestreng> er hva som spurt om i BibSys sitt eget API.

78 Hovedprosjekt Side 78 BibSys i appen Figur 4.43: Skjermbilde av mobilapplikasjonen - Her vises resultatet etter et søk på bøker som matchet tittelen ibsen I mobilapplikasjonen er BibSys implementert som et fragmentet og kan kun settes inn på fremsiden som er det øverste laget. I fragmentet er det en tekstboks og en knapp, brukeren skriver inn søkestrengen og trykker på knappen. Når knappen trykkes inn sendes en spørring med søkestrengen til BibSys API et i webapplikasjonen. JSON dataen fra REST tjenesten blir hentet og parset av mobilapplikasjonen og vist i skjermbildet.