0

2012

Lena Sandvik, Michael Krog,

Kristian Johannessen, Snorre Olimstad,

Alexander Wehlin

Hovedprosjekt av Team Rubberduck

30.05.2012

Produktrapport

1

Forord

Vi forutsetter at leseren har lest presentasjonen av prosjektet før denne rapporten leses. Under

denne forutsetning kan dette dokumentet leses selvstendig. Denne oppbygningen har vi for å gi et

bedre innblikk i hva vår oppgave går ut på, informasjon om gruppen og oppdragsgiver med mer.

Dette er siden vi har en litt spesiell oppgave, med både en utrednings- og utviklingsdel.

Denne rapporten gir utfyllende informasjon som i hovedsak er beregnet for oppdragsgiver, men også

ment for sensor og veileder. Vi benytter derfor ukritisk generelle datatekniske begreper. Men når det

gjelder ord og uttrykk i forhold til kryssplattform har vi tatt høyde for at oppdragsgiver også er ny på

området. Ellers henviser vi til ordlisten (Vedlegg H - Ordliste) hvis noe er uklart.

Denne rapporten er delt i to deler med respektive underkapitler:

Del 1: Utredning som presenterer de resultatene vi har kommet fram til i oppgavens første del.

Denne delen omfatter alt vi leverte til oppdragsgiver, og den inneholder derfor enkelte

prosessrealterte elementer. Vi har allikevel valgt å ha den med her for å gi et bedre helhetsinntrykk

av produktet. Delen består av kapitlene:

Redegjørelse for kartlegging av verktøy: I dette kapitlet redegjør vi for hvilke kriterier vi

la til grunn for vurderingen av de ulike rammeverkene.

Kartlegging av verktøy: Vi vurderer de verktøyene som er aktuelle rammeverk, med

fordeler og ulemper. Til slutt konkluderes det med hvilke tre rammeverk som skal være

med i neste steg.

Utredningen: Her gis først en generell beskrivelse av plattformene. Deretter redegjør vi

for den dyptgående testingen og kommer med en endelig konklusjon. Konklusjonen

inneholder anbefaling av rammeverk til oppdragsgiver.

Del 2: Utvikling som beskriver applikasjonen som ble laget med rammeverket fra del 1, utredningen.

Konklusjonen i denne delen gir en revurdering av rammeverket og vi kommer med en endelig

anbefaling. Delen består av kapitlene:

Gjennomgående elementer: Her beskrives elementer og relevante problemstillinger i

forhold til utviklingen.

Brukeradministrasjon: Her beskrives alle operasjoner som sees på som

brukeroperasjoner – inn-/utlogging, registrering og profiladministrasjon.

Søk: Dette kapitelet omfatter samtlige søkefunksjoner. Søk på bransje, tittel (fritekst) og

kart beskrives her. Videre beskrives også muligheten for lagring av posisjon.

Design: I dette kapittelet gis en grundig forklaring av hvordan designet er bygget opp.

Videre forklarer vi rundt håndtering av landscape- og portraitvisning.

Diskusjon – Webapplikasjon eller native: Her drøfter vi rundt et spørsmål som er veldig

sentralt i databransjen om dagen. Vi kommer også med vår egen konklusjon.

Konklusjon: Dette er den endelige konklusjonen.

2

Innhold Del 1 – Utredningsrapport ...................................................................................................................... 6

1 Redegjørelse for kartlegging av verktøy ......................................................................................... 7

1.1 Fremgangsmåte ...................................................................................................................... 7

1.2 Gjennomgang av poengsetting ............................................................................................... 7

2 Kartlegging av verktøy .................................................................................................................... 9

2.1 webMethods Mobile Designer ............................................................................................... 9

2.1.1 Tilgjengelighet ................................................................................................................ 9

2.1.2 Modenhet ..................................................................................................................... 10

2.1.3 Oppsummering ............................................................................................................. 10

2.2 CloudPact............................................................................................................................. 10

2.2.1 Tilgjengelighet .............................................................................................................. 11

2.2.2 Modenhet ..................................................................................................................... 11

2.2.3 Oppsummering ............................................................................................................. 11

2.3 FeedHenry ............................................................................................................................ 12

2.3.1 Tilgjengelighet .............................................................................................................. 12

2.3.2 Modenhet ..................................................................................................................... 13

2.3.3 Oppsummering ............................................................................................................. 13

2.4 Kony ...................................................................................................................................... 14

2.4.1 Tilgjengelighet .............................................................................................................. 15

2.4.2 Modenhet ..................................................................................................................... 15

2.4.3 Oppsummering ............................................................................................................. 15

2.5 Rhodes .................................................................................................................................. 16

2.5.1 Tilgjengelighet .............................................................................................................. 16

2.5.2 Modenhet ..................................................................................................................... 17

2.5.3 Oppsummering ............................................................................................................. 17

2.6 PhoneGap ............................................................................................................................. 18

2.6.1 Tilgjengelighet .............................................................................................................. 18

2.6.2 Modenhet ..................................................................................................................... 19

2.6.3 Oppsummering ............................................................................................................. 19

2.7 Mono .................................................................................................................................... 20

2.7.1 Tilgjengelighet .............................................................................................................. 20

2.7.2 Modenhet ..................................................................................................................... 21

2.7.3 Oppsummering ............................................................................................................. 21

3

2.8 Konklusjon ............................................................................................................................ 21

3 Utredningen ................................................................................................................................. 22

3.1 Generelt om plattformene ................................................................................................... 22

3.1.1 Android ......................................................................................................................... 22

3.1.2 iPhone ........................................................................................................................... 24

3.1.3 Windows Phone ............................................................................................................ 25

3.2 PhoneGap ............................................................................................................................. 25

3.2.1 Komme i gang ............................................................................................................... 25

3.2.2 Utviklingsprosessen ...................................................................................................... 31

3.2.3 Beskrivelse av APIer ...................................................................................................... 31

3.2.4 Testapplikasjonen ......................................................................................................... 33

3.2.5 Hva rammeverket egner seg til ..................................................................................... 35

3.2.6 Oppsummering ............................................................................................................. 35

3.3 Mono .................................................................................................................................... 37

3.3.1 Komme i gang ............................................................................................................... 37

3.3.2 Utviklingsprosessen ...................................................................................................... 39

3.3.3 Beskrivelse av APIer ...................................................................................................... 40

3.3.4 Testapplikasjon ............................................................................................................. 40

3.3.5 Hva rammeverket egner seg til ..................................................................................... 43

3.3.6 Oppsummering ............................................................................................................. 43

3.4 webMethods Mobile Designer ............................................................................................. 45

3.4.1 Anskaffelse ................................................................................................................... 45

3.4.2 Forsøk på å bruke produktet ........................................................................................ 45

3.5 Rhodes .................................................................................................................................. 47

3.5.1 Komme i gang ............................................................................................................... 47

3.5.2 Utviklingsprosessen ...................................................................................................... 49

3.5.3 Beskrivelse av API’er ..................................................................................................... 53

3.5.4 Testapplikasjon ............................................................................................................. 54

3.5.5 Hva rammeverket egner seg til ..................................................................................... 57

3.5.6 Oppsummering ............................................................................................................. 57

3.6 Konklusjon ............................................................................................................................ 59

3.6.1 Delkonklusjon: PhoneGap ............................................................................................. 59

3.6.2 Delkonklusjon: Mono .................................................................................................... 60

3.6.3 Delkonklusjon: webMethods Mobile Designer ............................................................. 60

4

3.6.4 Delkonklusjon: Rhodes ................................................................................................. 60

3.6.5 Endelig konklusjon ........................................................................................................ 61

4 Kildehenvisning ............................................................................................................................ 62

4.1 Internettreferanser............................................................................................................... 62

4.2 Bokreferanser ....................................................................................................................... 69

Del 2 – utviklingsrapport ...................................................................................................................... 70

1 Gjennomgående elementer ......................................................................................................... 71

1.1 Browser-ulikheter ................................................................................................................. 71

1.2 localStorage .......................................................................................................................... 71

1.3 GlobalConst.js ....................................................................................................................... 72

1.4 Loadingskjerm ...................................................................................................................... 72

1.5 Internett-tilgang ................................................................................................................... 72

1.6 Webservice ........................................................................................................................... 73

1.6.1 Tjenestene .................................................................................................................... 73

1.6.2 Hente data .................................................................................................................... 73

1.6.3 Poste data ..................................................................................................................... 74

2 Brukeradministrasjon ................................................................................................................... 75

2.1 Startsiden ............................................................................................................................. 75

2.2 Logg inn ................................................................................................................................ 76

2.3 Logg ut .................................................................................................................................. 77

2.4 Registrer ............................................................................................................................... 77

2.5 Vis profil ............................................................................................................................... 81

2.6 Endre bruker ......................................................................................................................... 82

2.7 Slett bruker ........................................................................................................................... 84

3 Søk ................................................................................................................................................ 85

3.1 Bransje .................................................................................................................................. 86

3.2 Tittel/resultat ....................................................................................................................... 87

3.2.1 Generelt ........................................................................................................................ 88

3.2.2 LocalStorage variabler .................................................................................................. 89

3.2.3 Sidehåndtering ............................................................................................................. 90

3.2.4 Håndtering av forskjellige søk ....................................................................................... 90

3.2.5 Håndtering av navigering mellom sider ........................................................................ 91

3.2.6 Samspill mellom tekstsøk og kart ................................................................................. 92

3.3 Detaljert visning av stilling .................................................................................................... 93

5

3.3.1 Håndteringer av opphørte stillinger ............................................................................. 94

3.4 Søke i kart ............................................................................................................................. 95

3.4.1 Oppbygning .................................................................................................................. 95

3.4.2 Beregning av avstander ................................................................................................ 96

3.4.3 Håndtering av interaksjon med kartet .......................................................................... 97

3.4.4 Glideskala ..................................................................................................................... 98

3.4.5 Informasjonsvinduer, markører og deres funksjon ..................................................... 100

3.5 Lagring av posisjon ............................................................................................................. 100

4 Design ......................................................................................................................................... 104

5 Diskusjon: Webapplikasjon eller native? .................................................................................... 106

5.1 Kryssplattform .................................................................................................................... 107

5.2 Utseende ............................................................................................................................ 108

5.3 Utviklingsprosessen ............................................................................................................ 108

5.3.1 Lisenser ....................................................................................................................... 108

5.3.2 Debugging/testing ...................................................................................................... 108

5.3.3 Brukertester................................................................................................................ 109

5.3.4 Distribusjon ................................................................................................................ 110

5.4 Versjoner ............................................................................................................................ 110

5.5 API-tilgang .......................................................................................................................... 110

5.6 Konklusjon .......................................................................................................................... 111

6 Konklusjon .................................................................................................................................. 113

7 Kilder .......................................................................................................................................... 113

7.1 Internettreferanser............................................................................................................. 113

7.2 Bokreferanser ..................................................................................................................... 117

6

Del 1 – Utredningsrapport --------Overlevert WebCruiter som et selvstendig dokument--------

7

1 Redegjørelse for kartlegging av verktøy

Dette kapitlet redegjør for hvordan vi gikk da vi vurderte rammeverk. Fremgangsmåten er mer

detaljert beskrevet i prosessrapportens kapittel 2.2.1. Videre er avsnitt 1.2 gjengitt i sin helhet i

kapittel 2.2.2.1 i prosessrapporten. Leseren kan derfor fortsette til kapittel 2 hvis dette stoffet

allerede er kjent.

1.1 Fremgangsmåte

Per dags dato finns det många ramverk på marknaden som är tillgänglig för programmerare världen

över, det blir dessvärre mindre när man letar efter ramverk som ska vara krysskompatibel mellan

Android, iPhone och Windows Phone 7.5. För att komma fram till en lista med olika verktyg så var vi

tvungen att sätta vissa grova krav till att börja med. Det gick ut på att skriva ner alla ramverk som vi

finner som är kompatibel med gällande plattformarna för projektet.

Efter att vi har gått igenom och kommit fram till en lista med ramverk så är nästa steg att begränsa

oss och få ned antal ramverk till tre, och lämna in förslaget till arbetsgivaren.

Vi har haft en aktiv dialog med arbetsgivaren genom hela screeningen. Vi kom fram till att enkelt av

ramverken vi tog med på grund av potential inom kort framtid, inte skulle vara med för att dem inte

uppfyllde kraven som vi hade satt. Dem var också irrelevant för arbetsgivaren.

Efter önskan av arbetsgivaren begränsade vi antal aktuella ramverk och satt igång utredning av de

slutliga tre ramverken.

1.2 Gjennomgang av poengsetting

Vi har valt att vi ska rangera varje ramverk på en skala 1 – 10 beroende på hur bra dom gör sig på

respektive punkt. Full översikt av tabbeller finner ni i vedleggene till sist (Vedlegg B – Rangering etter

kartlegging og Vedlegg C – Revurdering etter utredningen). Förklaring om vad vi lägger vikt på varje

punkt följer nedan.

krysskompilering: Bygger som namnet föreslår att ramverket är helt krysskompatibel, eller om det

skulle vara andra faktorer som att man blir tvungen att skriva egen kod till olika plattformar.

Tillgänglighet Är bland annat på hur lätt det är att få information om verktyget, hur lätt

nedladdningen är, hur integreringen till olika IDE. Eller om dem har en egen lösning. Vi tar följande i

värdering:

Anskaffelse

o Hur lätt är det att hitta information om hur man laddar ner programmet, också hur

svårt är det att installera SDK.

Integrering med utvecklingsmiljöer

o IDE plugin eller egen IDE lösning?

o Hur lätt är det att få det funktionellt.

Support

o Forum?

8

o Aktiv community som tutorials?

o Email/telefon och respons tid på dom ramverk som vi var tvungen att kontakta.

Community

o Omtale och spridning på F.ex Forum och privata sidor.

o Information och tutorials på net.

Lisensering

o Hur funkar den?

o Pris?

o Vad får man med?

Modenhet: Den delen av analysen som ska summera ihop hur gott verktyget är känt. Får man en låg

score här så tyder det på att det antingen är ett litet sällskap eller att ramverket kan vara så pass nytt

att folk inte har börjat använda det. Krysskompabilitet och API stöd hör också hemma under den här

punkten, men då vi anser att dem punkterna väger så mycket så har vi valt att värdera dem för sig

själv. Så vi värderar följande:

Versjoner

o Hur många versioner finns det?

o Kommer dem med jämna mellanrum, dokumentation och notes som kommer med

uppdateringarna.

Utbredelse

o Många som använder ramverket?

o Hur går utvecklingen av företaget?

Erfaring

o Har företaget funnits länge, och är mobilt en ny branch för dem?

o Kommer dem att finnas inom tid, och är dem levnads duktig?

Omtale

o Ramverket är känd på olika sites

o Företag som använder ramverket nöjd?

o Generellt omtal runt ramverket.

API-stötte: Hur många API som ramverket har stöd för, vi har redan tagit med ramverk som har dem

API som vi behöver, men skala mässigt så betyder en 10 att ramverket har stöd för alla aktiva APIe’er

som finns på marknaden och är aktuella för oss i det här projektet.

Teknologi: Vad använder ramverket för slags programmerings språk, värden som vi sätter här är satt

beroende på hur bra och utbrett språk som används är. Vi har satt i värdering med om språken går

att debugga, och hur lätt det är att testa ut koden till simulator eller device.

9

Efter utredningen omvärderade vi ovanstående punkter då vi hade fått mer förståelse och inblick i

ramverken. I tillägg så lade vi till två punkter.

Utvecklingsprocessen: Hur enkelt är det att sätta upp ett nytt projekt. Har IDE lösningen till

ramverket en god IntelliSense funktion. Har ramverket och IDE lösningen en debugging funktion,

samt hur moduler och bibliotek lösningen är.

Stabilitet: Värderas utifrån hur pass stabilt programmet kör på dem aktuella plattformarna, upplever

vi att en plattform presterar under det vi förväntar, så noteras det här.

2 Kartlegging av verktøy

I dette kapitlet gir vi en beskrivelse av samtlige rammeverk som var med i den detaljerte

kartleggingen. Alle rammeverk har en oppsummering med en tabell over fordeler og ulemper. Helt til

slutt kommer vi med en konklusjon hvor vi trekker frem de tre kandidatene som gikk til utredning.

2.1 webMethods Mobile Designer

Metismo var företaget som starta projektet Bedrock. Som nu har

blivit köpt upp av Software AG och som har blivit en del av deras

lösning webMethods. Ramverket är java baserad, och är Kryss-

plattform kompatibel. kryss-kompilatorn kan automatisk

översätta java till C++, C# och actionScript [1]

OpenGL support vart också lagt till i mitten av 2008 som gör det möjligt för grafisk programmering till

applikationer. I 2009 så vart det även stöd för HTML5 och Flash.

Plattformar som för tillfället har stöd för webmethods ramverk är Android, iOS, windows mobile och

windows phone 7, där den sist nämnda blev tillagd stöd för i slutet av 2010.

2.1.1 Tilgjengelighet

WebMethods erbjuder skräddarsydda licenser beroende på vad man skulle önska till företaget, så

priserna kan variera. För att kontakta så kan man skicka mail till deras sale service som ni kan finna

på hemsidan [2].

Företaget är gott känt på marknaden. Över 50 globala företag använder för tillfället webmethods till

sina mobila plattformar för utveckling av applikationer till internt och externt bruk.

WebMethods har i tillägg stöd för plugin i IDE programmet Eclipse [3]. Vilket gör det enklare att

jobba med vid sidan av andra projekter. Man utvecklar också applikationerna med native stöd. Du

utvecklar en applikation med design och funktionalitet och portar därifrån till önskade plattformar.

WebMethods håller sig också uppdaterad på alla andra plattformars SDKs vilket ger dig tillgång till de

allra senaste funktionerna.

Figur 1: Software AG logo

10

På Hemsidan kan man också finna att WebMethods har ett gott API stöd, man kan dessvärre inte se

specifikt vilka stöd dem har från olika tillverkare.

2.1.2 Modenhet

Webmethods har over tid blivit en av lösningarna för företag världen runt, om man går på deras

hemsida så kan man se att fler och fler använder webmethods.

Med en så stor användare bas som WebMethods har så är det inte svårt att hitta information på

internet eller forum om man skulle önska det. Detta har resulterat i att webmethods har en trevlig

utvecklings miljö där utvecklare och Software AG hjälper till med problem som skulle uppstå.

2.1.3 Oppsummering

WebMethods är baserad på Java men kryss-kompilatorn klarar att översätta till både C++, C# och

JavaScript vilket är språket som används av de flesta mobila plattformarna för tillfället.

Ramverket har också stöd för alla plattformar som skulle kunna vara och bli aktuella på marknaden,

om det kommer nått nytt så kommer dem mest troligt att lägga till stöd för den inom kort framtid.

Beroende på vad man letar efter så har webmethods olika licenser kostnader, på grund av det så kan

vi inte ge nått exempel på vad det hade kostat att utveckla en applikation med Webmethods som

ramverk.

Stöd för Eclipse finns att få som manga av dem andra ramverken, dem håller sig även uppdaterad på

alla andra plattformars SDKs som gör utvecklingen av applikationer vill alltid ha det senaste av

funktioner tillgänglig.

Fördelar Nackdelar

Software AG stort företag. Har bara stöd för en IDE.

Bra API stöd. Man blir tvungen till att skriva UI lösning vid sidan av.

Stöd för alla plattformar.

Många stora företag använder ramverket.

Väldigt bra support.

Tabell 1: Fördelar och nackdelar ved webMethods

2.2 CloudPact

CloudPact [4] ramverket konstruerat av ett företag med

samma namn som har kontor i Indien, Hyderabad.

Företaget Består utav 6 personer men ökar raskt, CloudPact Figur 2: Logo CloudPact

11

är en orginisation som driver och utvecklar cross plattforms mobila SDK för Android, Windows Phone

7, iOS(iPhone, iPad), Blackberry.

CloudPact är baserad på J2EE, HTML5 och CSS och har fullt stöd för APIer så som:

Kamera

Kontakter

Lokation service

Nätverk service

BarCode

Fil access och Database access.

Dem har även stöd för ett antal fler APIer som är listade på dems support sida [5].

I CloudPact kan man programmera apps kallade Hybrid apps, det vill säga att dem ger exat den

samma funktionaliteten som vilken annan nativ app ville ha gjort.

CloudPact har även en server version som heter EmPact vilket vill köra på en server på företaget(On-

site). Den andra lösningen dem erbjuder är att dem hostar din lösning på en server som ligger hos

cloudpact.com, du vill då får tillgång till ett grafiskt IDE till programmerare.

2.2.1 Tilgjengelighet

CloudPact har två stycken olika betalningsmetoder, den ena är för den on-premise och den tar dem

betalt olika beroende på vad kunden skulle önska för specifikationer, medans cloud-hosting tar dem

betalt 120 dollar I året. Det finns också en trial version på deras hemsida som man kan ladda hem

och prova på deras hemsida.

För att köpa produkten så måste man kontakta en säljare hos cloudPact på mail, för att sedan

bestämma vilken lösning man vill av emPact eller hosting hos cloudPact.

2.2.2 Modenhet

CloudPact är ett nytt företag som inte är äldre än 1 år, ramverket är inte för tillfället i någon BETA

utan är ute i en full version för användning. Med tanke på att det inte finns någon användarbas än för

verktyget är så pass nytt så finns det inte mycket hjälp att söka bland forum och andra medier.

Cloudpact är ett relativt nytt företag, hittar inte ett speciellt datum där dem gick live men dem är inte

äldre än 1 år, dvs ett relativt nytt företag som har gått ut med sin första produkt. Ramverket är för

tillfället inte i någon BETA utan är i full version och fungerande. Community är nästan non-existent då

det är ett nytt ramverk.

2.2.3 Oppsummering

CloudPact har stöd för alla aktuella mobil plattformar för tillfället. Företaget ligger placerat i Indien

och har för tillfället sex stycken anställda som jobbar med support och salg av produkten. Dem säger i

en intervju att talet på anställda ökar. CloudPact är baserad på HTML5, CSS och javascript med ett

gott stöd för APIer. Priserna ligger lite varierande beroende på vad för slags lösning man är

12

intresserad i. Dem kan tillbjuda en egen specificerad lösning eller emPact som är en On-site lösning

som man installerar hos företaget. På grund av att företaget är så pass ny så har dem inte attraherat

sig en så många användare.

Fördelar Nackdelar

God API stöd Relativt höga priser

Har alla plattformar Nytt företag

Modenhet

Web IDE

Inga Plugin

Tabell 2: Fördelar och nackdelar ved CloudPact

2.3 FeedHenry

FeedHenry [6] er et irsk selskap startet i 2008 av

forskningssenteret Telecommunications Software & Systems

Group (TSSG). De tilbyr tjenester for kryssutvikling av mobile

applikasjoner i nettskyen under mottoet ”Powering Apps

from the Cloud”.

Selskapet benytter seg av open-source rammeverket PhoneGap [7] til å tilby kryssplattformutvikling

ved hjelp av HTML5, CSS3 og Javascript. I tillegg benyttes nettskyteknologi med mulighet for

dataprosessering og sikkerhet på serversiden. FeedHenry lar deg utvikle native applikasjoner til

iPhone, Android, Windows Phone og Blackberry. Man kan også lage Web Applikasjoner.

Utviklingsprosessen foregår ved at man koder applikasjonen ved hjelp av de nevnte teknologier. I

tillegg er det mulig å benytte andre rammeverk som for eksempel JQuery Mobile og Sencha Touch til

å bygge brukergrensesnitt. Publisering gjøres ved at det genereres binærfiler for de ulike

plattformene som kan distribueres for testing eller på de ulike aktørenes markedsplasser.

2.3.1 Tilgjengelighet

FeedHenry tilbyr to forskjellige løsninger: En gratis versjon for utviklere gjennom en enkel

registreringsprosess. I løpet av sekunder har man registrert seg og kan begynne på sin første

applikasjon. Informasjon om hva man får tilgang til uten å betale er dog vanskelig å få tak i, men en

kort test gir inntrykk av at man har tilgang til alt en enkeltutvikler trenger.

Figur 3: Logo FeedHenry

13

Som bedriftkunde har man mulighet til å prøve en demoversjon gratis. Fullversjonen baserer seg på

en månedlig avgift pluss ytterligere kostnader for lagring, båndbredde osv. Siden FeedHenry støtter

integrasjon med bedriftens systemer, er dette mest sannsynlig løsningen for WebCruiter.

Registreringen gir tilgang til FeedHenrys AppStudio. Dette er et utviklermiljø i nettskyen. Men det er

mulig å bruke Eclipse ved hjelp av en gratis plug-in. Dette lar deg jobbe lokalt i Eclipse, for så å bruke

FeedHenry sine servere til å sjekke inn og ut filene i prosjekter. Det virker dog som om man må via

AppStudio for å publisere til de ulike plattformene.

Når det gjelder guider til hvordan man kommer i gang, er dette lett tilgjengelig på FeedHenrys

hjemmesider. Det er også mulig å lage applikasjoner basert på ulike maler. Disse malene er også

fullverdige applikasjoner som viser forskjellig funksjonalitet – alt fra enkel utskrift til kommunikasjon

med server og visning i kart.

2.3.2 Modenhet

Nyeste versjon av rammeverket, versjon 2.0, kom ut 27. april 2011. Den største nyheten i denne

versjonen var støtte for Windows Phone 7. Det er med andre ord kun vært støtte for dette i noen

måneder. Rammeverket er tilsynelatende bygget opp etter samme modell som mange selskaper

utvikler mobile applikasjoner: én om gangen.

Dette reflekteres i hvor utbredt støtten for APIer til de ulike plattformene: Det er det full støtte for

Android og iOS, nesten full for Blackberry, mens Windows Phone ligger langt etter. Flere sentrale

APIer støttes pr. januar 2012 ikke, deriblant Geolocation og panorering av skjerm [8]. Det er riktignok

planlagt, men noen releasedato er ikke gitt.

FeedHenry er et ungt selskap, og dette gjenspeiles i størrelsen på communityet rundt. Det finnes et

forum på hjemmesiden, samt et senter for ofte stilte spørsmål. Men utvalget er ikke overveldende.

Noen spørsmål og svar finnes, men sammenliknet med store aktører, er det nærmest ingen ting.

Et annet problem med støtten de tilbyr, er at det er veldig rettet mot Android og iOS [9]1. Det finnes

veiledere for installasjon og publisering av applikasjoner til disse plattformene, men ikke til for

eksempel Windows Phone. Appstudio har heller ingen Windows Phone Emulator, noe som er

betenkelig.

Når det gjelder utbredelse, er selskapet foreløpig mest kjent innenfor Storbritannia. Et raskt overblikk

på samarbeidspartnerne deres vitner om dette: Samtlige selskap er britiske, og selv om det er en viss

størrelse på noen, tyder dette på at FeedHenry ikke er særlig utbredt enda.

2.3.3 Oppsummering

FeedHenry er et irsk selskap som tilbyr kryssplattformutvikling til Android, iOS, Blackberry og

Windows Phone 7 i nettskyen ved hjelp av HTML5, CSS3 og Javascript. Selskapet tilbyr forskjellige

utgaver av sin tjeneste, både gratis og månedsbaserte abonnementer. Selv om utvikling primært

foregår i skyen, er det også mulig å bruke utviklerverkøyet Eclipse ved hjelp av en plug-in.

Rammeverket er for øyeblikket ute i versjon 2 [10], og hadde før dette ikke støtte for Windows

Phone. Derfor er ikke integrasjon av APIer fullverdig for denne plattformen pr. januar 2012, men det

1 Se kilde for eksempel

14

er planlagt. Det er også særdeles lite støtte å hente på nettsidene deres og i forumet om utvikling til

Windows Phone. I tillegg finnes det ingen Windows emulator i Appstudio2.

Fordeler Ulemper

Benytter kjente teknologier (HTML, CSS, Javascript).

Lite støtte for IDE’er; kun Eclipse ved hjelp av nedlasting av plugin.

Støtter i utgangspunktet alle aktuelle plattformer Må via nettskyen for å publisere.

Har gratisversjon. Foreløpig liten støtte for APIer til Windows Phone 7.5.

Finnes demoversjon som alternativ til betalingsløsning (for bedrifter).

Generelt lite støtte for annet en Android og iOS på nettsidene.

Har støtte for forskjellige rammeverk til bygging av brukergrensesnitt.

Lite utbredt; både community og samarbeidspartnere

Ingen Windows Phone emulator i Appstudio.

Tabell 3: Fordeler og ulemper ved FeedHenry

2.4 Kony

Kony ble etablert i 2007 av den suksessfulle entreprenøren, Raj Koneru,

som forstod at håndholdte plattformer ville fortsette å vokse

eksponentielt i fremtiden. Konys visjon er ”Write Once, Run Everywhere”

som har vist seg å fungere veldig bra. De har hovedkvarter i Orlando,

Florida samt kontor i San Mateo, California og Hyderabad, India. Kony ble tilgjengelig i 2009 etter å

ha fullført utviklingen av sin software.

KonyOne, som er deres utviklingsverktøy, er veldig åpen i forhold til om du vil programmere native,

web eller hybrid. Det er 100 % felles kode, dvs. at kryssplattformutvikling støttes fullt ut.

Verktøyet benytter seg av HTML5 og CSS3, i tillegg til JavaScript. De har støtte for alle de syv store

operativsystemene [11].

KonyOne har tilgang til flere elementer som datalagring, notifikasjoner (push-varsler) og Geolocation.

En oversikt over spesifikk API-støtte for enhver plattform fantes ikke, men de har en oversikt over

viss API-tilgjengelighet [12].

2 Vi registrerte oss på hjemmesiden og testet.

Figur 4: Logo Kony

15

2.4.1 Tilgjengelighet

I forhold til nedlastning og installasjon finnes det svært lite informasjon. Man må kontakte dem via

deres hjemmeside for å få tilsendt en demo. Dette gjøres ved å fylle inn et skjema og sende til dem

via hjemmesiden [13].

De sikter nok ikke til private utviklere i samme grad som de fokuserer på større, etablerte selskaper.

Under ”About us” finner du informasjon som for eksempel ”To date, about 70 percent of the U.S.

airline industry has migrated to Kony”. Du finner også overskrifter som ”Solutions for every industry”

som sier litt om hva deres markedsgruppe er. De driver innenfor både bilindustrien, bank og

helsesektoren, etc.

Kony er Eclipsebasert og har full støtte for OS-native, hybrid og wrapper-applikasjoner. Ut i fra deres

hjemmeside kan det også virke som de benytter seg av noe kalt KonyOne Studio som er deres IDE.

2.4.2 Modenhet

Kony er i mye mindre grad kjent enn sine konkurrenter som RhoMobile og PhoneGap. Mer

informasjon om Kony er det ikke lett å finne, sett bort i fra deres hjemmeside.

KonyOne er nå ute i versjon 4.0. Verktøyet har vært tilgjengelig siden de lanserte første versjon i

2009.

I motsetning til PhoneGap og Appcelerator hvor du finner informasjon om hva forskjellige brukere

syns om verktøyet, er dette ikke tilfellet for Kony. Det er mye vanskeligere å finne ut hva andre syns

om verktøyet. Nesten det eneste stedet man kan lese om Kony og KonyOne er på deres hjemmeside

[14].

2.4.3 Oppsummering

Vi kan konkludere med at dette verktøyet ikke passer for vår oppgave. Vi tok det med i vurderingen

vår pga. OS-støtten til både iOS, Android og Windows Phone. Kony var også nevnt i en oversikt over

gode kryssutviklingsverktøy.

Deres hovedsatsning er på store industrier som fly- og bilselskap. Det skal sies at det var relativt mer

arbeid i å få tak i verktøyet i forhold til andre kandidater. Rundt verktøyets API-støtte var det også

nokså diffust.

I første øyekast virket Kony som en verdig kandidat, men etter litt mer etterforskning forstod vi at

dette kanskje ikke var tilfellet. KonyOne var lite utbredt med tanke på brukervurderinger på forum

osv. Vi tok også kontakt med de etter en stund. I tillegg til at det tok lang tid før vi fikk svar, var også

svaret langt i fra tilfredsstillende. Vi fikk kun en standardisert mail med link til deres nettsider.

På dette tidspunktet virker det som vi har andre, bedre verktøy vi tar med videre til sammenligning.

16

Fordeler Ulemper

Veldig fleksibel - kan programmere nativ, web eller hybrid

Liten informasjon om nedlastning og bruk

Støtter alle OS Ikke særlig tilgjengelig

Felles kodebase Ikke gratis - må ha lisens

Lite utbredt

Tabell 4: Fordeler og ulemper ved Kony

2.5 Rhodes

Rhomobile er et amerikansk selskap som ble opprettet i oktober 2008. De

bygger på Open Source mobilapplikasjoner, kan lastes ned til både

Windows og OSX [15]. Disse er native applikasjoner (ikke web-

applikasjoner) som fungerer med synkroniserte lokale data og drar nytte

av enhetens funksjoner, som for eksempel GPS, kamera, kartlegging,

push varsler og kalender.

Rhomobile tilbyr også integrasjonen RhoConnect [19], som gjør det enklere å koble applikasjoner opp

mot en server. Dette eliminerer noe av arbeidet for å koble til, hente, analysere og håndtere lokal

datalagring i applikasjonene. Ifølge Rhomobile er RhoConnect den raskeste og mest skalerbare

integrasjon serveren på markedet. Rhomobile Rhodes er basert på programmeringsspråket Ruby.

HTML5 og CSS3 brukes i tillegg.

2.5.1 Tilgjengelighet

Rhomobile i seg selv er gratis og innstallasjonsfilen RhoStudio kan lastes ned på nettsiden deres [17].

Men for å publisere tar de 1000$ pr. applikasjon [21]. RhoStudio inneholder alle Rho-produkter, som

for eksempel Rhodes og RhoConnect. Programmet skal være uproblematisk å installere med et nokså

standard oppsett, både på Windows og OSX.

RhoStudio er en Eclipse installasjon, og gir et integrert utviklingsmiljø (IDE) for både utvikling av

Rhodes og RhoConnect.

På hjemmesiden til Rhomobile tilbyr de veiledning til hvordan verktøyet skal brukes [18]. De viser deg

blant annet hvordan du skal installere verktøyet, generere applikasjoner, bruk av RhoConnect og

oppbygning av selve programmeringskodene.

Selskapet tilbyr også en mulighet for utvikling av applikasjoner uten å installere noe på

datamaskinen. Rhomobile RhoHub gjør det mulig å programmere og kjøre koden på nettsiden deres.

Via RhoHub tilbys det løsninger i Cloud.

Figur 5: Logo Rhomobile

17

2.5.2 Modenhet

Verktøyet har vært tilgjengelig siden oktober 2008, og har siden den gang blitt nedlastet over 50 000

ganger. Nå brukes det aktivt av over 20 000 utviklere.

Rhomobile Rhodes er ute i versjon 3.0, som har fått gode kritikker og er godt kjent i nettsamfunnet.

Rammeverket har også vunnet Fukuoka Ruby Award i 2010, det er en pris som er skapt for å

promotere og skape mer offentlig oppmerksomhet rundt det relativt ukjente og voksende

programmeringsspråket [16].

Selv om Rhomobile er et selskap med bare 3 års historie, så er det nokså godt utbredt og velkjent av

mobilapplikasjonsutviklere verden over. Det gis god informasjon om produktet og tilbys bra hjelp og

øvelser på nettsiden.

2.5.3 Oppsummering

Rhomobile er et amerikansk selskap som tilbyr kryssplattformutvikling til alle plattformer ved hjelp

av Ruby, CSS3 og HTML5. De tilbyr et gratis fullversjonsprogram ved navn Rhomobile RhoStudio, som

blant annet inneholder Rhodes (rammeverk) og RhoConnect (integrasjonsserver). Dette programmet

har en versjon til både Windows og OSX, og kan lastes ned på nettsiden.

Verktøyet har et godt omdømme og brukes for tiden av over 20 000 utviklere verden over, tross at

rammeverket bygger rundt det forholdsvis ukjente programmeringsspråket Ruby. Det er også mulig å

utvikle og kjøre applikasjoner online på nettsidene deres i cloud via RhoHub.

Etter den opprinnelige screeningen var Rhomobile en reell kandidat, men i ettertid fant vi et

dokument på hjemmesiden som strider imot det inntrykket vi hadde [22]. Dessverre oppdaget vi ikke

dette før et godt stykke ut i utredningsprosessen. Det resulterer i at Rhomobile ikke lenger var en

kandidat. Rammeverket hadde vært en stor kandidat for prosjektet om de hadde gitt like god støtte

til WP7 som de andre plattformene.

Fordeler Ulemper

Gratis

Ruby (ukjent programmeringsspråk)

API-støtte Eneste IDE som er støttet er Eclipse

Tutorials og guidelines tilgjengelig Støtter ikke Windows Phone fullt ut.

Rammeverk som fungerer på både OSX og Windows

Godt kjent i på forum og hos mange utviklere

IDE-støtte

Tabell 5: Fordeler og ulemper

18

Figur 6: Logo PhoneGap

2.6 PhoneGap

PhoneGap (også kalt Apache Cordova) er et open source rammeverk til mobil

som er utviklet av Nitobi Software [23]. Det skal nevnes at bl.a. flere fra IBM,

RIM og Microsoft også bidro. PhoneGap ble først sluppet i 2005, mens

lanseringen på v1.3.0 var 19. desember 2011. Det ble først utviklet på en

såkalt iPhoneDevCamp-event i San Fransisco. De har i tillegg vunnet en

anerkjent pris3. Rammeverket blir brukt av flere mobile applikasjonsplattformer som Worklight og

appMobi. PhoneGap er ganske anerkjent på verdensbasis med over 600 000 nedlastninger av koden,

og med tusenvis av apps på mobile App Stores.

Programmeringsspråkene som brukes er JavaScript, HTML5 og CSS3. Operativsystem som støttes er

bl.a. iOS, Android, Windows Phone 7 og BlackBerry. Til de tre førstnevnte OS’ene, som er de

plattformene vi skal utvikle til, er følgende elementer tilgjengelige:

Kamera

Geolocation

Notifikasjoner

Nettverk

Accelerometer (for å presentere skjermbildet i landscape eller portrait)

Lagring m.m.

Se komplett liste på PhoneGap sine nettsider [24].

Enkelte metoder kan gi forskjellig resultat på de ulike plattformene. Dette har noe med

oppbygningen av telefonenes operativsystemer å gjøre – det er ikke en konsekvens av oppbygningen

til PhoneGap.

PhoneGap brukes til å lage native applikasjoner med webteknologier4, og har tilgang til API og app

stores. De bruker standardbasert webteknologi for å bygge sammen webapplikasjoner og mobile

enheter. Med PhoneGap blir all kode felles for de tre plattformene siden det er utviklet i JavaScript

og HTML.

PhoneGap har også en service kalt PhoneGap Build som gjør at du kan kompilere kode i skyene

(Cloud Compiling). Dette gjør at du slipper unna med å installere SDK’er, kompilatorer og annet

software. Du skriver din app med HTML, CSS og JavaScript, laster den opp til PhoneGap Build, og får

tilbake App Store klare applikasjoner til iOS, Android, etc.

2.6.1 Tilgjengelighet

PhoneGap er open source (åpen kildekode) og helt gratis å bruke. Utviklere og selskaper kan bruke

PhoneGap til mobile applikasjoner som er gratis, open source, kommersiell, eller hvilken som helst

kombinasjon av disse.

3 People’s Choice Award på O’Reilly Media’s 2009 Web Conference 4 Med webteknologier menes her HTML5, CSS3 og JavaScript

19

I tillegg til å ha flere ”communities” som PhoneGap Google Group, finnes det også muligheter for

betaling av supportpakker. Har man spørsmål angående utvikling, er den beste måten å få kontakt

med de på Google Group. Basic, Pro og Enterprise er eksempler på supportpakker de tilbyr [25].

Prisen varierer fra $24.95 til $1,995 i måneden.

Installasjon av rammeverket virker meget gjennomførbart. De har også en side med en ”Get Started

Guide” der du kan velge plattform og få en brukervennlig gjennomgang av installasjonen.

De har full støtte for integrasjon med IDE. Du kan bruke Xcode til iOS, Eclipse til Android og Visual

Studio til Windows Phone. Det eneste man trenger å laste ned er SDK og plugin til tilhørende

plattform.

Som tidligere nevnt finnes det muligheter for kompilering i skyene med PhoneGap Build.

2.6.2 Modenhet

Verktøyet har vært tilgjengelig siden det ble introdusert i 2008. De har stadig lagt til nye funksjoner

og støtte for flere plattformer. Den siste versjonen 1.3.0 ble lansert 19. desember 2011. Dette er

forresten en fullversjon, ikke en betaversjon. I skrivende stund har de kommet med en ny versjon

som har ordnet en del bugs, versjon 1.4.1. Det er tydelig at de jobber aktivt med å utvikle det.

PhoneGap har mange brukere og er godt etablert. Ved å sjekke nettsamfunn som Twitter og

Facebook ser vi at PhoneGap er på toppen når det gjelder følgere/brukere sammen med blant annet

Appcelerator Titanium. Noen mener at Titanium er bedre på den måten at det bare skrives i

JavaScript, mens PhoneGap har HTML og CSS i tillegg. PhoneGap er på den andre siden tilgjengelig på

flere mobile plattformer siden applikasjonen er nettbasert.

PhoneGap er alltid nevnt på lister som ”Best Cross-Platform Mobile Development Tools” og er ofte

blant topp 5, hvis ikke de faktisk er på topp. De er anbefalt på flere forum på nettet i tillegg.

2.6.3 Oppsummering

Alt i alt virker det som PhoneGap er et av våre beste alternativer. Vi skal tross alt programmere til tre

forskjellige plattformer. De har mange brukere, er veldig utbredt og de har gode supportforum som

PhoneGap Google Group [26] og PhoneGap sine wiki-sider [27].

PhoneGap har veldig god API-støtte til alle plattformer, og det brukes til å lage native applikasjoner.

Vil man programmere og kompilere i skyene, har man mulighet til dette via PhoneGap Build.

Det er gratis å laste ned og installere verktøyet, så det er helt klart en fordel. De støtter integrasjon

med IDE, som Eclipse og Xcode. Og ut i fra diverse topplister ser vi at PhoneGap stadig er nevnt, noe

som må være positivt.

Slik vi har snakket sammen er vi relativt sikre på at PhoneGap blir en av våre 3 kandidater til mer

utdypende screening.

20

Figur 7: Logo Mono

Fordeler Ulemper

Bruker HTML, CSS, JavaScript - som er forholdsvis kjent

Hvis man vil ha tilgang til supportpakker, koster dette relativt mye

Fungerer på alle plattformer

Godt etablert, mye brukt

Gratis

Bra tutorials på deres hjemmeside

God API-støtte

Felles kodebase for alle plattformene

Tabell 6: Fordeler og ulemper ved PhoneGap

2.7 Mono

Mono er et open source prosjekt som ble startet i 2001 og gitt ut første

gang i 2004, og som nå ledes av Xamarin. Xamarin ble startet opp i 2011 av

utviklerne av Mono, MonoTouch og Mono for Android [28].

Man kan bruke Visual Studio, og bruke C# og .NET. Man må linke tre prosjekter; Android, iOS og

Windows Phone. Man kan builde alle prosjektene. Det finnes ikke emulator til iPhone (iOS) i

Windows, så dette må man bruke f.eks Xcode på Mac til.

Dette er litt tungvint, for man må uansett bruke både Mac og Pc. Det er felles businesslogic, men

man må lage UI og API-integrasjon for hver enkelt. Man kan ikke lage en iPhone-app i windows, og

man kan ikke lage en Windows Phone app på Mac. Den koden som deles mellom plattformene, deles

ved hjelp av linkede filer/prosjekter.

På Xamarin sin hjemmeside kan man laste ned MonoDevelop [29].Det er basert på tidligere Mono.

Det er veldig likt Visual Studio. Det har Source Control, intellisense, GUI (integrert Gtk#). Man kan

enkelt bruke XML-filer. Programmet kan også brukes til utvikling av webapplikasjoner. UI er ikke

krysskompatibel.

2.7.1 Tilgjengelighet

Mono kan kodes i Visual Studio, og Xcode på Mac. Man laster enkelt ned og installerer plugins i VS

for Android og Windows Phone for å få IDE-støtte.

MonoDevelop kan lastes ned som trial-versjon på hjemmesiden til Xamarin. For fullversjon koster det

fra $399 for hvert av produktene (MonoTouch [31] og Mono for Android [30]).

21

2.7.2 Modenhet

Det har kommet flere versjoner siden 2004. Da brukte man Visual Studio med plugins for å kunne

utvikle på alle de tre plattformene. Det fungerer fortsatt fint å utvikle Mono med dette programmet.

Ellers så har Xamarin gitt ut sin 3. versjon av MonoDevelop i løpet av 2011. Programmet minner

veldig om Visual Studio, og er basert på tidligere Mono. Det er mye aktivitet på begge hjemmesidene

(Mono-Project [32] og Xamarin [33]). Det finnes flere nettsider med artikler, videoklipp, linker osv.

Det virker veldig utbredt, det er mange store firmaer som bruker Xamarin (blant annet Microsoft,

Accenture, 3M, HP osv) til utvikling av apps.

2.7.3 Oppsummering

Mono er et open source prosjekt som ble startet i 2001 og gitt ut i 2004. Nå ledes det av Xamarin.

Xamarin ble startet opp i 2011 av utviklerne av Mono, MonoTouch og Mono for Android.

Mono er et godt utviklet rammeverk, med mange brukere. Det er lett å finne informasjon på forumer

og nettsider.

Man utvikler med C# og .NET. Man kan enten bruke Visual Studio med plugins, eller MonoDevelop

som koster $399 pr lisens. Man må kjøpe for både Android og iOS, og er avhengig av å bruke både

Mac og PC. UI er ikke krysskompatibelt, så dette er ikke en 100 % kryssutviklingsløsning.

Fordeler Ulemper

Mye tilgjengelig informasjon, mange som har utviklet med dette rammeverket.

Rammeverket er ikke krysskompatibelt på UI-laget.

Kan lage apps for alle aktuelle plattformer Må aktivt benytte både Mac og Windows

Bruker C# som de eneste på markedet API må utvikles for hver plattform

IDE-støtte

Gratis?

Støtte for tredjeparts-biblioteker

Tabell 7: Fordeler og ulemper ved Mono

2.8 Konklusjon

Ut i fra det vi har skrevet om de ulike rammeverkene har vi utarbeidet en rangering basert på en

poengsum slik som beskrevet tidligere i rapporten (se avsnitt 1.2). I tabellen under er sammendraget

av denne poenggivningen (Tabell 8). En mer detaljert tabell er vedlagt (Vedlegg B – Rangering etter

kartlegging). De tre kandidatene som går videre til utredning med utvikling av testapplikasjon er de

med best poengsum.

22

PhoneGap vil la oss lage en native applikasjon med teknologier benyttet i vanlig webutvikling. Dette

gjør at vi kan dra nytte av tredjeparts biblioteker som for eksempel JQuery. Av de rammeverkene vi

har sett på er dette også det som dukker opp i flest sammenhenger og de virker å ha en meget solid

brukerbase med mye støtte.

webMethods Mobile Designer benytter Java til programmering. De har en unik krysskompilator som

de andre rammeverkene ikke kan skilte med. De har støtte for tredjeparts biblioteker. Det skal

nevnes at dette rammeverket var bak Rhomobile etter den opprinnelige screeningen, men at ny

informasjon førte til at vi måtte bytte ut Rhomobile (se avsnitt 2.5.3).

Mono er det eneste C# baserte rammeverket vi har kommet over. Det utnytter en helt annen måte å

dele kode på enn de to ovennevnte ved at man har tre forskjellige prosjekter; et MonoTouch, et

MonoDroid og et Windows Phone prosjekt. Ved å bruke teknikker som linkede prosjekter deler man

kode mellom disse, men man vil ikke få 100 % felles kode.

Tabell 8: Sammendrag av poenggivning

3 Utredningen

Dette kapitlet tar for seg den grundige utredningen som ble gjort via utvikling av testapplikasjoner. Vi

går igjennom hvert rammeverk og kommer med en vurdering av hvilket vi mener er best i

konklusjonen til slutt.

3.1 Generelt om plattformene

I dette avsnittet gis en kort beskrivelse av hvordan man utvikler applikasjoner til Android, iPhone og

Windows Phone. Vi mener det er en fordel å vite hvordan plattformene fungerer selv om man skal

jobbe med rammeverk for kryssutvikling.

3.1.1 Android

For å utvikle til Android trenger man bare å laste ned Android SDK [34] – det er ikke nødvendig å løse

utviklerlisens. Nedlastingen er dog noe spesiell: Man får en SDK manager som kan benyttes til å laste

Kryss-kompatblitet

Tilgjengelig-het

Moden-het

API-støtte

Tekno-logi

Sum

PhoneGap 10 8,8 9,5 9 8 9,1

Mono 7 8,8 8 8 9 8,2

webMethods 8 6,8 8,8 10 6 7,9

Rhomobile 3 8 7,8 8 7 6,8

Kony 10 2 4 9 8 6,6

CloudPact 10 2,4 1 10 8 6,3

FeedHenry 3 4,6 3 8 8 5,3

23

ned SDK’er til ulike versjoner. Vi anbefaler minimum å laste ned til versjon 2.2 og 4.0.35. Flere kan

lastes ned etter behov. Det viktigste er at man sørger for å få med Google API’en til hvert nivå slik at

man får støtte til kart.

Utviklingsmiljøet Eclipse anbefales til Android [35], men det er også uproblematisk å bruke NetBeans

[36]. Vi har likevel hatt et lite problem i forbindelse med NetBeans; når man oppretter et nytt

prosjekt er det en fil som mangler. En enkel ”clean and build” av løsningen fikser dette (Figur 8).

Figur 8: Feilmelding. Filen til høyre genereres ved "clean and build"

Som sagt trengs det ingen utviklerlisens til Android, men man må signere applikasjonene sine med en

digital nøkkel for å få applikasjonen ut på device. Vi anbefaler å benytte device til testing, for selv om

det finnes en emulator, er denne meget treg og kronglete å jobbe med. Man trenger ikke å generere

et eget nøkkelpar for testing – det følger med en debug nøkkel som kan brukes [37]. Før man kan

teste på device, må man gjennom et par enkle steg for å sette opp prosjektet og telefonen for debug

[38]. For å installere appen på telefonen må man via kommandolinjen [39], så dette er noe

vanskeligere enn den tilsvarende operasjonen på iPhone og Windows. Fordelen er at man ikke

trenger å installere noe ekstra programvare slik som iTunes og Zune Music til henholdsvis iPhone og

Windows Phone.

Skal man teste bruk av kart må man ha en API nøkkel fra Google [40]. Dette er stort sett

uproblematisk, men hvis man bruker Java JDK 1.7 får man sertifikat med SHA1 kryptering. Den

letteste måten å fikse dette på er å benytte keytool programmet som finnes i 1.6 versjonen.

Vi støtte på en del problemer med Android plattformen. Det første gjaldt installering av drivere. Vi

har testet på HTC Sensation, HTC Desire S og Samsung Galaxy Note, og samtlige fikk feil i den

automatiske installasjonen av USB driveren. Det er mulig å laste ned en driver via SDK Manager [41],

men denne dekker ingen av de nevnte telefonene. Løsningen er å lete på nettet. For HTC vet vi at

driveren for HTC Hero fungerer [42].

Det andre store problemet var emulatoren. I motsetning til de andre plattformene, kan man lage

flere emulatorer avhengig av hvilke elementer man skal teste. Man kan også velge hvor stor

lagringsplass denne skal ha. Her kan det være greit å ta i litt: 256 MiB har fungert best for oss. Men

uansett er den veldig treg, selv om den er relativt rask når den først er oppe og går. Enkelte av oss

5 API-level 8 og 15

24

slet med i det hele tatt å starte en emulator. Løsningen var å sørge for at man har satt riktige PATH

variabler (Figur 9). Vi anbefaler uansett å teste rett på device.

Figur 9: Eksempel på PATH

3.1.2 iPhone

For å kunne begynne med å utvikle apps til iPhone, må man være registrert i Apple Developer Portal

[43]. Dette er en Apple-konto som man også bruker til App Store. Det eneste man trenger å gjøre er å

oppgradere kontoen til Developer så får man rettigheter til diverse programmer til din Mac.

Utviklingsmiljøet det er lagt opp til å bruke er Xcode [44], og som standard er det Cocoa som brukes

som rammeverk. Programmeringsspråket er Objective-C. Det er mulighet for å lage applikasjoner til

både iPhone, iPad og Mac.

Man trenger ikke å tenke på å laste ned SDK, plugins eller annet software for å programmere til

iPhone. iOS SDK og alt annet som trengs følger med når du laster ned Xcode fra Apple sine nettsider.

Xcode har i tillegg med Interface Builder som gjør det enklere å lage brukergrensesnittet til

applikasjoner. Med hjelp av drag’n drop kan du lage alt det grafiske som knapper, menyer, ”Tab Bars”

etc.

En annen viktig funksjon er simulatoren som følger med programvaren. Dette gjør det mulig å

kjøre/teste applikasjoner på en virtuell smarttelefon. Med denne kan du velge om du skal simulere

en iPhone, iPhone Retina (4/4S) eller iPad. Du kan også panorere skjermen i tillegg til å ”riste

telefonen” for å sjekke diverse funksjonalitet som fungerer på en smarttelefon. En annen positiv

egenskap ved simulatoren er at den er veldig rask. Det er også mulig å teste Geolocation på den. Din

posisjon vil da vises som hovedkvarteret til Apple.

Skal du derimot teste appen din på device, for eksempel på en ekte iPhone, må du betale for en

utviklerlisens som du kan kjøpe for 99$ i året for enkeltpersoner [45] eller 299$ for selskaper [46].

Det er en del jobb å få denne lisensen og få registrert en enhet som du kan pushe apps til. Men Apple

har en fin brukerveiledning du kan følge for at alt skal gå riktig for seg [47].

Det siste som bør nevnes er at filen ”[prosjektnavn].plist” inneholder egenskapen External Hosts

(Figur 10). Her må man legge til nettsider/linker for at du skal kunne bruke for eksempel Google

Maps, lese RSS etc. En stjerne (*) vil si at at du åpner for alt.

Figur 10: External Hosts

25

3.1.3 Windows Phone

Utvikling til Windows Phone krever at du laster ned SDK fra Microsoft sine nettsider [48]. Denne

SDK’en integreres med Visual Studio, som må være installert fra før for at integreringen skal gå

smertefritt. Prosessen til nedlasting og installasjon er veldig enkel. Filen som lastes ned er kun på

3mb og dermed går installasjonen kjapt. I SDK følger det med en WP7 emulator som kan brukes for å

teste ut applikasjonen i de fleste rammeverk underveis i utviklingen. Denne emulatoren er nesten

like rask som en device.

For å starte et prosjekt for utvikling av WP7 er det bare å opprette et Silverlight for Windows Phone-

prosjekt på vanlig måte i Visual Studio. Utviklingsprosessen er så å si lik som å lage en vanlig

Silverlight applikasjon med XAML til brukergrensesnitt og C# som logikk.

For å kunne bruke Bing-kart på Windows Phone 7 må man gjennom en tilsvarende prosess som på

Android [49], bare at det er noe enklere. Det er også muligheter for å bruke google kart i

applikasjonene [50], men da må du ha en API-key [51].

For å kunne deploye en applikasjon til device kreves det at du anskaffer en utviklerlisens [52] som gir

deg tilgang til dette. Etter du har kjøpt denne er det noen krav du må møte før du kan deploye

applikasjonen; enheten må registreres [53], enheten må kobles til datamaskinen og du må ha Zune

installert på datamaskinen for å kunne få kommunikasjon mellom enheten og datamaskinen [54].

3.2 PhoneGap

3.2.1 Komme i gang

For å komme i gang med PhoneGap, er det noen steg man må igjennom. Dette avsnittet beskriver

denne prosessen på de ulike plattformene.

3.2.1.1 Android

Android må utvikles i Eclipse eller Netbeans. Tutorial for hvordan man kommer i gang på

hjemmesiden til PhoneGap er lagt opp for Eclipse [55]. Vi støtte på en del problemer når vi brukte

denne, så vi brukte heller en mer omfattende tutorial [56]. Vi fulgte den, og det fungerte helt greit

også i Netbeans.

Det vi merket oss når vi opprettet prosjektet var at Package Name må bestå av to navn/ord uten

mellomrom, og med punktum i mellom. I tutorialen blir man bedt om å opprette mappen libs, men

det trenger man ikke, det opprettes automatisk en mappe som heter Libraries når man lager et nytt

Android-prosjekt. På figuren nedenfor (Figur 11) ser man mappestrukturen. www-mappen er den

sentrale.

26

Figur 11: Mappestruktur Android-prosjekt med PhoneGap i NetBeans

I filen AndroidManifest.xml skriver man inn de ulike tilgangene man trenger i uses-permission-tagger

(Kodelisting 1). Her er et eksempel på ulike permissions, men man trenger som regel ikke alle disse.

Testappen vår trengte ikke mange av disse.

27

Kodelisting 1: AndroidManifest.xml med permissions

Det kan virke unødvendig tungvint å måtte gå igjennom alle disse stegene hver gang man skal lage et

nytt prosjekt. Dette var også vi skepiske til. Men det er mulig å lage et standard prosjekt og bruke

dette som en template for senere prosjekter. I NetBeans er det ikke mulig å lage prosjekt og velge

"from existing source", man må kopiere og rename. Dette er dog ikke problematisk i forhold til å gå

igjennom alle nødvendige steg for hvert prosjekt.

3.2.1.2 iPhone

Når du skal utvikle til iPhone med PhoneGap-rammeverket er det lagt opp for å bruke Xcode. I

PhoneGap-mappen som man laster ned, kan du navigere deg til katalogen med navnet ”ios” og kjøre

.dmg-filen for å installere PhoneGap for iOS. Det er det eneste man må gjøre for å få lage PhoneGap-

baserte applikasjoner på Mac.

På PhoneGaps hjemmeside har de en god tutorial på oppsett av prosjekt til iOS [57]. Det er en såpass

god tutorial at vi bestemte oss for at det var unødvendig å beskrive gjennomgangen her. Vi tar bare

for oss ting som er utelatt i PhoneGaps guide, og som ikke forklarer seg selv.

Når du er ferdig med å sette opp et PhoneGap-basert prosjekt, skal filstrukturen se ut noe som dette

(Figur 12):

28

Figur 12: Filstruktur på prosjektet

Det er generelt veldig lett å opprette nye prosjekt til iOS-plattformen. Det meste går av seg selv. Etter

at du har dratt over www-mappen til Xcode, så er du klar.

Noe som ikke gjennomgås i tutorialen er hvordan man setter at prosjektet skal støtte forskjellige

orienteringer6. Hvis du står i roten7 av prosjektet i Xcode, bør du se et skjermbilde (Figur 13) som lar

deg velge forskjellige orienteringer som skal støttes.

6 Panorering av skjerm, portrait eller landscape 7 Roten er markert i Figur 12

29

Figur 13: Prosjektegenskaper

Her er det bare å klikke på de orienteringene man vil prosjektet skal ha støtte for. På samme side er

det også muligheter for å sette egne ikoner og oppstartsbilder.

3.2.1.3 Windows Phone

I zip-filen som inneholder PhoneGap-rammeverket finner man filen PhoneGapStarter.zip i Windows-

mappen. Denne er en project template for Visual Studio på lik linje med de templates som hører til

vanlige C# prosjekter. I start guiden [58] står det at zip-filen skal kopieres til en Silverlight for

Windows Phone-mappe som ikke eksisterte på det stedet guiden påstår8. Den fantes riktignok et

annet sted9, men å lime inn PhoneGapStarter.zip her ser ikke ut til å virke. For å få frem

PhoneGapStarter i Visual Studio kopierte vi først hele Silverlight for Windows Phone-mappen inn på

det stedet guiden sier den skal. Da fikk vi den frem, men vi fikk også duplikater av hver eneste vanlig

Windows Phone template. For å fjerne disse igjen er det bare å slette de fra den kopierte mappen.

8 C:\Users\[USERNAME]\Documents\Visual Studio\2010\Templates\ProjectTemplates\Silverlight for Windows Phone 9 C:\Users\Program Files(x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\CSharp\Silverlight for Windows Phone

30

Når alt er satt opp, lager man et nytt PhoneGap-prosjekt på samme måte som ved oppretting av

vanlige Visual Studio-prosjekter. Blant mappene og filene (Figur 14) som opprettes finner man www-

mappen som er felleskomponenten mellom samtlige plattformer.

Figur 14: Mappestruktur Windows Phone PhoneGap prosjekt

Alle JavaScript-, HTML- og CSS-filer skal inn her. I prinsippet veldig enkelt, men vi stiller

spørsmålstegn ved hvorfor det ikke er mulig å legge til nye filer av disse typene direkte. Man må

enten kopiere en av de filene man allerede har og så endre navn, eller så kan man ha et asp.NET

webprosjekt i samme løsning hvor man kan opprette slike filer. Disse kan så legges til PhoneGap-

prosjektet ved å velge ”add existing item”.

Et siste problem vi støtte på var at linker til andre HTML-sider ikke alltid fungerte. Ved å legge på

’rel=”external”’ i a-tagen (Kodelisting 2) omgikk vi det problemet. En mulig årsak til problemet kan

være at det ikke er samsvar med filen GapSourceDictionary og navnet til HTML-filen man prøver å

navigere til. Hvis problemet skulle oppstå når rel-attributten ikke er satt, anbefaler vi å sjekke denne

filen først.

Kodelisting 2: "rel" attributt

31

3.2.2 Utviklingsprosessen

PhoneGap var utfordrende for oss i og med at det er lite IntelliSense i JavaScript. Dermed blir det

vanskelig å finne aktuelle metoder og attributter. Videre er det lite muligheter for debug, men det er

mulig å bruke plugins i nettlesere10. Da får man ikke debugget PhoneGap sine JavaScript-metoder. En

av fordelene med JavaScript, HTML og CSS er at du nokså fritt kan velge hvilket miljø du vil

programmere i, som Visual Studio, Eclipse, NetBeans osv.

PhoneGap er det klart største rammeverket innenfor kryssplattform, og med det i bakhodet var det

ikke overraskende at det var masse hjelp å få på forum, artikler og andre steder på internett.

Rammeverket har også gode muligheter for Source Control ved bruk av Team Foundation Server,

Subversion eller Git.

Det er fullt mulig å integrere tredjeparts JavaScript- og CSS-biblioteker, deriblant jQuery [59], jQuery

Mobile [60] og Sencha Touch [61]. De to førstnevnte krever ingen nedlastning. De kan bare legges til

ved hjelp av en script- eller link-tag (Kodelisting 3), mens Sencha Touch må lastes ned. Dette fordi

Sencha er et fullverdig rammeverk for utvikling av mobile webapplikasjoner.

Kodelisting 3: Scripttag for å inkludere JQuery

For å få opp kart trengte vi ingen API-key, siden Google Maps sin webversjon ikke krever en nøkkel

[62]. Det er derimot nødvendig å ha denne med hvis du vil overvåke antall ganger kartet blir vist.

Med rammeverket Phonegap har vi muligheten til å få native elementer på iPhone via plugins og

JavaScript, og til Windows Phone via kode i XAML og XAML.cs. Dette finnes foreløpig ikke for

Android. Uansett så vil integrering med native elementer gjøre at mengden felles kode blir mindre. Vi

anbefaler å bruke CSS istedenfor.

Når man skal lime sammen må det opprettes nye prosjekter på de andre plattformene og lime inn

HTML, CSS og egne JavaScript-filer i www-mappen. Dette var metoden vi brukte og det gikk

knirkefritt.

3.2.3 Beskrivelse av APIer

API-biblioteket er et kompakt og lite JavaScript-bibliotek som gir tilgang til de fleste API’ene. Alle de

mest vanlige er med, og det var veldig oversiktlig på hjemmesiden [63]. Man kan i tillegg velge i

mellom de ulike versjonene på den siden, og få frem de aktuelle API’ene og tilhørende

dokumentasjon.

Alle API’ene er tilgjengelig for både Android, iOS og Windows Phone.

Det var enkle JavaScript-kall for å benytte API’ene (Kodelisting 4). Man kan også benytte resultat av

disse metodene videre i vanlige JavaScript-metoder.

10 For eksempel Firebug i Firefox

32

Kodelisting 4 Geolocation

Vi sammenlignet nyeste versjon av PhoneGap (versjon 1.4.1) med den eldre versjonen 1.0.0 (Vedlegg

D – PhoneGap API-sammenlikning). Det var avvik11 fra plattform til plattform i forhold til hvordan

API-kall oppfører seg. Dette hadde de ikke klart å rette opp gjennom de senere versjonene, og vi fant

ut at det var en forklaring på dette.

PhoneGap bruker den samme koden over alle plattformer, men alle plattformene er forskjellig

bygget opp. Derfor vil samme metode gi noe forskjellig resultat avhengig av plattform. For eksempel

er det ikke mulig å angi knappetekst til PhoneGaps alertbox i Windows Phone – den vil alltid vise

”OK” (Figur 15).

Figur 15: Knappetekst på PhoneGaps alertbox for WP7

11 Kalles ”quirks” i PhoneGaps dokumentasjon

33

3.2.4 Testapplikasjonen

Tidlig i prosessen ble det klart at de kravene vi hadde satt til testapplikasjonen ikke ville gi oss noe

fullgodt bilde av hvordan det er å bruke PhoneGap. De elementene nedenfor som ikke samsvarer

med kravspesifikasjonen (Vedlegg A), er med i applikasjonen som en direkte konsekvens av den

vurderingen.

Applikasjonens startmeny (Figur 16) er laget ved hjelp av jQuery Mobile CSS [60] som benytter seg av

HTML5s attributter. Disse brukes til å dele opp sidene i logiske elementer12. Videre er det definert

forskjellige typer datatemaer. Menyvalget for Tema demo tar deg til en side hvor de ulike

standardtemaene demonstreres [64]. Det er også mulig å lage sitt eget ved hjelp av ThemeRoller

[65].

Figur 16: Applikasjonens startside vist på Android emulator

I tillegg til tema siden har vi laget sider som demonstrerer tre API’er som vi ikke har demonstrert i de

andre testapplikasjonene:

Device henter ut informasjon om telefonen [74]

Connection [75] henter ut informasjon om hva slags internettkobling man har. Her

demonstreres også PhoneGaps alert-metode. På iPhone og Android kommer det også opp en vanlig

JavaScript alertbox – denne støttes ikke på Windows Phone. [76]

12 Forskjellige data-roles. Eksempler er page, header, content og footer

34

Camera [77] har som hensikt å vise at det er mulig å starte telefonens kameraapplikasjon fra

PhoneGap. Man kan ta bilde eller velge fra album, men utover det skjer det ingen ting.

De to menyelementene som ikke er omtalt enda er de eneste applikasjonen ville hatt hvis vi ikke

hadde avveket fra kravspesifikasjonen. ”Rss-test”-valget tar deg til en side som henter stillinger fra

RSS-feeden [78] ved hjelp av jQuery AJAX [79]. Vi slet en del med å forstå hvordan man fikk til dette,

så denne metoden er utarbeidet i samarbeid med en utvikler hos WebCruiter. Formatteringen har vi

derimot gjort selv. Vi ønsket å teste hvor mobilvennlig design man kan få til ved bruk av egen CSS

kode (i motsetning til jQuery Mobile og lignende). Resultatet gjorde at vi kan konkludere med at det

er fullt mulig å lage et stilrent design for mobil fra bunnen av (Figur 17)

Figur 17: CSS formattert resultat fra RSS-feed på Windows Phone emulator

For å teste GeoLocation API’et til PhoneGap [80] valgte vi å benytte Google Maps. Dette fordi det var

enkelt og kompatibelt med alle plattformene. Resultatet fra PhoneGap metoden gis videre til en

funksjon fra Google API’et som viser nåværende posisjon i et kart. Metoden vi har brukt til å vise

kartet er kun av demonstrative årsaker. Scrolling og pinching fungerer derfor forskjellig på

35

plattformene. Vi mistenker at dette har noe med måten de individuelle nettleserne13 behandler

bilder på.

Til slutt ber vi leseren legge merke til back-knappen på Windows Phone (Figur 17). Denne er eksklusiv

for Windows og er skrevet i XAML-siden som holder HTML-filene i WP7 applikasjonen. Funksjonen

som ligger bak knappen er en C# metode som kaller en JavaScript funksjon (Kodelisting 5). For at

dette skal virke på alle sider, må JavaScript funksjonen være deklarert i samtlige HTML-sider.

Kodelisting 5: Code-behind i C# som kaller JavaScript-funksjon i HTML-filene

3.2.5 Hva rammeverket egner seg til

PhoneGap egner seg veldig godt for kryssplattformutvikling. Det er 100% felles kode. Dette er mulig

siden kun HTML, CSS og JavaScript blir brukt.

Det egner seg best til apper med hovedvekt på UI og API-integrasjon. Skal man derimot ha mye og

kompleks businesslogikk på klient, egner det seg dårligere. JavaScript har manglende debug og

mangelfull IntelliSense. Derfor blir det kronglete å skrive store og komplekse datastrukturer.

Bruker man PhoneGap anbefales det derfor å ha mesteparten av businesslogikken på serverside. På

den måten kan man bruke JavaScript i applikasjonen til å kommunisere med denne. Det er akkurat

slik vi ser for oss oppbyggingen av WebCruiters applikasjon.

3.2.6 Oppsummering

PhoneGap er et meget godt utviklet rammeverk som er enkelt å ta i bruk. Deling av kode går av seg

selv siden det brukes universelle filformat14. Hvis man ønsker er det også mulig å få innslag av native

elementer på iPhone og Windows Phone. Et lite minus at dette ikke går på Android ved hjelp av

native kode.

13 PhoneGap vises i en kontroll basert på den enkelte telefons nettleser. 14 HTML, CSS og JavaScript

36

Det er meget lett å finne hjelp og støtte om PhoneGap – både fra deres egne sider og ellers på

nettet. API-dokumentasjonen deres [63] er ryddig og oversiktlig. Man kan også få en komplett

oversikt helt tilbake til første offentlige release.

Før vi gikk i gang med utredningen var vi kritiske til måten å opprette prosjekter til Android. Det er

mange filer som skal endres på, mapper som skal opprettes og filer som skal limes inn. For å slippe å

gjøre dette hver gang, anbefaler vi å lage et prosjekt som er ferdig satt opp som kan brukes som en

template for senere prosjekter.

Tabellen under viser revurdert oversikt over fordeler og ulemper ved PhoneGap. Endringer er satt i

fet og kursiv tekst. Ingen punkter er endret eller fjernet – det er kun lagt til nye.

Fordeler Ulemper

Bruker HTML, CSS, JavaScript - som er forholdsvis kjent

Hvis man vil ha tilgang til supportpakker, koster dette relativt mye

Fungerer på alle plattformer Lite IntelliSense og debug-muligheter

Godt etablert, mye brukt Vanskelig å skrive applikasjoner med mye og kompleks businesslogikk

Gratis

Bra tutorials på deres hjemmeside

God API-støtte

Felles kodebase for alle plattformene

Enkelt å integrere med Source Control

Bredt utvalg av utviklingsmiljøer

Tabell 9: Revurdering av fordeler og ulemper

37

3.3 Mono

3.3.1 Komme i gang

Når man jobber med Mono er det ikke noen egen måte å komme i gang med Windows Phone, siden

man bruker et Silverlight for Windows Phone prosjekt. Vi beskriver derfor mer utfyllende hvordan

man kommer i gang med Android og iPhone. Videre beskrives prosessen med å lage mappestruktur i

et typisk Mono kryssplattformprosjekt.

3.3.1.1 Android

Det første man må gjøre er å kjøpe den Mono for Android-lisensen som passer for deg [81]. Da får

man et installasjonsprogram som installerer alle nødvendige komponenter inkludert Android SDK

Manager hvis ikke den finnes fra før [82]. Vi fikk riktignok noen problemer når den ikke fantes fra før,

så vi anbefaler å gjøre dette på forhånd for å unngå dette.

Både i Visual Studio og MonoDevelop har Xamarin laget en egen løsning (Figur 18) for samhandling

med emulator og device. Her støtte noen av oss på et problem; det var ikke noe emulatorbilde å

finne selv om det var opprettet. Vi mistenker at det hadde noe med PATH-variabler å gjøre, så

løsningen ble å teste rett på device.

Figur 18: Mono for Android launcher

Det er verdt å nevne at Mono for Android-prosjekter bruker API-level 8 som standard. Endre dette i

Properties ved behov.

3.3.1.2 IPhone

Att komma igång med MonoTouch var enkelt och simpelt. Man är tvungen att installera det här på

en Mac för att Windows inte kan programmera till iPhone. Installationsprogrammet får du genom att

köpa den licens som passar dig bäst [81].

38

Då får man med MonoDevelop som är IDE lösningen och andra nödvändiga komponenter.

MonoDevelop tillbjuder inte grafiskdesigner till UI byggning som för exempel Xcode sin Interface

Builder. Men du kan öppna en .xib fil från MonoDevelop till Xcode sin Interface Builder (Figur 19).

Figur 19: Exempel på .xib fil

Med MonoDevelop kan man se likheter med Visual Studio, och är användarvänlig. Du känner igen

solutions från Visual Studio och om du har jobbat med det i ett projekt förr.

3.3.1.3 Prosjektoppbygging

For å bygge kryssplattformprosjekter med Mono bør du bruke et vanlig Silverlight for Windows

Phone-prosjekt som utgangspunkt. Jonas Follesø fra BEKK Consulting har utviklet en

kryssplattformapplikasjon [83] som vi har brukt som inspirasjon til strukturering av vårt prosjekt. Han

har også laget en workshop [84] som blant annet viser denne oppbygningen. De viktigste elementene

i denne omfatter linking av filer mellom klassebiblioteker, designpatterns15, Build configurations og

hvordan åpne MonoTouch i VS. Ved å bruke denne oppbygningen vil mappestrukturen se omtrent

slik ut (Figur 20):

Figur 20: Mappestruktur

15 Follesø beskriver MVVM-mønstret, men det viktigste er å skille ut businesslogikken

39

Ved utvikling av slike prosjekter anbefaler vi å gjøre dette fra start. Siden vår testapplikasjon var

såpass liten i omfang, valgte vi å lage prosjektene hver for seg for så å lime de sammen på slutten. Da

støtte vi på noen problemer i de respektive prosjekters filer; det kan bli inkonsistens mellom blant

annet filnavn16.

3.3.2 Utviklingsprosessen

Det ble en del forskjellig koding mellom plattformene, noe som er uunngåelig. IntelliSense er derimot

på nivå med vanlig C#-programmering. Derfor var det rimelig greit å finne fram til objekters

egenskaper og attributter. Det er gode feilmeldinger, men enkelte hendelser hadde for lite eller

kryptisk informasjon(Figur 21).

Figur 21: Mono for Android feil i VS

16 For eksempel står applikasjonsnavnet i XAML-filene på Windows Phone. Disse må da kanskje endres.

40

Mono lar deg benytte kjente IDE’er som Visual Studio og Xcode. I tillegg er MonoDevelop også god å

bruke, men da spesielt på Mac. Selv om det går an å skrive hele løsninger i Visual Studio17 [85], er

man tvunget til å bytte mellom Mac og Windows. Dette er først og fremst når man skal lage

brukergrensesnitt til iPhone og for å kunne teste.

Derfor må man ha en løsning for å dele kode mellom Mac og PC, noe som utelukker Team

Foundation Server. Det er lettest å bruke GitHub for bytting mellom plattformer underveis i

prosessen.

Integrering med andre biblioteker, som for eksempel MonoMobile.Extensions, innebærer stort sett

bare å legge til en referanse til bibliotekets DLL-fil. For å få til dette må man først bygge biblioteket.

Med MonoMobile.Extensions fikk vi noen problemer med dette siden det ikke er helt ferdig. Blant

annet fikk vi en kompileringsfeil når vi prøvde å bygge Android-implementasjonen. En annen ting å

merke seg er at man bare trenger å bygge prosjektet som heter MonoMobile.Extensions18.

Siden brukergrensesnitt lages til hver enkelt plattform, blir utseende 100% native. Applikasjonene

både ser og føles som om de var laget i de respektive språkene19.

3.3.3 Beskrivelse av APIer

Mono har ett av de största API stöden på marknaden vad vi kunde se. Detta beror på att MonoTouch

är en integrering av Objective-C i C#, och Mono for Android är en integrering av Java i C#. Det gör att

Mono har ett massivt bibliotek med API stöd och dokumentation som man kan ta till bruk [86].

Ramverket tillbjuder massa API stöd, men var för sig. Det vill säga att det inte finns en universell kod

för MonoTouch och Mono for Android. På grund av det får man ingen integrering med

telefonegenskaper med hjälp av gemensam kod. Man kan inte heller använda Windows Phone kod,

något som gör att den gemensamma kod basen blir snabbt mindre.

Det är dock under utveckling ett bibliotek som heter MonoMobile.Extensions [87] som är en

integrering av PhoneGap i C#. Meningen med det här projektet är att bygga en koppling mellan

iPhone, Android och Windows Phone sina respektive API’er. Biblioteket är dessvärre inte färdigt, den

saknar stöd för bland annat Geolocation till iPhone. Projektet utvecklas utav tre personer utan en

fast plan.

3.3.4 Testapplikasjon

Vi valgte en annen løsning i denne applikasjonen enn vi gjorde i PhoneGap-applikasjonen. Istedenfor

en startmeny, bestemte vi oss for å utnytte det at man lager brukegrensesnitt til hver enkelt

plattform i Mono-applikasjoner. Det ga oss mulighet til å teste de respektive plattformenes måter å

lage applikasjoner med faner(Figur 22). Android og iPhone har tradisjonelle faner slik man kjenner fra

nettlesere, mens Windows Phone har en såkalt ”Pivot-Control” som lar deg bla mellom sider i tillegg

17 Plugin er beskrevet i workshop av Jonas Follesø, BEKK Consulting (https://github.com/follesoe/FlightsNorway/tree/workshop/Docs) 18 Løsningen inneholder også et eksempel som ikke er nødvendig å bruke 19 Objective-C, Java, C#

41

til vanlig fane-navigering20.

Figur 22: Testapplikasjon på Android, Windows Phone og iPhone

Når applikasjonen starter opp vises RSS-fanen. Denne henter ut stillinger fra RSS-feeden [78] ved

hjelp av én klasse som deles over alle plattformene. Selve metoden som henter ut data benytter Linq

til XML(Kodelisting 6), og er på den måten meget enkel.

Kodelisting 6: Linq til XML brukes til å behandle datane fra RSS-feeden (e.Result)

Vi støtte allikevel på noen problemer med å få presentert resultatet fra metoden vår på telefonene.

Som flere ganger tidligere i prosjektet var det Android som var problemet. For å løse dette skrev vi

om mye av Rss-klassen21 ut i fra en presentasjon i Norwegian .Net User Group holdt av teknologisjef i

Sysco, Sigurd Snørteland [88]. Det viste seg i ettertid at den viktigste endringen denne introduserte

var måten vi kalte metoden i UI-laget på Android. Hvis vi prøvde å endre på teksten i en label utenfor

metoder som var direkte assosiert med UI-elementer(Kodelisting 7), fikk vi feil i form av

20 Med vanlig tab-navigering mener vi å trykke på den tabben man vil gå til. 21 Klassen heter ”Rss” med små s-er

42

NullReferenceExceptions eller at applikasjonen bare hang seg.

Kodelisting 7: Denne metoden er ikke direkte assosiert med et UI-element. Resultatet blir at

applikasjonen henger seg

Løsningen er å gjøre iterering av listen med utskrift når man for eksempel trykker på en knapp. Selve

oppdateringen av listen er alt som skal gjøres i metoden over.

Den andre fanen viser din nåværende posisjon i kart. Metoden som henter ut posisjonen benytter

Geolocation-klassen fra MonoMobile.Extensions biblioteket [87], er felles for Android og Windows

Phone. Men som tidligere nevnt er ikke iPhone-delen av dette implementert. Kartfanen på iPhone

demonstrerer derfor bare hvordan man bruker MonoTouch sitt kart-API.

Selve Geolocation-objektet som Loc-klassen22 benytter seg av, må sendes inn gjennom

konstruktøren. Dette er fordi Android og Windows Phone må opprette et slikt objekt på forskjellige

måter(Kodelisting 8).

Kodelisting 8: Nytt Geolocation-objekt på henholdsvis Android og Windows Phone

Når kartfanen lastes23 blir det gjort et metodekall som legger brukerens nåværende posisjon inn i

objektets variabler. Da vi prøvde å skrive dette ut direkte oppstod det et uventet problem ved at vi

alltid fikk posisjonen 0,0. For å fikse dette kom vi opp med en enkel løsning: Vi skrev en metode som

returnerer en oppdatert utgave av objektet som så brukes til utskrift.

Det er lagt inn en knapp på både Windows- og Android-visningene for å vise posisjonen. Grunnen til

dette er at særlig Windows Phone-metoden kan være treg. Vi vet ikke konkret hvorfor, men testing

antyder at det har noe med måten Windows Phone bruker Wi-Fi til å triangulere posisjonen å gjøre.

Ved testing i områder der det har gått veldig tregt med Wi-Fi og Location Services slått på, har det

22 Loc-klassen brukes til å finne og returnere brukerens posisjon 23 På Android og Windows Phone

43

hjulpet å slå på mobildata. I slike områder anbefaler vi derfor å vente i opptil 10 sekunder på

Windows Phone før man trykker på knappen dersom man ikke har annen tilgang til nett enn Wi-Fi.

På Android har det egentlig ikke vært noen lignende problemer, så knappen er der hovedsaklig for å

kunne finne igjen posisjonen når man zoomer. Zoomnivået på Android er nemlig noe lenger ut enn

på Windows Phone. iPhone har ytterligere lavere zoomnivå (Figur 23).

Figur 23: Forskjellige zoomnivåer på Android, Windows Phone og iPhone

3.3.5 Hva rammeverket egner seg til

MonoTouch och Mono for Android är stora och komplex ramverk som har stort potential. Dessvärre

för oss så gäller ramverket bäst så länge man har lite eller ingen integration med telefonens API’er,

och när man ska presentera få views. C# är ett språk som passar gott till stora komplexa

datastrukturer än vad JavaScript gör.

Vi rekommenderar att följa med på utvecklingen av MonoMobile.Extensions vilket kan göra Mono

mycket mer mångsidig. Om det här biblioteket blir färdigutvecklat så får man i princip PhoneGaps

styrkor i C#. Det som återstår då av gemensam kod är lite API integrering24 och grafiska gränssnitt.

3.3.6 Oppsummering

Mono har vært på markedet relativt lenge og er veldig godt utviklet25. For å kunne programmere til

både iOS, Android og WP7 trenger man forskjellig type rammeverk26. Du kan bruke Visual Studio og

Xcode eller MonoDevelop som følger med rammeverket ved installasjon.

24 För tillfället finns det inget bevis om att alla API’er kommer att integreras i MonoMobile.Extensions.

44

Det er ikke spesielt vanskelig å finne støtte og eksempler om bruk av Mono på nettet. De har egne

dokumentasjonssider med hjelp til installasjon og oppsett av prosjekt, i tillegg til API-dokumentasjon

med mer [86].

Vi ga i utgangspunktet ikke så god kritikk av mulighet for integrering med utviklingsmiljøer (IDE). Det

er ingen problemer å bruke MonoDevelop på Mac, men det anbefales å bruke Visual Studio på

Windows. Plugin til VS for MonoTouch var ikke vanskelig å implementere; Mono for Android plugin

installerte seg selv i VS, så slikt sett var det ikke store problemer å bruke Visual Studio til Mono.

Bytting mellom Mac og PC er fortsatt ikke til å unngå.

På forhånd var vi skeptiske til i hvor stor grad Xamarin mener at rammeverket kan brukes til

kryssutvikling. Det er ingen apps i showcasen deres som er til alle tre plattformer [97]. Selv om denne

kanskje bare viser de beste applikasjonene, burde det vært minst én applikasjon der av denne typen.

MonoMobile.Extensions viser at det er mulig å få felles API’er på de tre forskjellige plattformene med

C#. Vi lurer derfor på hvorfor Xamarin ikke har gjort tilsvarende. Vi setter igjen spørsmålstegn ved

hva deres tiltenkte bruksområde for rammeverkene er.

Tabellen under viser revurdert oversikt over fordeler og ulemper ved Mono. Endringer er satt i fet og

kursiv tekst. Originaltekst står i parentes der det er endringer.

Fordeler Ulemper

Mye tilgjengelig informasjon, mange som har utviklet med dette rammeverket.

Rammeverket er ikke krysskompatibelt på UI-laget.

(Kan lage apps for alle aktuelle plattformer)

Kan lage apps for Android og iPhone med delte biblioteker fra Windows Phone-prosjekt

Må aktivt benytte både Mac og Windows

Må ikke hoppe så mye mellom som vi trodde

Bruker C# som de eneste på markedet (API må utvikles for hver plattform)

Må benytte tredjeparts biblioteker for å få felles API-integrasjon. Disse er ikke nødvendigvis fullstendige

IDE-støtte Tvilsomt at det er tenkt som kryssutviklingsverktøy

Støtte for tredjeparts-biblioteker

Enkel installasjon

(Gratis?)

Fant ut det ikke var gratis, men det er ikke nødvendigvis en ulempe

Tabell 10: Revurdering av fordeler og ulemper

25 Xamarin tok over i 2011, men har vært på markedet betydelig lenger 26 Mono for Android og MonoTouch. WP7 er vanlig Silverlight for Windows Phone

45

3.4 webMethods Mobile Designer

Dette kapitlet omhandler prosesselementer, men er tatt med i produktrapporten for å gi et bedre

helhetsinntrykk over rapporten vi leverte til WebCruiter. Innholdet i kapittel 2.2.2.2 i

prosessrapporten er helt likt dette, og man kan derfor hoppe til avsnitt 3.5 hvis dette er lest.

Etter screeningen hadde vi et positivt inntrykk av webMethods Mobile Designer. Det eneste vi var

bekymret over var hvorvidt et så stort selskap som Software AG stilte seg i forhold til

studentprosjekter.

Vi har dessverre ikke lyktes med å få testet rammeverket. Istedenfor har vi, etter å ha forhørt oss

med WebCruiter, gjort en utredning av Rhodes fra Rhomobile istedenfor. Avsnittene under beskriver

prosessen vi har vært igjennom med Software AG. All kommunikasjon som er gjort per e-post er

vedlagt (Vedlegg E – Mailkommunikasjon med Software AG).

3.4.1 Anskaffelse

Til å begynne med virket det som om det skulle gå raskt å få tak i den programvaren vi trengte. Etter

at vi henvendte oss til salgsavdelingen per e-post, fikk vi svar fra en annen avdeling som hadde med

universiteter og høgskoler å gjøre. Herfra fikk vi beskjed om at det skulle sendes en pakke. Grunnet

problemet med Rhodes som vi har gjort rede for tidligere(se avsnitt 2.5.3) og det faktum at vi

oppdaget dette på en fredag, gikk det en uke før veileder fikk oppgitt adresse.

Siden vi hadde noe å jobbe med imens vi ventet27, gjorde vi ingen forsøk på å purre Software AG med

en gang. Vi var i den tro at pakken var sendt og på vei til Norge. Men da vi ikke fikk noe i løpet av

uken, ringte vi til Tyskland fredag 9. mars. Da var det ikke mulig å få tak i vår saksbehandler. Han vi

snakket med kunne heller ingen ting om vår henvendelse eller produktet det gjaldt. Vi spurte blant

annet om mulighet til å laste ned produktet, men han kunne ikke svare. Han oppfordret oss til å ringe

mandagen etter.

I løpet av uken som fulgte hadde vi flere telefonsamtaler med saksbehandler, og det ble mer og mer

tydelig at han ikke visste noe som helst om produktet. Han sa også at vi var de første studentene som

hadde ønsket Designeren. Endelig bekreftelse på at pakken skulle sendes fikk vi ikke før sent på

ettermiddagen 13. mars.

Dagen etter ble vi nok en gang ringt opp av saksbehandler. Nå kunne han melde at det fantes

mulighet for å laste ned produktet, noe han hadde trodd ikke var mulig. Lisensnøkler ble sendt, og vi

kunne endelig laste ned og komme i gang. Trodde vi.

3.4.2 Forsøk på å bruke produktet

Det ble sendt to mailer. Først en med lisensnøkler og linker til å laste ned direkte. Deretter kom det

en ny mail som sa at vi måtte logge inn på en side [98] for så og laste ned herfra28. På denne siden

finner man ikke webMethods Mobile Designer direkte, men den er å finne i Software Download

Center. Dette på tross av at det står i klartekst at den ikke er mulig å laste ned via det programmet

(Figur 24).

27 Vi begynte å planlegge utviklingsfasen. 28 Brukernavn og passord til siden er oppgitt til Lars-Erik Johannessen.

46

Figur 24: Mangelfull informasjon på Software AGs sider

Det fulgte med en rimelig omfattende dokumentasjon som vi også fant på internett [99]. I denne

hevdes det at installasjonen inkluderer en rekke prøveprosjekter i mappen ”Samples”. Men samtlige

av oss fikk kun ett prosjekt i denne mappen: ”_Deviceprofiler_”. Dette er et prosjekt som brukes som

eksempel for oppsett med Eclipse, men ved å følge stegene i dokumentasjonen, får vi masse

kompileringsfeil.

Figur 25: Ingen samples

I et forsøk på å fikse dette tok vi for oss filen ”sdk.properties”. Dette er en XML-fil med generelle

innstillinger og filstier for de individuelle plattformenes SDK’er. Dokumentasjonen sier at det er her

man skal gi sine egne innstillinger, men det er særdeles mangelfulle eksempler29.

Vi kunne kanskje omgått dette hvis vi hadde fått se på koden i de prøveprosjektene som skal følge

med, men det virker som om Software AG har sendt oss feil lisensnøkkel. FAQ-filen som fulgte med

nedlastingen30 hinter til dette. Der står det at antall samples avhenger av lisenstype.

Det er verdt å merke seg at webMethods tilsynelatende bygger på å støtte konkrete telefoner kontra

hele operativsystemer. For eksempel er det bare en mappe for HTC under Windows Phone (Figur 26).

Dette gjenspeiles også når man kjører programmet for å legge til ”handset” fra build.xml-filen i

_DeviceProfiler_ prosjektet. Støtten for de andre plattformene virker dog å være altomfattende.

29 Særlig i forhold til om filstier skal bruke ”/” eller ”\”. 30 Dokument er overlevert WebCruiter, og er også tilgjengelig på vår prosjektside http://dotnet.iu.hio.no/s154415/TeamRubberduck/TR.aspx

47

Figur 26: Kun WP7-støtte for HTC?

Vi har prøvd å få kontakt med Software AG i forhold til å få tak i prøveprosjektene, men får ingen

svar. Saksbehandleren vår har ikke den nødvendige kunnskapen og han kan heller ikke sette oss i

direkte kontakt med noen som har det. Dette resulterte i at vi måtte ta en beslutning for å komme

videre i prosjektet. I samråd med Lars-Erik Johannessen ble det da besluttet å utrede Rhodes. Kart

skulle da utelates i testapplikasjonen for Windows Phone siden dette ikke er støttet enda.

3.5 Rhodes

3.5.1 Komme i gang

For å begynne å utvikle med Rhodes, må man laste ned RhoStudio fra Rhomobiles hjemmeside [15].

Da får man et installasjonsprogram som installerer nødvendige komponenter og noen

tilleggsprogrammer hvis man ønsker det. Det er ikke nødvendig å ha Eclipse på forhånd, selv om

tutorialen mener man må installere RhoStudio som et plug-in hvis man kjører 64-bits Windows [100].

Vi har kjørt RhoStudio på 64-bits Windows 7 uten problemer.

Problemer hadde vi derimot på Mac. RhoStudio bruker veldig mye ressurser, og det henger seg ofte.

Vi fant det derfor betydelig lettere å bruke Textmate sammen med kommandolinjen. Vi setter

spørsmålstegn ved hvor kompatibelt RhoStudio egentlig er med Mac. Flere av

undervisningsvideoene31 på hjemmesiden deres hvor Mac er brukt til utvikling, har de også brukt

denne teknikken.

RhoStudio tilbyr en simulator for testing av applikasjoner, men denne gir ingen følelse av hvordan

applikasjonen faktisk kjører på de individuelle telefonene. Den kjører applikasjonen på samme måte

uavhengig av hvilken plattform man har valgt. Eneste forskjell er hvilken CSS-fil den bruker. For å få

det rette inntrykket, må man teste på emulatorene fra produsentene. Da er det noen ekstra steg

man må gjøre som er beskrevet i avsnittene under. Det er også en tutorial for dette på

hjemmesidene til Rhomobile, men disse er ikke like gode for alle plattformer [102].

3.5.1.1 Android

Ruby er skrevet i C, så for at det skal være mulig å kjøre koden på Android-telefoner, må man

installere en komponent i tillegg til Android SDK. Android NDK [103] er et verktøy som blant annet

gjør det mulig å kjøre ruby-, eller nærmere bestemt, C-baserte applikasjoner på Android [104]. Derfor

31 ”Webinars”

48

må man laste ned denne og legge til filstien til denne under preferences i RhoStudio. For å unngå

problemer med mellomrom i filstien, anbefaler vi å legge den på rotnivået på den aktuelle disken32.

Videre er det veldig viktig at man bestemmer hvilke egenskaper applikasjonen skal ha i filen

”build.yml”. Dette gjelder kun for Android og tilsvarer de tradisjonelle tillatelsene man setter i en

vanlig Android-applikasjon.

3.5.1.2 iPhone

Det eneste man trenger for å kunne utvikle til iPhone på en Mac er RhoStudio for Macintosh. Denne

installasjonen inneholder alt av nødvendige filer som blant annet Rhodes og Ruby Gems. Det er viktig

å installere gems før du legger over RhoStudio i Applications-mappen. Det er også muligheter for å

installere Rhodes uten RhoStudio. Hvis JDK er installert fra før (som det allerede er på Mac OS X 10.6

og tidligere), er filstien til JDK’en allerede automatisk satt.

3.5.1.3 Windows Phone

Støtten for Windows Phone er minimal for øyeblikket. Det virker som om dette også gjelder for

måten man tester på device. Oppsettet er for så vidt greit. Det viktigste å merke seg her er forskjellen

på filene ”rhobuild.yml” og ”build.yml”. Førstnevnte gjelder for alle applikasjoner, mens sistnevnte er

spesifikk for hver enkelt applikasjon. Filsti til MSBuild skal da legges i rhobuild-filen.

3.5.1.4 Prosjektoppbygging

Når man lager et nytt Rhodes-prosjekt, er det masse filer der fra begynnelsen av (Figur 27). En del av

disse kan man slette etter behov. Blant annet er det egne filer for BlackBerry-views som er

irrelevante hvis man ikke skal ha applikasjonen sin ut på BlackBerry. Grunnen til at disse filene er der

er at browseren BlackBerry bruker har særdeles lite støtte for moderne CSS [105], noe som gjør at

viewsene her må struktureres på en annen måte.

32 For eksempel slik: C:\AndroidNdk

49

Figur 27: Mappestruktur i standard Rhodes-prosjekt

Det er også lagt opp en modell som håndterer innlogging mot RhoSync. Hvis man ikke har tenkt til å

benytte seg av dette, noe vi ikke gjorde, er det bare å slette hele denne mappen33.

Skal man lage sine egne stiler kan man også slette CSS-filer og bilder som hører med til disse.

JavaScript-filene anbefaler vi dog å la være – det er blant annet noen scripts som brukes før bygging

til noen plattformer34.

3.5.2 Utviklingsprosessen

Rhodes benytter seg av Ruby for å lage native applikasjoner, og er det eneste rammeverket som

automatisk strukturerer prosjekter etter MVC-modellen. Du blir nærmest tvunget til å programmere

på denne måten når du bruker Rhodes med RhoStudio. For å bryte med modellen kreves det en del

ekstra jobb ved sletting av filer og mapper.

For å generere en modell i RhoStudio er det bare å velge New->Rhodes model ved å høyreklikke i

Project Explorer. Da får man opp et informasjonsvindu (Figur 28) som man må skrive inn navn og

attributter til modellen. Du må allerede her være helt sikker på alle attributter du trenger. Når du er

ferdig og trykker på Finish vil alt av nødvendige filer bli generert. Modellen består av tre

hovedelementer (bruker modellen nedenfor som eksempel): Modellfilen (product.rb), kontrolleren

som tar seg av businesslogikken (product_controller.rb) og selve view-filene (*.erb). I forhold til view-

33 Modeller ligger i egne mapper. Den mappen det er snakk om her heter ”Settings” 34 Blant annet bygging til WP7

50

filene følger det også med såkalte .bb-filer, som tidligere nevnt, er filer til BlackBerry.

Figur 28: Lage en modell i RhoStudio

IntelliSense er ikke en funksjon som er lagt til i RhoStudio. Debugging er derimot integrert, men dette

gjelder bare selve Ruby-koden. Du får ikke debugget .erb-filene med HTML-syntaks. Dette bringer oss

videre til et annet lite problem, nemlig dårlig fremheving av kodeord i HTML, særlig på Mac (Figur

29). Men også på Windows er det langt fra bra, og det virker noen ganger litt tilfeldig hva som

utheves.

Figur 29: HTML-fremheving i RhoStudio

Når du vil kjøre applikasjonen i RhoStudio, må du ha en Run Configuration til det gjeldende

prosjektet som skal kjøres. Du kan lagre flere slike som du får benyttet deg av i RhoStudio (Figur 30).

Det som er en smule slitsomt er at en config må lages for et bestemt prosjekt. Dette medfører at hvis

51

du har flere prosjekter, må du enten lage en config til hvert prosjekt eller endre hvilket prosjekt som

er spesifisert i config’en. Dette kan bli slitsomt hvis du hopper mellom flere prosjekter samtidig. Du

velger i tillegg hvilken plattform og type simulator/device i hver config.

Figur 30: Run Configurations

Vi har støtt på visse problemer angående pushing til device. Blant annet til Windows Phone fikk vi

opp en merkelig feilmelding (Figur 31).

Figur 31: WP7 problemer

Denne kom riktignok etter at vi hadde fått til å pushe én gang. Da ble Ruby-tolkeren blokkert av

brannmuren under kompileringen (Figur 32). Etter at vi tillot dette, har vi ikke fått til å komme forbi

steget over. Det er tydelig at Rhodes’ kompilator ikke er fullt utviklet for Windows Phone enda.

52

Figur 32: Ruby interpreter blokkert

Til iPhone gikk det relativt greit å pushe til både iPhone-simulatoren og device. Det du må gjøre er å

bygge og kjøre applikasjonen med Xcode. Ved hjelp av et par kommandoer i Terminal får man satt

opp Xcode-miljøet for Rhodes-applikasjonen. Etter dette må man navigere seg til en (godt gjemt) fil

(Figur 33) for å starte applikasjonen i Xcode. Det siste steget er å velge rhorunner og enten simulator

eller device under Scheme ved siden av stopp-knappen i Xcode, og så kjøre applikasjonen.

53

Figur 33: Filsti til Xcode-versjon av prosjektet

Til Android er det, som nevn tidligere, noen flere steg enn de andre plattformene. Men så lenge man

har satt path til Java SDK, Android SDK og NDK, er det relativt enkelt å pushe. Det kan gjøres både fra

RhoStudio og kommandolinje. Vi synes dog at det er litt dårlig at man ikke kan velge emulator fra en

liste; dette må skrives inn manuelt. Videre hadde vi noen problemer med at Rhorunner hang seg,

men det gikk som regel alltid på andre forsøk.

Feilmeldinger er riktignok ikke veldig gode. Du får opp all informasjon om hva som skjer når du

bygger/kjører applikasjonen i konsollvinduet nederst til venstre i RhoStudio. Selve feilmeldingene fra

kjøring dukker opp i simulatoren, men det er som regel ganske kryptisk og vanskelig å finne igjen i

koden. Feilmeldinger fra kompilering skal komme ut i konsollvinduet, men vi har opplevd at dette har

blitt blanket ut når det skjer en feil. Når man kjører rake fra kommandolinjen vil du få opp mer

forklarende feilmeldinger i forhold til RhoStudio. Det kan derfor være lurt å kompilere applikasjoner

herfra istedenfor i RhoStudio.

3.5.3 Beskrivelse av API’er

Rhomobile har støtte for mange APIer. Så lenge man ikke utvikler for Windows Phone. I deres

oversikt [22] ser man at det kun er støtte for tre; ”Menu”, ”Toolbar” og ”Tab Ba (To Be Decided) på

resten av API’ene. Det vil si at de er planlagt, men det er ingen sikre tegn på når de kommer og hva

som konkret er mulig.

Rhodes API’er består av mange funksjoner som ikke er innebygde telefon-funksjoner[108]35 Et

eksempel er Rexml fra Ruby-biblioteket. Det finnes derimot ingen oversikt over hvilke plattformer

som støtter nettopp disse API’ene. Det ser ut som at Windows Phone ikke støtter dette, for når vi

pusher til device eller kjører prosjektet på simulator får vi feil (Figur 34).

35 F.eks kamera, geolocation m.m

54

Figur 34: Feil ved kjøring på Windows Phone simulator

Geolocation kan kodes på to forskjellige måter. Den ene måten er med Ruby. Den andre er ved bruk

av Ajax (JavaScript). I det siste tilfellet er det lite kode som skal til, og man bruker en enkel HTML-tag

for å aksessere geolocation-informasjonen.

3.5.4 Testapplikasjon

Kartfunksjonen er implementert ved hjelp av MVC-rammene som RhoStudio legger opp til. Dette

gjorde vi fordi vi ville demonstrere hvordan dette virker i praksis. Du blir i dette eksempelet nødt til å

lage et lokasjonsobjekt før du får muligheten til å vise posisjonen i kart.

55

Figur 35: Rhodes' startside

Når applikasjonen starter så kommer man til startsiden (Figur 35). Her kan man enten velge RSS eller

Location (kart). Posisjonen hentes med Rhomobile sin implementasjon av GeoLocation (Kodelisting

9). Denne henter posisjonen asynkront og derfor benytter man sleep-funksjonen for å vente på at

posisjonen oppdaterer seg. GeoLocation returnerer en int, men siden kartfunksjonen tar en string

som parameter, blir man tvunget til å kalle på en toString-funksjon etter hvert kall til en posisjon.

Kodelisting 9: Kode som henter ut brukerens posisjon

Å hente posisjonen tar ofte ganske lang tid. Når man har fått en posisjon går applikasjonen videre og

lagrer posisjonen i et Location-objekt som kan finnes igjen i Location-menyen (Figur 36). Vi opplevde

en bug på iPhone ved at man får feilmelding36. Det viser seg dog at det ikke har skjedd noen feil, og

objektet blir opprettet allikevel.

36 Error loading page

56

Figur 36: Location-menyen

For å vise frem posisjonen i kart velger man å vise objektet. Her er det et menyvalg for å vise på kart.

Da kalles det på en metode i kontrolleren som laster kartet og setter senter ved hjelp av objektets

egenskaper (Kodelisting 10).

Kodelisting 10: Kode for å sette senter og zoom-nivå

Det oppstod et uventet problem med Android: Vi hadde en fullt fungerende applikasjon på

testmobilen, men da vi prøvde å pushe denne igjen (uten endringer) hadde den sluttet å fungere. Vi

forsøkte derfor å pushe til en annen telefon, noe som fungerte helt fint selv etter flere pushinger.

Den eneste forskjellen mellom disse to var at den andre hadde tilgang til mobilt nett. Vi testet å slå

dette av, og da klarte vi å gjenskape feilen. Det er riktignok usikkert hvorvidt dette er kilden til feilen

– applikasjonen fungerte på et tidspunkt uten mobilnett også.

Det andre menyvalget tar deg til funksjonen som henter data fra WebCruiter. Metoden som henter

ned data fungerer på en ganske annen måte enn de to andre testapplikasjonene. De fleste Rhodes-

applikasjoner som henter data fra webtjenester benytter JSON, og disse metodene lot seg ikke uten

videre oversette til å lese XML. Vi fant derfor god inspirasjon fra en som hadde hatt tilsvarende

problem [107].

Når det trykkes på stillinger kalles det en metode i kontroller-filen til stillinger. Denne laster ned

informasjonen og lagrer det på device som en xml-fil. Denne blir deretter behandlet før

informasjonen skrives ut.

For å kutte ned outputen til kun navn på stillingene skrev vi en kode (Kodelisting 11) som skilte ut

informasjonen i feeden og skrev bare ut bare ut tekst som befant seg inne i title-tagger.

57

Kodelisting 11: Kode som henter ut en title. Denne kjøres i en løkke

Et lite problem med testapplikasjonen er at når RSS knappen trykkes på kommer det opp en

feilmelding før den deretter går automatisk videre å skriver ut informasjonen (Figur 37). Vi mistenker

at applikasjonen prøver å lese filen der dataen lagres før informasjonen er lastet ned, for deretter å

lese den på nytt etter nedlastingen.

Figur 37: Feilmelding i testapplikasjonen

3.5.5 Hva rammeverket egner seg til

Gjennom Ruby tilbyr Rhodes et verktøy som er bedre egnet til å skrive kompliserte datastrukturer

enn det JavaScript er. Men på grunn av manglende IntelliSense og lite debug er det ikke nødvendigvis

lettere.

Siden HTML og JavaScript benyttes til brukergrensesnitt vil man i prinsippet få en felles kodebase til

de aktuelle plattformene. Per nå ligger problemet i at støtten for Windows Phone er marginal. Men i

fremtiden kan Rhomobile tilby en seriøs utfordrer på kryssplattformfronten.

3.5.6 Oppsummering

På forhånd virket det som om miljøet rundt Ruby var ganske stort og sterkt voksende. Men i ettertid

mener vi at det er noe mindre enn man kunne ønske. Det er mye hjelp å finne i forumer og lignende,

men ofte ikke omfattende svar.

Videre er vi skuffet over støtten i RhoStudio i form av IntelliSense og debug-muligheter. Ustabiliteten

på Mac trekker også ned på helhetsinntrykket.

58

Som den eneste av de rammeverkene vi har testet tilbyr Rhomobile en egen simulator. Vi skulle

gjerne sett at denne var mer forseggjort. Den burde etterligne oppførselen til ulike plattformene på

en betydelig bedre måte enn det den gjør i dag37.

Generelt sett, ut i fra vår periode med testing, snublet vi over en god del bugs og småfeil. For

eksempel fikk vi et problem ved kjøring av sample-prosjektet som følger med RhoStudio (Figur 38).

Alt i alt, syntes vi ikke Rhodes var særlig tilfredsstillende. Ruby er i tillegg et ukjent

programmeringsspråk, men dette hadde svært lite å gjøre med vår endelige avgjørelse. Vi har heller

ikke mulighet til å lage alt av funksjonalitet til de valgte plattformene. Dette har å gjøre med at

Windows Phone ennå ikke har tilgang til API som GeoLocation, kamera, skjermrotasjon etc.

Figur 38: Et eksempel på en bug

Tabellen under viser revurdert oversikt over fordeler og ulemper ved Rhodes. Endringer er satt i fet

og kursiv tekst. Originaltekst står i parentes der det er endringer.

37 Den simulerer per nå så å si bare brukergrensesnitt

59

Fordeler Ulemper

Gratis

Ruby (ukjent programmeringsspråk)

API-støtte Eneste IDE som er støttet er Eclipse

(Tutorials og guidelines tilgjengelig)

I tillegg er det veldig gode videoer

Støtter ikke Windows Phone fullt ut.

Rammeverk som fungerer på både OSX og Windows

Ustabilt utviklingsmiljø på Mac

Godt kjent i på forum og hos mange utviklere Ustabil applikasjonsoppførsel

IDE-støtte Får med mange unødvendige filer når man bruker Rhogen (velger New->Rhodes model i RhoStudio)

Legger opp bra til MVC hvis det er noe man ønsker å benytte

Usikkert hva som støttes av tredjeparts biblioteker på de ulike plattformene

Tabell 11: Revurdering av fordeler og ulemper

3.6 Konklusjon

Konklusjonen er basert på erfaringene vi har gjort oss underveis i utviklingen av testapplikasjonene

med rammeverkene PhoneGap, Mono og Rhodes. Vi har gjort et omfattende utredningsarbeid hvor

vi har satt oss godt inn i rammeverkene og dannet oss et mer representativt bilde enn det vi hadde

etter den første kartleggingen.

Videre har vi gjort en revurdering av poengrangeringen for hvert rammeverk (Vedlegg C –

Revurdering etter utredningen). Denne er oppsummert i slutten av kapitlet og viser samtidig den

endelige rangeringen.

3.6.1 Delkonklusjon: PhoneGap

Av de rammeverkene vi har testet, er PhoneGap det eneste som tilbyr fullstendig krysskompatibilitet

av alle tre aktuelle plattformer. Det er dog noen elementer som vil oppføre seg forskjellig på de

forskjellige plattformene, men dette påvirker ikke brukeropplevelsen nevneverdig – verken for

programmerere eller brukere.

Manglende debug og lite IntelliSense for JavaScript, gjør at PhoneGap ikke er å foretrekke for

applikasjoner med store og komplekse datastrukturer. Men i applikasjoner hvor det er mye data som

skal presenteres til brukeren uten at det ligger en innviklet datastruktur bak, er PhoneGap suverent.

60

Det er meget enkelt og komme i gang med, og enda lettere å jobbe med. Siden det også er et av de

rammeverkene med størst brukerbase, finnes det store mengder hjelp å få på forumer – både på

deres egne sider og ellers.

3.6.2 Delkonklusjon: Mono

Monorammeverkene, MonoTouch og Mono for Android, er de eneste som benytter C# som

programmeringsspråk. Dette gir en meget stor fordel over de andre ved at man får kraften dette gir

gjennom store mengder biblioteker – både tredjeparts, Microsofts og Xamarins.

Den store svakheten til Mono i forhold til krysskompatibilitet er det faktum at det er to separate

rammeverk. For å lage kryssapplikasjoner kombinerer man tre prosjekter hvor ett er et Windows

Phone-prosjekt. Brukergrensesnitt og API-integrasjon er forskjellig på alle plattformene, noe som gjør

at den felles kodebasen raskt krymper det øyeblikket man begynner å ta med dette i applikasjonen.

Hvis applikasjonen ikke skal ha noe integrasjon med telefon-API’er derimot, vil man få en veldig stor

andel av kodebasen felles. I slike tilfeller anser vi Mono som det beste alternativet selv om PhoneGap

fremdeles vil tilby mer felles kode. Grunnen er at C# egner seg mye bedre enn JavaScript til å skrive

komplekse datastrukturer, særlig fordi man får full IntelliSense.

3.6.3 Delkonklusjon: webMethods Mobile Designer

Vi fikk ikke gjort en utredning av dette rammeverket, men vi fikk satt oss nok inn i det til å få et

innblikk i hvordan det fungerer. SoftWare AG kjøpte Metismo i mai 2011 og gjorde deres løsning,

Bedrock, til en del av webMethods. Det kan dog virke som at mye av kunnskapen om rammeverket

forsvant i prosessen. Fra vårt perspektiv som studenter, var det særdeles vanskelig å få tak i noe som

helst informasjon om rammeverket og hvordan det brukes.

Det kan riktignok ikke avskrives helt. Da det bygger på Java, vil det potensielt kunne stille i samme

klasse som Mono. Vi har riktignok fått inntrykket av at det støttes individuelle telefoner kontra hele

operativsystemer, noe som i så fall ikke er å foretrekke. Det er også en betydelig mer slitsom prosess

å bygge prosjekter enn Mono, så mest sannsynlig er det ikke en seriøs utfordrer.

3.6.4 Delkonklusjon: Rhodes

Rhodes har per dags dato ikke full støtte for Windows Phone. Det er planlagt å implementere dette,

men det er ingen indikasjoner på når og hva som konkret vil implementeres.

Forutsatt at det kommer samme støtte til Windows Phone som til de andre plattformene, vil Rhodes

være et spennende alternativ. Men etter de erfaringene vi har gjort er vi litt usikre på hvor aktuelt

det vil være å bruke for bedrifter.

Utviklingsmiljøet er ikke det beste, og samtidig er det ingen støtte å få fra dette i form av IntelliSense.

Samtidig er rammeverket tilsynelatende litt umodent enda – det er noen stabilitetsproblemer både

med utviklingsmiljøet og applikasjoner.

Med tid kan Rhodes bli en utfordrer til PhoneGap. Men for å få til det må støtten rundt Ruby bygges

betraktelig opp slik at det kan tilbys bedre rammer for utviklere.

61

3.6.5 Endelig konklusjon

Basert på avsnittene over har vi kommet frem til følgende konklusjon:

PhoneGap er det eneste med 100 % felles kode, det er rammeverket vi har hatt best erfaringer med

og det som er lettest å komme i gang med. Siden WebCruiter har omfattende servicelag på sine

servere, mener vi at det vil være begrenset hvor mye komplekse datastrukturer det vil bli i

applikasjonen de har planer om. Videre skal det være med API-integrasjon i applikasjonen, noe som

også favoriserer PhoneGap.

Vår anbefaling til WebCruiters videre arbeid er derfor PhoneGap.

Denne tabellen oppsummerer resultatet av revurderingen av poengrangeringen. Endringer i kursiv:

Kryss-kompatblitet

Tilgjengelig-het

Moden-het

API-støtte

Tekno-logi

Utviklings- prosessen

Stabilitet Sum

PhoneGap 10 8,8 9,5 9 7 7,2 8 8,5

Mono 6 8,8 8 7 7 8,6 8 7,6

Rhodes 3 7,2 7,8 8 6 5,8 5 6,1

Tabell 12: Endelig rangering

62

4 Kildehenvisning

4.1 Internettreferanser

1 http://communities.softwareag.com/webmethods

[Sist besøkt: 31.1.2012]

2 http://www.softwareag.com/corporate/products/wm/default.asp

[Sist besøkt: 31.1.2012]

3 http://www.softwareag.com/corporate/products/wm/mobile_computing/mobile_designer/

how_it_works/default.asp

[Sist besøkt: 31.1.2012]

4 http://www.cloudpact.com/

[Sist besøkt: 31.1.2012]

5 http://api.cloudpact.com/mobile-api

[Sist besøkt: 31.1.2012]

6 www.feedhenry.com

[Sist besøkt: 31.1.2012]

7 http://phonegap.com/2011/10/18/feedhenry-leverages-phonegap-to-simplify-app-

development-for-enterprise-clients/

[Sist besøkt: 31.1.2012]

8 https://spreadsheets.google.com/spreadsheet/pub?hl=en_US&hl=en_US&key=0AnlS_3zOVE

hMdGl1YUE5MVFsX1BuWGpscUcwZTVmT3c&single=true&gid=0&output=html

[Sist besøkt: 31.1.2012]

9 http://docs.feedhenry.com/reference-docs/app-building-and-submission/

[Sist besøkt: 31.1.2012]

10 http://feedhenrystatus.com/category/deployments/

[Sist besøkt: 31.1.2012]

11 http://www.kony.com/native-mobile-apps

[Sist besøkt: 31.1.2012]

12 http://www.kony.com/cross-channel-api

[Sist besøkt: 31.1.2012]

13 http://www.kony.com/about-us/contact-us

[Sist besøkt: 31.1.2012]

63

14 http://kony.com/

[Sist besøkt: 31.1.2012]

15 http://www.rhomobile.com/

[Sist besøkt: 31.1.2012]

16 http://rhomobile.com/company/

[Sist besøkt: 31.1.2012]

17 http://rhomobile.com/products/rhodes/

[Sist besøkt: 31.1.2012]

18 http://docs.rhomobile.com/

[Sist besøkt: 31.1.2012]

19 http://rhomobile.com/products/rhoconnect/

[Sist besøkt: 31.1.2012]

20 http://itsallaboutruby.blogspot.com/2010/08/rhodes-framework.html

[Sist besøkt: 31.1.2012]

21 http://rhomobile.com/products/buy/

[Sist besøkt: 31.1.2012]

22 http://docs.rhomobile.com/rhodes/device-caps

[Sist besøkt: 1.3.2012]

23 http://phonegap.com/

[Sist besøkt: 13.3.2012]

24 http://phonegap.com/about/features

[Sist besøkt: 31.1.2012]

25 http://phonegap.com/support#support-packages

[Sist besøkt: 31.1.2012]

26 http://groups.google.com/group/phonegap

[Sist besøkt: 31.1.2012]

27 http://wiki.phonegap.com/w/page/16494772/FrontPage

[Sist besøkt: 31.1.2012]

28 http://en.wikipedia.org/wiki/Mono_(software)

[Sist besøkt: 31.1.2012]

29 http://xamarin.com/

[Sist besøkt: 13.3.2012]

30 http://xamarin.com/monoforandroid

[Sist besøkt: 13.3.2012]

64

31 http://xamarin.com/monotouch

[Sist besøkt: 13.3.2012]

32 http://mono-project.com/Community

[Sist besøkt: 13.3.2012]

33 http://support.xamarin.com/

[Sist besøkt: 13.3.2012]

34 http://developer.android.com/sdk/index.html

[Sist besøkt: 13.3.2012]

35 http://developer.android.com/sdk/eclipse-adt.html

[Sist besøkt: 13.3.2012]

36 http://www.techjail.net/starting-programming-for-android-with-netbeans.html

[Sist besøkt: 13.3.2012]

37 http://developer.android.com/guide/publishing/app-signing.html#debugmode).

[Sist besøkt: 13.3.2012]

38 http://developer.android.com/guide/developing/device.html

[Sist besøkt: 13.3.2012]

39 https://blogs.oracle.com/geertjan/entry/procedure_for_android_development_on

[Sist besøkt: 13.3.2012]

40 http://code.google.com/intl/no-NO/android/add-ons/google-apis/mapkey.html

[Sist besøkt: 13.3.2012]

41 http://developer.android.com/sdk/win-usb.html

[Sist besøkt: 13.3.2012]

42 http://handheld.softpedia.com/get/Drivers/HTC-Hero-Drivers-81097.shtml

[Sist besøkt: 13.3.2012]

43 https://developer.apple.com/

[Sist besøkt: 13.3.2012]

44 https://developer.apple.com/xcode/

[Sist besøkt: 13.3.2012]

45 https://developer.apple.com/programs/start/standard/

[Sist besøkt: 13.3.2012]

46 https://developer.apple.com/programs/ios/enterprise/

[Sist besøkt: 13.3.2012]

47 https://developer.apple.com/ios/manage/overview/index.action

[Sist besøkt: 13.3.2012]

65

48 http://www.microsoft.com/download/en/details.aspx?id=27570

[Sist besøkt: 13.3.2012]

49 http://www.microsoft.com/maps/developers/web.aspx

[Sist besøkt: 13.3.2012]

50 http://www.codeproject.com/Articles/153467/Google-Maps-for-Windows-Phone-7-using-

Bing-Map-Con

[Sist besøkt: 13.3.2012]

51 http://code.google.com/intl/no-NO/android/add-ons/google-apis/mapkey.html

[Sist besøkt: 13.3.2012]

52 http://create.msdn.com/en-US/home/about/developer_registration_walkthrough)

[Sist besøkt: 13.3.2012]

53 http://msdn.microsoft.com/en-us/library/ff769508(v=vs.92).aspx)

[Sist besøkt: 13.3.2012]

54 http://msdn.microsoft.com/en-us/library/gg588378(v=vs.92).aspx

[Sist besøkt: 13.3.2012]

55 http://phonegap.com/start#android

[Sist besøkt: 5.3.2012]

56 http://wiki.phonegap.com/w/page/30862722/phonegap-android-eclipse-quickstart

[Sist besøkt: 5.3.2012]

57 http://phonegap.com/start#ios-x4

[Sist besøkt: 5.3.2012]

58 http://phonegap.com/start#wp

[Sist besøkt: 5.3.2012]

59 http://jquery.com/

[Sist besøkt: 13.3.2012]

60 http://jquerymobile.com/

[Sist besøkt: 13.3.2012]

61 http://www.sencha.com/products/touch

[Sist besøkt: 13.3.2012]

62 http://googlegeodevelopers.blogspot.com/2010/03/introducing-new-google-geocoding-

web.html

[Sist besøkt: 13.3.2012]

63 http://docs.phonegap.com/en/1.4.1/index.html

[Sist besøkt: 5.3.2012]

66

64 https://gist.github.com/1117707

[Sist besøkt: 5.3.2012]

65 http://jquerymobile.com/themeroller/

[Sist besøkt: 13.3.2012]

66 http://ofps.oreilly.com/titles/9781449383268/ch02_id35816688.html

[Sist besøkt: 13.3.2012]

67 http://www.leemunroe.com/css-button/

[Sist besøkt: 13.3.2012]

68 http://phoniphone.wordpress.com/

[Sist besøkt: 13.3.2012]

69 http://www.dreamintech.net/2011/11/how-to-setup-and-use-nativecontrols-in-phonegap/

[Sist besøkt: 13.3.2012]

70 http://wiki.phonegap.com/w/page/35501397/Tutorials

[Sist besøkt: 13.3.2012]

71 http://www.evoluted.net/thinktank/web-development/google-maps-api-v3-custom-

location-pins

[Sist besøkt: 13.3.2012]

72 http://code.google.com/intl/no-NO/apis/maps/articles/geolocation.html

[Sist besøkt: 13.3.2012]

73 https://github.com/viavansi/phonegapsample

[Sist besøkt: 13.3.2012]

74 http://docs.phonegap.com/en/1.4.1/phonegap_device_device.md.html#Device

[Sist besøkt: 13.3.2012]

75 http://docs.phonegap.com/en/1.4.1/phonegap_connection_connection.md.html#Connectio

n

[Sist besøkt: 13.3.2012]

76 http://osdir.com/ml/phonegap/2011-12/msg00411.html

[Sist besøkt: 13.3.2012]

77 http://docs.phonegap.com/en/1.4.1/phonegap_camera_camera.md.html#Camera

[Sist besøkt: 13.3.2012]

78 https://www.webcruiter.no/webservices/webcruiterculture.asmx/RSSFeed?Company_Id=21

84300&CultureId=NB-

NO&Collections=1%2c2%2c3%2c4%2c5%2c6%2c7%2c8&xmlversion=version2

[Sist besøkt: 13.3.2012]

67

79 http://yoavniran.wordpress.com/2009/08/02/creating-a-webservice-proxy-with-jquery/

[Sist besøkt: 13.3.2012]

80 http://docs.phonegap.com/en/1.4.1/phonegap_geolocation_geolocation.md.html#Geolocati

on)

[Sist besøkt: 13.3.2012]

81 https://store.xamarin.com/

[Sist besøkt: 13.3.2012]

82 http://docs.xamarin.com/android

[Sist besøkt: 13.3.2012]

83 https://github.com/follesoe/FlightsNorway

[Sist besøkt: 13.3.2012]

84 https://github.com/follesoe/FlightsNorway/tree/workshop/Docs

[Sist besøkt: 13.3.2012]

85 https://github.com/follesoe/VSMonoTouch

[Sist besøkt: 13.3.2012]

86 http://docs.xamarin.com/

[Sist besøkt: 13.3.2012]

87 https://github.com/chrisntr/MonoMobile.Extensions

[Sist besøkt: 13.3.2012]

88 http://sigurdsnorteland.wordpress.com/tag/monodroid/

[Sist besøkt: 13.3.2012]

89 http://www.alexyork.net/blog/2009/09/19/uinavigationcontroller-with-monotouch-building-

a-simple-rss-reader-part-1/

[Sist besøkt: 13.3.2012]

90 http://wiki.ios.xamarin.com/HowTo

[Sist besøkt: 13.3.2012]

91 http://forum.xda-developers.com/showthread.php?t=1302815

[Sist besøkt: 13.3.2012]

92 http://www.iphonedevsdk.com/forum/iphone-sdk-development/10226-line-break-

uilabel.html

[Sist besøkt: 13.3.2012]

93 http://bytes.com/topic/c-sharp/answers/249110-scrollbar-label

[Sist besøkt: 13.3.2012]

68

94 http://conceptdev.blogspot.com/2009/09/monotouch-mapkit-101.html

[Sist besøkt: 13.3.2012]

95 http://troybrant.net/blog/2010/01/set-the-zoom-level-of-an-mkmapview/

[Sist besøkt: 13.3.2012]

96 http://stackoverflow.com/questions/1166444/mkmapview-zoom-and-region

[Sist besøkt: 13.3.2012]

97 http://xamarin.com/apps

[Sist besøkt: 13.3.2012]

98 https://empower.softwareag.com/

[Sist besøkt: 15.3.2012]

99 http://documentation.softwareag.com/webmethods/wmsuites/wmsuite8-

2_sp2/Mobile_Designer/8-2-SP2_Using_Mobile_Designer.pdf

[Sist besøkt: 15.3.2012]

100 http://docs.rhomobile.com/rhostudio.tutorial

[Sist besøkt: 15.3.2012]

101 http://docs.rhomobile.com/rhodes/tutorial

[Sist besøkt: 15.3.2012]

102 http://docs.rhomobile.com/rhodes/build

[Sist besøkt: 19.3.2012]

103 http://developer.android.com/sdk/ndk/index.html

[Sist besøkt: 19.3.2012]

104 http://developer.android.com/sdk/ndk/overview.html

[Sist besøkt 19.3.2012]

105 http://docs.rhomobile.com/rhodes/bb-css

[Sist besøkt 19.3.2012]

106 http://vimeo.com/12301104

[Sist besøkt 19.3.2012]

107 http://codedog.net/2010/09/28/rss-reader-for-rhodes/

[Sist besøkt 19.3.2012]

108 http://rhodesapi.rhomobile.com/rhodes-api-toc-functional

[Sist besøkt 19.3.2012]

69

4.2 Bokreferanser

109 Allen, Sarah : Graupera, Vidal : Lundrigan, Lee (2010) : Pro SamrtPhone Cross-Platform

Development. iPhone, BlackBerry, Windows Mobile, and Android Development and

Distribution : New York : Apress

70

Del 2 – utviklingsrapport --------Beskrivelse av Jobfinder--------

71

1 Gjennomgående elementer

I dette kapitlet beskriver vi elementer som brukes gjennom større deler av applikasjonen. Videre

beskrives enkelte relevante problemområder. For en komplett liste over API’er og andre verktøy

henviser vi til kapittel 1.5 i prosessrapporten.

1.1 Browser-ulikheter

PhoneGap kjører i de ulike plattformenes webView. Disse er basert på de ulike standardbrowserne,

noe som gir noe forskjellig oppførsel fra plattform til plattform. Browserne til de ulike plattformene

er som følger:

iPhone: Safari

Windows Phone 7.5: Internet Explorer 9

Android: Chrome-basert [1]

Både Safari og Androids browser er basert på WebKit [2]. Disse er derfor nærmest hverandre i

opplevelse. Vi har også erfart dette gjennom utviklingen ved at ting som har fungert på Android stort

sett har fungert på iPhone også.

Android og iPhone har vært med i smarttelefongamet lengre enn Microsofts Windows Phone, og det

merkes spesielt på browserene. Det minste man forventer av en mobilbrowser er støtte for touch,

men i IE9 er ikke dette støttet. Som en følge av dette er det for eksempel ikke mulig å panorere eller

zoome på et kart slik som man forventer av en touchtelefon. Det er heller ikke støtte for

inputmetoder som krever touch slik som glideskalaer. Det er allikevel mulig å oppnå glideskalaer,

men da er det ikke mulig å dra disse – man må trykke for å sette verdi.

1.2 localStorage

LocalStorage [3] er et lagrings-objekt, og ligner på sessionvariabler i andre språk (C#, PHP m.m).

Forskjellen er at data lagret i localStorage eksisterer helt til man sletter det via kode (Kodelisting 12),

eller sletter lagrede data på telefonen.

Kodelisting 12: Setting, henting og sletting av localStoragevariabler

Det er kun mulig å lagre tekststrenger i en localStoragevariabel.

72

Vi bruker dette til å ta vare på vesentlig informasjon gjennom applikasjonens levetid. Dette

inkluderer lagring av informasjon mellom sider og bevaring av innloggingsstatus. De localStorage-

variabler som ikke er vesentlig for oppstart38 slettes når startsiden laster.

1.3 GlobalConst.js

I filen GlobalConst.js er det samlet funksjoner som vi bruker på kryss av alle filene. Men viktigst av alt

her er linken til webservicen som brukes. Ellers finnes følgende funksjoner:

setMapType: Brukes i index.html for å navigere til riktig kart avhengig av hvilken plattform

man har.

goHome, goLogIn, goEdit, goDelete, goBack: Brukes i onclick på bilder og span-tagger slik at

det blir en link

clearLocalData: Brukes i index.html for å slette localStorage. Det er kun localStorage-

variablene for sessiontoken (st) og radius (radius) som ikke blir slettet. Hvis en localStorage-

variabel som har med søk å gjøre er satt når man går inn på den siden, skjer det en feil.

Derfor må denne funksjonen brukes i index.html.

1.4 Loadingskjerm

Det vises en loadingskjerm de stedene der det er aktuelt. Det gjelder de sidene som kan ta litt tid å

laste. Vi benytter rammeverket spin.js til dette.

1.5 Internett-tilgang

På alle sidene der man gjør et webservice-kall vil man i den tilhørende JavaScript-filen finne denne

koden i error-callbacket i Ajax-kallet(Kodelisting 13):

Kodelisting 13: Når internett-tilgang mangler blir man sendt til index.html

Hvis det mangler internett-tilgang vil man altså sendes til index.html. Når index.html lastes skjer som

nevnt i kapittelet ovenfor et kall på funksjonen startLoad og den sjekker også internett-tilgangen:

Kaller på funksjonen checkConnection.

Denne bruker API’et navigator.network (Kodelisting 14).

Hvis den returnerer false vil det i funksjonen startLoad() skrives ut en beskjed om at

internett-tilgang mangler, man må slå på nett og prøve igjen.

38 Alt utenom innloggingsstatus og søkeradius

73

Kodelisting 14: Sjekker internett-tilgang og localStorage-objektet "error"

1.6 Webservice

Web service är en tjänst som vi använder till projektet. Den gör det möjligt för oss att hämta, samt

poste data. Tjänsten gör det möjligt att vi slipper att behandla data på klient. En server gör all

databehandling, så att allt vi behöver göra är att kalla på olika metoder mot servern, som vill

returnera ett resultat set.

1.6.1 Tjenestene

Tjänsterna som används är uppbyggda av WebCruiter. Dom ger oss data genom en XML sida som vi

kallar på. Tjänsterna [4] som vi använder oss av är:

Användare services: o Legg till användare. o Ta bort användare. o Hämta information om en användare. o Endre information o Login o Log ut

Ställnings services: o Ställnings annons information. o Industri sök. o Ställnings lista (Används med annons info.)

Användar tjänster är web services med både POST och GET, medan allt som har med ställningar att

göra är GET funktioner. Det är lite skillnad på hur man använder båda, det blir förklarat lite kort i

sektionerna nedan.

1.6.2 Hente data

För att hämta ut data ifrån XML sidan som serven returnerar till oss så använder vi oss av AJAX och

JQuery. AJAX är tjänsten som läser igenom dokumentet från den URL som ges i metoden. Koden

under är ett exempel på hur man hanterar en XML sida med AJAX (Kodelisting 15).

74

Kodelisting 15: AJAX GET

I exemplet här så är linje fyra, url där adressen till Web Servicen blir placerad39. Vi använder oss av

each function för att hämta ut information från dem noderna som är relevant. Ett exempel på noder i

ett kall är vist i Kodelisting 16.

Kodelisting 16: XML sidan

Ställningslistan är en hårdkodad lista med ekte ställnings ID som används till att hämta ”real time”

annons data. Men dem är inte bunden i hop, så vissa ställningar kan ha slutat att upphöra. För mer

information om detta se avsnitt 3.3.1.

1.6.3 Poste data

Sidor av applikationen som använder POST är så som login och logg ut samt ändra och registrera. Det

funkar inte riktigt lika som GET, för att data som ska skickas till web servicen måste packas in för den

skickas (Kodelisting 17).

39 Alla services har olika URL adresser

75

Kodelisting 17: AJAX POST

Data packas in i ett XML-format, också kallt SOAPBody (Figur 39)40. För att web servicen kan klara och

behandla data så måste den också ha en SOAPHeader. Det är detta som göres med hjälp av

xhr.setRequestHeader funktionen som visade sig att ge oss problemer (se processrapporten, avsnitt

2.3.2.1).

Figur 39: SOAPBody template

2 Brukeradministrasjon

Her tar vi for oss alle aspekter av applikasjonen som har med brukeroperasjoner å gjøre. Dette

omfatter inn- og utlogging, registreing, samt endring/sletting av bruker.

2.1 Startsiden

Tilhørende filer:

HTML: index.html

40 Web servicen är en SOAP tjänst.

76

JavaScript: index.js

Når siden lastes starter funksjonen onDeviceReady som kaller på funksjonenstartLoad i index.js.

Funksjonen gjør følgende:

Sjekker om man har noen form for internett-tilgang.

getSessionLocal startes. Denne sjekker om localStorage-variabelen «st» eksisterer.

Dette styrer hvilke linker som skal være synlige på forsiden, altså en sjekk på om man er

logget inn.

o Logget inn: «Vis profil», «Administrer steder» og «Logg ut» vises.

o Ikke logget inn: «Logg inn» og «Registrer» vises.

o De andre linkene vises alltid

2.2 Logg inn

Tilhørende filer:

HTML: logIn.html

JavaScript: logIn.js

Ved innlogging får man utdelt en sessionToken. Denne er unik for hver innlogging, og den benyttes

for å verifisere en bruker mot WebCruiters database.

Når siden lastes starter funksjonen onDeviceReady som kaller på funksjonen getSessionLocal. Dette

er for å sjekke om man allerede er innlogget, for å forhindre bruk av tilbake-knapp etter utlogging.

Knappen «Logg inn»kaller på funksjonen validateFields. Da skjer følgende:

Den sjekker at alle feltene for innlogging er fylt inn, og gir passende tilbakemeldinger hvis

noe mangler.

Når felter er fylt inn kalles funksjonen WriteLoginSoap. soap-logintemplate i login.html brukes.

Den sender med brukernavn og passord i webservice-kallet.

o Hvis kallet er vellykket, og brukernavn og passord er riktig, opprettes en localStorage-

variabel «st». I den legges sessiontoken som returneres. Hvis brukernavn og passord

er feil skrives en feilmelding (Kodelisting 18).

o Hvis det er mislykket er det feil i internett-tilkoblingen.

77

Kodelisting 18: Vellykket webservice-kall ved innlogging, med to utfall

2.3 Logg ut

Tilhørende filer:

HTML: index.html

JavaScript: logOut.js

Menyknappen «Logg ut» i index.html starter WriteLogoutSoap som ligger i logOut.js. Funksjonen gjør

følgende:

Bruker soap-logoutemplate som ligger i index.html.

Sessiontoken som ligger i localStorage-variabelen «st» blir sendt med i webservice-kallet.

Webservice-kallet skjer, og hvis utloggingen er vellykket slettes localStorage-variabelen «st»

og man havner på startsiden igjen.

Hvis det er mislykket er det feil i internett-tilkoblingen.

2.4 Registrer

Tilhørende filer:

HTML: reg_name.html, reg_adress.html, reg_userinfo.html, reg_final.html

JavaScript: registration.js, localstorage_registration.js

Registreringen er delt opp i fire steg, hvorav de tre første stegene inneholder utfylling av dine

persondata mens det siste er et bekreftelsessteg. De tre første trinnene forklares som ett, siden det

meste av funksjonaliteten går igjen i alle stegene. Disse stegene har henholdsvis reg_name,

reg_adress og reg_userinfo som sine respektive HTML-filer.

Samtlige av trinnene benytter seg av localStorage. Dette blir brukt til bevaring av utfylt data. I hvert

trinn, etter man har fylt inn data, er det fullt mulig å navigere seg tilbake til tidligere trinn og gjøre

endringer. Navigerer du deg frem og tilbake i registreringen, er det lagt inn en metode som henter ut

informasjonen som allerede er skrevet inn og legger det inn i feltene. Disse metodene ligger i

localstorage_registration.js, siden denne tar seg av all bruk med localStorage.

Hver av de første tre registreringstrinnene kaller på to metoder kalt for eksempel getNameLocal og

saveAdressLocal. De har forskjellige navn i forhold til hvilke steg det gjelder, dette for å skille mellom

hvilke data som skal hentes/lagres. Get-metoden (Kodelisting 19) kalles når hver side lastes, og hvis

78

man allerede har vært på denne siden og fylt inn data, vil denne metoden hente ut informasjon fra

localStorage og vise disse dataene.

Kodelisting 19: En av funksjonene som henter data fra localStorage og viser disse

SaveLocal-funksjonene skjer først når man har fylt ut alle felter på et steg og valgt å gå videre til

neste. Da kalles forskjellige valideringsmetoder (beskrevet under) som ligger i registration.js

(Kodelisting 20). Kun hvis det er ingen valideringsfeil på utfylte data, vil denne funksjonen gå videre

til sine saveLocal-funksjoner i localstorage_registration.js. Disse metodene er så å si like get-

metodene. Forskjellen er at her settes verdiene, istedenfor å bli hentet ut. Etter at verdiene er lagret

i localStorage, blir du navigert til neste steg i registreringsprosessen.

Kodelisting 20: Eksempel på valideringstest

Det er validering på samtlige felter. Vi har benyttet oss av regulære uttrykk og if-tester på de utfylte

feltene. Det er lagt inn følgende valideringstester:

Alle: Sjekk etter tomt felt.

For -/etternavn: Mellom 2 og 30 tegn. Kun bokstaver, bindestrek og mellomrom er tillatte

tegn.

Telefon: 8 siffer.

Fødselsdato: se under.

Adresse: Gatenavn (tekst) + husnummer (adskilt med mellomrom).

Postnr: 4 siffer.

Poststed: Automatisk utfylling – se nedenfor.

Epost: Må være gyldig epost-format. Eksempel: e@post.no.

Passord: Minst 6 tegn.

Felles for Epost og Passord: Har bekreft-felter. Disse må være like.

79

Fødselsdato (Kodelisting 21) er et av feltene som det er lagt mest vekt på. Det er gjort validering med

tanke på gjeldende årstall, skuddår, antall dager i forskjellige måneder, med mer.

Kodelisting 21: Valideringstest på fødselsdato

De tre første trinnene er relativt like, det samme er funksjonaliteten bak dem. I steg nummer to,

reg_adress.html, har vi derimot implementert et ekstra JavaScript fra Bring sine utviklersider [5].

Scriptet, som vi har kalt getCity og ligger i registration.js, gjør i hovedsak at poststed automatisk

utfylles når postnummer er skrevet inn (Kodelisting 22). Med noen tilpasninger fungerte dette

ypperlig i applikasjonen.

80

Kodelisting 22: Automatisk utfylling av poststed

Det fjerde og siste steget er der bekreftelsen av selve registreringen utføres. Her listes all

informasjonen du tidligere har skrevet inn i, bortsett fra passord (Figur 40). Da har du muligheten til å

gå igjennom og sjekke at all informasjon stemmer.

Figur 40: Bekreftelse av data

Her er det funksjonen getAllLocal som henter ut alle dataene og viser de i labels istedenfor tekstfelt

denne gangen. Trykkes det på bekreft-knappen, kjøres en funksjon som henter ut soapBody med alle

81

dataene som ligger i labels på siden. Dette sendes videre til webservicen og registreringen blir utført

hvis alt har gått bra. Verdiene i localStorage blir nå slettet igjen, og man blir navigert til startsiden.

Du har også til alle tider mulighet til å gå tilbake til hovedmenyen ved å trykke på home-knappen. Det

som da skjer er at metoden checkIfLocal blir kalt. Denne sjekker om du har skrevet inn noe data som

har blitt lagret i localStorage, altså om du har påbegynt registreringsprosessen. Hvis ikke du har noe

lagret, blir du tatt rett til startsiden. Om du har fullført et trinn, vil du få opp et bekreftelsesvindu

med spørsmål om du vil avbryte registreringen (Figur 41). Dette er metoden kalt confirm. Hvis du

velger å avbryte, blir alt i localStorage slettet og du blir så navigert til startsiden.

Figur 41: Avbryt registrering

2.5 Vis profil

Tilhørende filer:

HTML: profile.html

JavaScript: profile.js, localStorage_profile.js

Når siden lastes starter et javascript med flere funksjoner. I funksjonen onDeviceReady kalles

funksjonen startLoad som ligger i filen profile.js. Den gjør følgende:

kaller funksjonen getRadiusLocal som finnes i localstorage_profile.js. Den sjekker om

localStorage-variabelen «radius» finnes, hvis ikke settes radiusen til 10.

82

getCandidateInfo kalles:

o Her sjekkes localStorage-variabelen «st» først (Kodelisting 23). Denne sjekken er her

for å forhindre at bruker kan komme hit via tilbake-knappen med feil

innloggingsstatus

Kodelisting 23: Sjekker om sessiontoken finnes

o Deretter hentes soap-getuserinfosample fra profile.html.

o Sessiontoken som ligger i localStorage-variabelen «st» blir sendt med i webservice-

kallet.

o Webservice-kallet skjer, og hvis det er vellykket blir alle tekstlabler i tilhørende

profile.html fylt inn med variabler fra «myparam» (Kodelisting 24).

o Hvis det er mislykket er det feil i internett-tilkoblingen.

Kodelisting 24: Retur-objektet "myparam" brukes til å fylle inn labler

Når profilsiden vises med innhentede data har man muligheten til å endre på profilen. Man kan også

slette profilen.

2.6 Endre bruker

Tilhørende filer:

HTML: edit_user.html

JavaScript: edit.js

”Endre bruker” er på flere måter lik ”Vis profil”. På samme måte som ”Vis profil”, hentes ut

informasjon om brukeren ved å kalle på webservicens tilhørende metode. Dette er metoden

GetCandidateInfo i JavaScriptet edit.js. Denne metoden bruker sessionToken til å finne hvem bruker

det omhandler. Deretter henter den ut brukerens attributter og viser dem i tekstfeltene på siden.

Dette skjer med en gang du navigerer deg inn på siden (Figur 42).

83

Figur 42: Endre-siden i landscape (Pilen er ikke med i applikasjonen, kun for å vise at du kan scrolle)

Når all data om brukeren vises, er det muligheter for å endre på disse dataene. Funksjonene som

benyttes for validering og lagring av de nye dataene er de samme som for registrering (Se kapittel

2.4). Det er kun små forskjeller, som at e-post og passord ikke lagres eller bekreftes. I tillegg blir alle

felter validert samtidig og ikke trinnvis som i registrering. Du får altså ikke endret brukerdata før all

input er gyldige.

Fordi webservicen ikke har støtte for endring av påloggingsdata, er det heller ikke mulig i

applikasjonen. Brukernavnet vises allikevel i et deaktivert felt for at du skal kunne se ditt brukernavn.

Nytt felt i forhold til registrer er radius for søk i kart. Denne er satt til 10 som standard. Denne blir

hentet ut fra localStorage, og ikke fra webservicen. Denne blir da hentet fra metoden getRadiusLocal

(Kodelisting 25). I kartsiden velger man radius ved hjelp av en glideskala, men vi har valgt å bruke

tekstfelt som input på denne siden (se prosessrapporten, avsnitt 2.3.2.4 for detaljer). Radiusen kan

endres på med en verdi mellom 1 og 120, og denne blir brukt videre som standard zoomnivå på

kartsiden.

Kodelisting 25: Uthenting av radius

Valideringsteksten dukker opp nederst under alle tekstfeltene på siden. Men på grunn av at denne

siden er lenger enn det selve skjermbildet kan vise, vil skjermen automatisk scrolle til bunnen når

valideringsmeldinger vises. En enkel funksjon håndterer scrollingen (Kodelisting 26).

84

Kodelisting 26: Kode som automatisk scroller til bunn av dokumentet

Det er metoden validateFields som kalles når man trykker på endre-knappen. Denne sjekker alle

datafelter og at all input er gyldig, før den videre kaller på webservice-metoden som lagrer en bruker.

Her er det snakk om akkurat samme funksjon som i registrering. Det er ikke en egen endre-funksjon.

Funksjonen lagrer kun brukeren på nytt og overskriver den forrige informasjonen med de eventuelle

nye endringene. Endring av radius skjer utenom med localStorage sin setItem-metode.

2.7 Slett bruker

Tilhørende filer:

HTML: delete_user.html

JavaScript: delete.js

Sletting av bruker er tilknyttet profilsiden sammen med endring av bruker. Denne siden inneholder

ikke overveldende mye funksjonalitet eller informasjon. Det er kun meningen å kunne slette sin

bruker, ikke noe mer.

Delete.js er scriptet tilhørende slett-siden. Den inneholder kun webservice-metoden for å slette en

bruker, i tillegg til en bekreftelsesmetode kalt confirm. Det er funksjonen confirm som kjøres når

brukeren trykker på slett-knappen. Denne tar forbehold for at brukeren uvitende trykket på knappen

uten å mene det. Du får opp et bekreftelsesvindu (Figur 43) som spør om du vil slette eller ikke.

Figur 43: Bekreftelse av sletting

Velger du å avbryte, blir du værende på siden uten at noe mer skjer. Velger man å gjennomføre

slettingen, kalles metoden WriteDeleteSoap. Går dette riktig for seg (Kodelisting 27), blir din bruker

blir slettet.

85

Kodelisting 27: Kode som gjennomføres når alt går som planlagt

Etter at slettingen er gjennomført, blir også sessionToken fjernet fra localStorage. Du blir så navigert

tilbake til startsiden samtidig som du selvfølgelig har blitt logget ut.

3 Søk

Applikasjonen har flere muligheter for søk. Det er dog et par aspekter ved søkesidene som er felles:

Kartsiden og tittelsøk-siden benytter en array av Job-objekter (Kodelisting 28) når et nytt resultatsett

lastes ned. Denne overskrives når det gjøres et nytt søk41.

Kodelisting 28: Job-objekt

Videre er det muligheter for å søke etter både bransjer og stillingstitler. Det er derfor laget en

funksjon for å konstruere en søke-URL basert på hvilken type søk som skal gjøres (Kodelisting 29).

41 Med nytt søk menes her et nytt tittelsøk – ikke endring av radius på kart

86

Kodelisting 29: Funksjon som returnerer en passende søke-URL

3.1 Bransje

Tilhørende filer:

HTML: industry.html

JavaScript: industry.js

På denne siden har brukeren mulighet til å spesifisere søket sitt innenfor en viss bransje. Da brukeren

navigerer seg inn på siden blir det samtidig gjort et kall på en funksjon som henter navnene på alle

bransjene som finnes i XML-filen og skriver dem ut i form av tekstknapper oversiktelig på siden (Figur

44).

87

Figur 44: Søk på bransje

Når brukeren trykker på en av knappene, navigeres man til resultatsiden (se neste kapittel). Før

navigering skjer, kalles en funksjon som henter ut hvilken knapp som har blitt trykket. Navnet på

bransjen lagres så i localStorage slik at resultatsiden vet hva det skal søkes på (Kodelisting 30)

Kodelisting 30: Preprosessering av bransjesøk

3.2 Tittel/resultat

Tillhörande filer:

HTML: searchPosition.html

JavaScript: searchPosition.js

Sidan för tittelsök, användes också till att visa resultatsett (Figur 45).

88

Figur 45: Söksidan

Sidan kan nås även om man inte är loggad in. Sidan är enkel och lättnavigerad med bara ett sökfält,

sök knapp och möjligheter att trycka på visa ställningar i närheten, eller det resultaten du har fått i

kart.

Koden bak sidan är dock lite mer komplex än utseende. Efter som sök sidan kommer att bli använd

till olika föremål så behöver koden vara flexibel.

3.2.1 Generelt

För att göra det lättare och enklare att jobba med mycket data så valde vi att göra en ”Class jobb”

som har datafält för all data. Jobb-objektet sparas sen ner i en array.

Eftersom sök sidan blir använd av både bransch-sök och som den vanliga sök funktionen på annonser

så har vi en kontroll i början som registrerar om man har tryckt på knappen sök, eller om arrayen

som håller ställningarna redan är fylld ifrån bransch söket. Har man navigerat ifrån bransch så är en

localstorage variabel satt med id ”br”.

Funktionen searchTitle blir då kört när man trycker på knappen sök. Den tar för säkerhets skulle bort

lokal variabeln ”br” och laddar sedan in data i arrayen med funktionen loadData (Kodelisting 31).

Kodelisting 31: navigering till sök sidan

89

För att visa data som har blivit sparat i Job-array så bygger vi en textstring med HTML formatering i

en loop. Texten som bygges här visas sen ut på skärmen(Figur 46).

Figur 46: Byggt text på skärm

Id som sättes på ”vis mer” knappen är en id som är unik för en jobb-annons. Den används för att

navigera vidare till en sida som visar mer information om den annonsen. Mer om den funktionen

senare.

3.2.2 LocalStorage variabler

En förklaring av localStorage variabler som användes i både sök och detaljerad visning av

annonsdata.

br

Sätts när man navigerar ifrån ”bransje” sidan. Den används för att veta om man ska visa data

direkt när man navigerar ifrån bransje, eller om man navigerar från sök, vilket ska ge en tom

sida att söka ifrån.

radius

Variabeln som håller en ställnings distans ifrån lokationen du är vid, eller sparat dig till.

pageChange

Sätts när man navigerar till detaljerad visning av annonsdata för att veta om sök metoden vet

när det ska automatiskt söka på samma sök när man navigerar tillbaka till sök resultaten.

indexKey

Används i samsvar med pageChange, searched och pageChange. IndexKey är den sidan man

navigerar ifrån när man läser mer annonsdata. Används så att den vet vilken sida som ska

visas när man navigerar tillbaka från annonsen.

searchtype

90

Används till att bygga URL streng till web servicen. Den sätts till för exempel ”bransje” när

den ska bygga en URL till ett branch sök.

searchparam

Används på sök sidan till att veta vad kartan ska söka på, om det är ett branchsök eller om

den ska generera ställningar.

searched

Sätts till det som blir sökt på ifrån sökfältet. Används till att bygga samma URL streng när

man navigerar tillbaka till sidan ifrån annonsen.

titleid

Knappen som man navigerar till annonsdata har en funktion som blir kallad på när man

trycker på knappen. I den metoden så sätts det specifika ID till annonsen till variabeln. När

man då navigerar till nästa sida så hämtar man titleid och bygger en URL för att kalla på

annonsdata till annonsen.

maptype

Används till kartan så den vet om den ska visa ställningar som är nära eller om den ska visa

alla ställningar i det aktiva resultatsett.

3.2.3 Sidehåndtering

När text-strengen bygges så blir det kontrollerat om det behövs flera sidor för att visa alla elementet

som ligger i arrayen. Testen som körs är på arrayen sin lenght (Kodelisting 32) där alla annonser

ligger.

Kodelisting 32: Hantering av sider på sök sidan

Om variabeln ”j” är lik sista elementet i arrayen så är en näste knapp inte intressant, i andra tillfällen

så vill knappen genereras och man får möjlighet att navigera till nästa sida.

Funktionen printSteveJobs är funktionen som tar hand om uppgiften som skriver ut data till mobilen.

Variabeln ”i” används till index medan ”j” är max antal element per sida (Kodelisting 33).

Kodelisting 33: Antall hantering

3.2.4 Håndtering av forskjellige søk

Ved normal navigering till sidan så visas det inte några träffar på ställningar. Men om man har gjort

ett sök på branscher först så vill den visa alla träffar inom den branschen.

91

För att få till detta så har vi en kontroll när sidan laddas som kollar om det finns två variabler i

localStorage (Kodelisting 34). Dem två variablerna är bara satta om man navigerar ifrån bransch

sidan.

Kodelisting 34: Sök kontroll för navigering av sidor

Om söket skulle resultera i att man inte får något resultat, så får man för användarens skull möjlighet

att söka på ställningar som är i närheten av användaren. För att få till det måste man kalla på web

servicen två gånger. Detta är för att applikationen söker bland alla ställningar för att avgöra vilka som

är i närheten.

Får man däremot en träff på söket så är det också möjlighet för att visa ställningarna på kartan. Man

kan visa hela resultatsättet eller visa ställningar i närheten. Redan innan arrayen fylls med Job-objekt

så avgör det vilka ställningar som är i närområdet.

3.2.5 Håndtering av navigering mellom sider

Vid navigering mellan söket och sidan så är applikationen programmerad att den visar det samma

resultat set när man navigerar tillbaka till söket. Allt är gjort med två stycken localstorage variabler

som sätts vid navigering från söket. Den sparar ner det man sökte på, samt index till sidan man

navigerade bort ifrån när man trycker på ”neste” och ”forrige” knapparna (Kodelisting 35).

Kodelisting 35: Navigering localstorage variabler

När man då navigerar tillbaka till sidan så vill indexKey, och variabeln searhced bli läst in, då vill

samma data vill då bli hämtad från webservicen när man går tillbaka. Du vill också bli navigerad till

den rätta sidan.

92

3.2.6 Samspill mellom tekstsøk og kart

Man har möjlighet ifrån söket att visa ställningar i kartan genom att trycka på knapparna ”vis nære

på kart” eller ”visa alla på kart”. Om man inte har sökt på nått innan man trycker på knapparna så får

man upp ett felmeddelande om att det inte är några ställningar att visa (Figur 47).

Figur 47: Ingen träff på sök

3.2.6.1 Nærheten

Det som sker i bakgrunden är att när man har ett sök som inte resulterar i en träff så har vi redan

sökt igenom alla ställningar och funnit ut vilka som är i närheten av din position. När man då trycker

på vis i närheten knappen så vill man navigera till kartan och visa alla ställningar som är i närheten.

Om den inte finner ställningar i närheten så får man ut ett annat meddelande om att inga ställningar

kunde hittas.

3.2.6.2 Vis alle i kart

Söket som man har gjort på söksidan resulterar ett resultatset från webservicen. Samma URL som

användes sparas ned i en variabel, navigerar till sidan och kallar på webservicen igen. Resultatet är

samma resultatset som visas (Figur 48).

93

Figur 48: Resultat träff på ställningar

3.3 Detaljert visning av stilling

Tillhörande filer:

HTML: detailedPosition.html

JavaScript: detailedPosition.js

Vid navigering till sidan så sattes det en localStorage variabel med ID till den specifika annonsen som

man klickade på. Det är den här ID som används för att hämta ner den riktiga annonsen (Kodelisting

36).

Kodelisting 36: Bygging av web service URL

Eftersom många annonser innehåller olik data så var vi tvungen att köra olika kontroller på vilka fält

som var tillgänglig (Kodelisting 37). Vi gjorde detta simpelt genom att kolla om det som returnerades

var en tom streng eller om det var data i den. Om fallet var att den returnerade en tom streng, så

returnerade vi antingen ett passande meddelande eller så hoppade vi att skriva den ut.

94

Kodelisting 37: Metod för data sortering

Annonsdata till WebCruiter innehåller HTML kod, vi har en metod som tar bort koden (Kodelisting

38). Vi hittade funktionen på [6].

Kodelisting 38: HTML strip

3.3.1 Håndteringer av opphørte stillinger

Efter som annonsdata är dynamiskt, och går emot en live server så kommer vissa annonsdata att vara

borttagen. Då vill AJAX gå in till sin error funktion som returnerar en passande felmeddelande till

användaren(Kodelisting 39).

Kodelisting 39: AJAX error

95

3.4 Søke i kart

Tilhørende filer:

HTML: map.html, Android_map.html

CSS: map.css, CordovaTheme.min.css

JavaScript: map.js

Kartet er svært sentralt i Jobfinder, og denne siden utgjør en stor del av funksjonaliteten i

applikasjonen. Som leseren kan se er det to HTML-sider; grunnen til dette beskrives i

prosessrapporten, kapittel 2.3.2.13.1. Videre gir applikasjonen brukeren mulighet til å lagre

posisjoner – dette er omtalt i kapittel 3.5.

3.4.1 Oppbygning

På overflaten er kartsiden tilsynelatende enkel (Figur 49). Et kart fra Googles API [7] dominerer siden

med en glideskala for å bestemme søkeradius under. Glideskalaen er fra JQuery Mobile, men måten

vi fikk til det på alle plattformer er noe spesiell (se over for referanse til prosessrapport).

Figur 49: Kart-siden vist på Android

Siden kan vise flere typer søkeresultater:

96

Samtlige stillinger innenfor en gitt radius

Et resultatsett fra søkesiden

o Enten innefor den gitte radiusen

o Eller samtlige treff uavhengig av radius

Punkt to innebærer enten et søk på stillingstittel eller på bransje – begge er forskjellige kall til

webservicen.

Dette gjorde at vi måtte lage koden rimelig fleksibel slik at det ville bli enkelt å integrere flere

resultatsett med vising på kartet. Uavhengig av hvor man navigerer fra, har siden en fast hovedflyt

ved førstegangs lasting som består i kall til fire ”hovedfunksjoner”42(Figur 50).

Figur 50: Hovedflyt

Fleksibiliteten ligger i initialize-funksjonen. Etter at denne er ferdig kjørt, vet neste steg i flyten hvilke

data som skal søkes etter og om det skal tas høyde for avstand fra en gitt posisjon. Ved endring av

verdien på glideskalaen trenger kun det siste steget å kjøre; da er all nødvendig data allerede lastet

ned slik at alt som må gjøres er å oppdatere kartet.

3.4.2 Beregning av avstander

For å kunne regne ut avstanden mellom posisjonen det søkes fra43 og en stilling benytter

applikasjonen seg av en spesiell funksjon [8]. Denne er en implementasjon av Haversine formelen [9].

Funksjonen regner ut avstanden mellom to punkter på jordens overflate i kilometer og returnerer

dette(Kodelisting 40).

42 Hver av disse kan ha hjelpefunksjoner 43 Enten nåværende eller en lagret.

97

Kodelisting 40: Haversine formelen i JavaScript. toRad er en funksjon som gjør grader til radianer.

Denne operasjonen gjøres for hver stilling i resultatsettet. Hvis funksjonen returnerer et tall som er

mindre enn den gitte radiusen, blir stillingen lagt til kartet.

3.4.3 Håndtering av interaksjon med kartet

For å sørge for at kun ett informasjonsvindu kan være åpent om gangen, lagres alltid det nåværende

vinduet i en variabel kalt activeWindow. På den måten er det mulig for enhver funksjon å gjøre

operasjoner på dette vinduet. Når et nytt vindu åpnes, sørger en funksjon (Kodelisting 41) for å

oppdatere denne variabelen i tillegg til å lukke et eventuelt åpent vindu.

Kodelisting 41: Funksjon som oppdaterer activeWindow i tillegg til å lukke et allerede åpent vindu

Denne funksjonen benyttes også til å lukke et åpent vindu når kartets zoom_changed-event

aktiveres.

Når et vindu lukkes, settes kartets sentrum på nytt – enten på nåværende posisjon, eller tilbake på

det opprinnelige sentrum hvis kartet viser et resultatsett uten nåværende posisjon. Dette håndteres

litt på samme måte som lukking av aktive informasjonsvinduer: Variabelen initialCenter holder rede

på hvor sentrum skal settes når et vindu lukkes. Lukkingen fanges opp via et event (Kodelisting 42)

98

Kodelisting 42: closeclick-event på et infovindu

3.4.4 Glideskala

Glideskalaen er, som nevnt tidligere, fra JQuery Mobile. Den er utformet ved hjelp av et egendefinert

tema laget ved hjelp av JQuerys ThemeRoller [10]. For å benytte JQuery Mobile behøver man

referanse til tre forskjellige filer. I Android_map.html, som benyttes av iPhone i tillegg til Android, er

disse lagt til på vanlig måte ved hjelp av referanser i HTML-koden (Kodelisting 43).

Kodelisting 43: Referanser til JQM i HTML

På Windows Phone måtte vi derimot gjøre dette på en annen måte. Her lastes disse referansene inn i

deviceready-funksjonen istedenfor. En if-setning(Kodelisting 44) sørger for at map.js fint kan benyttes

av begge kart-sidene uten at det blir konflikter. Vi minner leseren om prosessrapportens kapittel

2.3.2.13.1 hvor det er beskrevet hvorfor dette er løst på denne måten.

Kodelisting 44: Laster inn referanser til JQM hvis plattformen er Windows.

Glideskalaen har to events knyttet til seg. Ett håndterer det som skjer når man drar skalaen til en ny

verdi, mens det andre brukes til å oppdatere kartet når brukeren slipper skalaen. Førstnevnte

benytter change-eventet til å oppdatere tekstlabelen som forteller brukeren hva den nåværende

radiusen er (Figur 51). Skalaen på Windows Phone kan ikke dras grunnet manglede støtte for

touchevents44. Derfor skjer oppdatering av label på denne plattformen samtidig som kartet

oppdateres.

44 Se kapittel 1.1

99

Figur 51: Tallet i den nederste labelen oppdateres når skalaen dras (ikke på Windows Phone)

Det andre eventet (Kodelisting 45) er mer sentralt siden det er dette som gir brukeren mulighet til å

oppdatere kartet. Som nevnt tidligere (Figur 50), trenger kun det siste steget i hovedflyten og gjentas

når glideskalaen flyttes. Før den kommer så langt, er det et par andre ting som må gjøres.

Kodelisting 45: vmouseup-event for oppdatering av kart

Glideskalaens 18 steg skal kunne gi brukeren mulighet til å søke mellom 1 og 120 km. Derfor er det

laget to hjelpefunksjoner som oversetter fra radius til glideskalaverdi og motsatt. Disse er svært enkle

og baserer seg på elementær matematikk. Vi henviser derfor til kildekoden for detaljer rundt disse.

Videre er det nødvendig å fjerne alle markører før kartet oppdateres (da blir nye markører lagt til).

Alle markører som legges til, blir samtidig lagt i en array. Det er denne som løpes igjennom av

removeMarkers-funksjonen. Variabelen slide benyttes til å skrive ut en feilmelding hvis den nye

radiusen ikke ga noen treff på stillinger i nærheten (Kodelisting 46).

100

Kodelisting 46: Variabelen slide i bruk. Legg merke til kommentaren

3.4.5 Informasjonsvinduer, markører og deres funksjon

Alle stillinger, samt brukerens posisjon vises med egne markører på kartet. Hver enkelt bransje45 har

en egen markør knyttet til seg for visning i kartet (Figur 49). Videre har samtlige markører knyttet et

informasjonsvindu til seg. For stillingene gir innholdet på disse mulighet til å vise mer informasjon om

den valgte stillingen(Tilsvarende som vist i Figur 46). Markøren som viser brukerens posisjon derimot

kan ha flere forskjellige informasjonsvinduer avhengig av innloggingsstatus og hvilken posisjon som

vises. (Figur 52)

Figur 52: Informasjonsvinduer: Ikke innlogget, logget inn og visning av lagret posisjon

3.5 Lagring av posisjon

Tilhørende filer:

HTML: storedLocs.html

JavaScript: storedLocs.js

45 Bransjer omfatter for eksempel Politi, IT, Helse og Sosial m.m.

101

Vi benytter localStorage til å gi brukeren mulighet til å lagre flere posisjoner for senere bruk. Som

nevnt i avsnitt 1.2, kan localStorage kun lagre strenger, så hvordan klarte vi å lagre flere posisjoner?

Løsningen ligger i JavaScripts innebygde JSON-objekt. Dette har funksjoner for å gjøre om andre

objekter, for eksempel en array, til en tekststreng og for å lese det tilbake igjen (Kodelisting 47).

Kodelisting 47: JSON.stringify og JSON.parse brukt med localStorage

Ved å lagre lengde- og breddegrader, samt navn på lokasjonene i tre arrayer, kunne vi bruke disse

funksjonene til å oppnå den funksjonaliteten vi ønsket.

Hvis brukeren er logget inn, får man muligheten til å lagre posisjon via infovinduet på markøren som

viser nåværende posisjon (Figur 52). Trykker man på knappen, blir arrayene for lengde- og

breddegrader oppdatert og skrevet til localStorage på nytt. Deretter navigeres man til siden

”Administrer steder”.

Siden bruker JQuery for å få en dynamisk oppbygging: Hvis brukeren har valgt en posisjon for lagring,

vises en lagreboks øverst. Ellers vises en infoboks med mulighet for sletting (Figur 53)

102

Figur 53: Lagreboks til venstre og infoboks med slett til høyre

Ved lasting av siden, blir arrayene for navn, lengde- og breddegrader lest inn. I tillegg leses

localStoragevariabelen newLoc – hvis denne ikke er null, vet siden at brukeren har valgt å lagre en

posisjon (Kodelisting 48). Da vises skjermbildet til venstre i figuren over. Ellers vises det andre

skjermbildet.

103

Kodelisting 48: Dynamisk JQuery for lasting av "Administrer steder"

Når brukeren huker av i checkboxen, settes en variabel slik at funksjonen som kalles ved trykk på et

listeelement, vet hva den skal gjøre. Er sletting på, fjerner den elementet fra siden samtidig som de

tilhørende data slettes fra localStorage (Kodelisting 49). I motsatt fall fungerer et trykk på et

listeelement på samme måte som når man trykker på ”Stillinger i nærheten” i hovedmenyen. Eneste

forskjell er at den nåværende posisjonen erstattes med den lagrede.

Kodelisting 49: Håndtering av trykk på listeelement

104

Hvis man navigerer bort fra siden uten å lagre, blir ulagret data slettet. Dette gjøres veldig enkelt ved

at lengden på arrayen med breddegrader46 sammenliknes med den for navn. Hvis disse ikke er like,

slettes de to siste elementene fra lengde-/breddegrad-arrayene før det navigeres bort fra siden.

Et problem med denne løsningen er at de lagrede posisjonene blir knyttet opp mot telefonen

istedenfor mot brukeren. Funksjonaliteten kan derfor sees på som et ”proof of concept”.

4 Design

Hoveddesignet er samlet i filen main.css. I noen tilfeller har det vært nødvendig med modifiserte

varianter av stiler i denne filen.

Skjermbildet på appen er delt opp i to deler på de sidene der det er relevant47; header og container

(Figur 54). Header og footer blir brukt til navigeringsknapper (hjem, fram, tilbake, evt plassering av

logo). Container fungerer som en slags body for innholdet.

Figur 54: Header og container

Containeren har en automatisk høyde, som gjør at innholdet alltid får plass og at en eventuell footer

alltid havner nederst. Vi tenkte først å ha footeren fast i bunnen av skjermen å ha en scroll på

containeren, men dette ser ut til å bli oversett på Android. Derfor valgte vi løsning med automatisk

høyde, uten at vi ser på det som et problem.

På kartsiden har vi implementert egne ikoner på markørene til hver bransje som er tilgjengelig. Helse

og Sosial har for eksempel et rødt kors, mens IT har en PC som ikon.

46 Denne har alltid samme lengde som arrayen med lengdegrader. 47 For eksempel ikke relevant på kartet

105

Applikasjonen er utviklet med forbehold for både portrait- og landscapevisning. CSS’en fungerte i

utgangspunktet like godt på de fleste HTML-sidene i både landscape og portrait. Håndtering av når

man snur skjermen skjer automatisk ved at tekst og elementer blir zoomet inn og størrelsen tilpasset

i landscape-visning. I flere av sidene fungerte ikke dette like godt, eller vi var misfornøyde med

håndteringen.

Da håndterte vi dette selv ved å implementere EventListeneren orientationChange. I denne

funksjonen (Kodelisting 50) byttet vi fra portrait-CSS til landscape-CSS og vice versa ut ifra hvilken

visning som allerede var valgt. Disse CSS-stilene var ikke veldig ulike, men inneholdt endringer på

blant annet bredde, høyde og plassering av elementer. Noen forandringer var mer omfattende enn

på andre sider.

Kodelisting 50: Funksjon som tar seg av panorering av skjerm

CSS’en som trengte mest jobb når det gjaldt håndtering av landscape, var kart på iOS-plattformen.

Når skjermen her ble snudd til liggende stilling, ble kun kartet vist og ikke selve glideskalaen som skal

ligge under kartet. Ytterligere CSS-klasser (Kodelisting 51) måtte derfor til.

Kodelisting 51: Eksempler på forskjellige klasser for håndtering av orientation

iPhone hadde i tillegg problemer med meta-tags. Til vanlig ser en meta-tag slik ut:

Kodelisting 52: Meta-tag

På iPhone laget en av egenskapene i content problemer. Dette var ”height=device-height”. Hvis

denne var på plass, oppdaterte ikke iPhone seg riktig i forhold til landscape-visning (Figur 55).

106

Figur 55: Meta-tag problem på iPhone

Løsningen ble å fjerne denne egenskapen fra meta-tag’en. Etter denne endringen fungerte det slik

det skulle (Figur 56).

Figur 56: Meta-tag løsning

5 Diskusjon: Webapplikasjon eller native?

Når vi har arbeidet med native kryssplattformutvikling ved hjelp av webteknologier, har vi ikke

kunnet unngå å stille oss spørsmålet; ”kunne vi ikke gjort dette som en ren webapplikasjon?”. Vi kan

dra det enda lenger og spørre oss det samme spørsmålet uavhengig av metode for native utvikling.

Hva egner seg best til en applikasjon av samme type som vår – web eller native?

107

Figur 57: Web vs native

5.1 Kryssplattform En av de aller største fordelene med webapplikasjoner er at det er tilnærmet 100% kryssplattform

uten at man trenger noe å laste ned noe rammeverk for å gjøre det slik. Videre er det mulig å dra

nytte av kode man allerede har hvis man skal lage en mobilversjon av et allerede eksisterende

nettsted48 (Figur 58). Det eneste som drar ned mengden felles kode, er det samme som for vår native

applikasjon: browserulikheter.

Figur 58: Norsk topphåndball sine sider skalert til mobil

48 Responsive design (http://en.wikipedia.org/wiki/Responsive_Web_Design)

108

Andre native kryssplattform rammeverk har ikke dette problemet, men de har til gjengjeld mye

mindre muligheter for deling av kode. Vi har enda til gode å se et rammeverk som benytter språk

som C# eller Java til å oppnå like mye felles kode som en webapplikasjon.

5.2 Utseende Webapplikasjoner ser tradisjonelt ut som det de er – nettsider som kjører i telefonenes respektive

nettlesere (Figur 58). Men det er mulig å oppnå en mer native følelse ved å benytte CSS til å

etterlikne utseende til native applikasjoner49. Ved å gjøre det minker man selvsagt mengden felles

kode, og derfor ser man svært få (om noen) webapplikasjoner som gjør dette over alle plattformer.

Hvis man jobber med native applikasjonsutvikling, enten ”vanlig”50 eller ved hjelp av et rammeverk

som Mono, vil utseende alltid bli som man forventer på den aktuelle plattformen. Ulempen er nok en

gang mengden felles kode – uten et rammeverk vil denne være ikke-eksisterende.

5.3 Utviklingsprosessen Det som kanskje veier aller tyngst i valget av metode er hva valget vil ha for påvirkning på

utviklingsprosessen. Uten bruk av kryssplattformrammeverk, vil det å lage en applikasjon for iPhone,

Android og Windows Phone kreve kunnskaper om tre forskjellige programmeringsspråk. Bruker man

et rammeverk, trenger man kanskje kun kjennskap til ett. Uavhengig av det har utviklingsprosessen

til native applikasjoner enkelte trekk som ikke går igjen i webapplikasjoner.

5.3.1 Lisenser

Utvikler man for web kreves ingen spesielle lisenser. Skal man derimot lage en native applikasjon for

de samme plattformene som vi har gjort, kreves potensielt flere. Utviklerlisens for iPhone og

Windows Phone må man uansett ha, men i tillegg kommer potensielle lisenser for rammeverk. For en

stor bedrift er ikke dette nødvendigvis noe problem, men for en mindre bedrift kan flere tusen

dollar51 i året være utslagsgivende.

5.3.2 Debugging/testing

En webapplikasjon lever på en server og er tilgjengelig via en URL. Utviklere vil derfor aldri trenge å

kompilere koden og installere en debugversjon av en applikasjon for å teste nyskrevet kode. Når man

jobber med native derimot er dette uunngåelig. Selv med et rammeverk som PhoneGap, kommer

man ikke unna behovet for tre ulike utviklingsmiljøer og kompilering i hvert av disse til de ulike

plattformene (Figur 59).

49 Eksempler kan finnes her (http://www.scottlogic.co.uk/blog/colin/2011/09/developing-windows-phone-7-html5-apps-with-phonegap/) og her (http://ofps.oreilly.com/titles/9780596805784/) 50 Objective C, Java, Silverlight for Windows Phone (C#) 51 Mono rammeverkene koster $2500 per stykk.

109

Figur 59: Utviklingsflyt

For én test vil ikke tidsforskjellen være stor mellom native og web, men gjennom en lengre

utviklingsprosess vil det utgjøre en betydelig forskjell. Fra vårt ståsted er dette grunnen til at native

applikasjoner gjerne lages til én plattform om gangen kontra alle på en gang. Da er det i det minste

bare én kompilering som skal gjøres hver gang man tester noe nytt.

5.3.3 Brukertester

Som sagt er en webapplikasjon tilgjengelig på en URL på nettet. Denne er derfor langt mer

tilgjengelig for brukere enn en native applikasjon som må lastes ned og installeres. Ved utføring av

brukertester, er det derfor langt enklere å nå ut til mange med en webapplikasjon.

Det er også lettere å gjøre justeringer underveis i testen og samtidig være sikker på at alle deltakere

har fått denne justeringen på sin telefon. Ending av én linje kode på en native applikasjon krever at

brukeren må laste ned en oppdatering for å få denne med seg52, mens for en webapplikasjon må

man i verste fall laste siden på nytt.

52 Dette gjelder uansett om man er i en testfase eller i release

110

5.3.4 Distribusjon

De samme tilgjengelighetsproblemene som ved brukertester vil dukke opp når man skal distribuere

applikasjonen. Native applikasjoner må via de respektive App-Stores53 som for det meste er

underlagt visse krav – krav som kanskje gjør at man må tilpasse design og oppbygning på sin løsning

for i det hele tatt å få lov til å gi den ut.

På en annen side er det lettere å markedsføre en native applikasjon. Alle App-Stores har mulighet til

å vise ting som ”Anbefalte apper”, ”Nye apper” og lignende. Slik kan utgivere synliggjøre sine

produkter på en mye billigere og enklere måte enn med løsninger som er native. Med en

webapplikasjon vil man være avhengig av reklamekampanjer på andre nettsteder for å skape

oppmerksomhet rundt sitt produkt.

5.4 Versjoner Når man lager et nytt prosjekt for en native applikasjon får man alltid det samme spørsmålet: Hvilken

versjon av operativsystemet er applikasjonen myntet på? (Figur 60) Her må man vurdere om man

ønsker å nå ut til så mange som mulig, eller om man vil dra nytte av funksjonalitet i nyeste versjon av

det aktuelle operativsystemet.

Figur 60: Forskjellige versjoner ved start av nytt Androidprosjekt

På websiden har man ikke dette problemet i samme grad. Det finnes forskjellige versjoner av

nettlesere, men ikke på samme måte.

Uansett er dette problemet mest gjeldene på én plattform: Android. Her florerer det av telefoner

med forskjellige utgaver av operativsystemet, mens for Windows Phone er det i skrivende stund stort

sett bare 7.5 og iPhone stort sett bare 5.1. Det blir dog spennende å se om WP-brukere får

oppgradere til Windows Phone 8 uten ekstra kostnad.

5.5 API-tilgang Ett felt der native er fullstendig overlegen web er i forhold til interaksjon med telefonenes API’er.

Enkelte ting, som posisjon, går an å få tilgang til i en webapplikasjon uten for mye hokuspokus. Men

mer komplekse ting som å ta bilder og behandle disse krever native tilgang.

Derfor vil en applikasjon som krever mye API-tilgang, uavhengig av hvor stor felles kodebase man vil

ha, la seg enklest løse som en native applikasjon. I noen tilfeller vil det bare la seg løse slik.

53 Google Play, App Store og Windows Markedplace

111

5.6 Konklusjon Uansett hvilke aspekter man ser på, koker det hele ned til et enkelt spørsmål: Hva slags applikasjon

skal du lage?

Hvis applikasjonen har mye databehandling, burde store deler ligge på en server som gjør dette. Da

er det ikke særlig brukervennlig hvis dette sendes til telefonen før det er formattert på riktig måte.

Løser man et slikt scenario native, innebærer det at applikasjonen stort sett står igjen som et slags

GUI-skall for en applikasjon som kjører på serveren. Da mener vi at en webapplikasjon er en bedre

løsning. Det er mer hensiktsmessig og det vil samtidig minke mengden data telefonen trenger å laste

ned siden serveren da kan dra mer av lasset (Figur 61).

Figur 61: Kommunikasjon mellom telefon og server

Man vil dog kunne oppnå samme effekt som ved en webapplikasjon når man bruker PhoneGap, men

da er vi nok en gang inne på dette med GUI-skall. Særlig hvis alt applikasjonen gjør er å motta ferdig

formattert HTML fra serveren som så presenteres. Men hvis applikasjonen samtidig skal ha tilgang til

de av telefonens API’er som ikke er tilgjengelige for en webapplikasjon, vil dette være

hensiktsmessig.

Vi mener at applikasjoner av samme type som den vi har laget i forbindelse med dette prosjektet i

større grad vil forsvinne som native applikasjoner i fremtiden. Eventuelt vil det finnes både en native-

og en webversjon slik som applikasjoner som for eksempel Facebook gjør.

112

Tabellene under oppsummerer fordeler og ulemper ved henholdsvis webapplikasjoner og

nativeapplikasjoner:

Fordeler Ulemper

Kryssplattform Browser-ulikheter

Ikke kompilering Vanskelig å oppnå naturlig utseende

Ingen komponenter som må lastes ned på forhånd.

Vanskelig å få tilgang til API’er

Ingen distribuering Vanskelig å markedsføre

Samler alt på et sted

(på server)

Krever ingen lisenser

Oppdatering skjer på server

Skalere eksisterende webside (spør lena)

Lettere med brukertester

Tabell 13: Fordeler og ulemper ved webapplikasjoner

Fordeler Ulemper

Kan være kryssplattform Må bruke rammeverk for å oppnå kryssplattform

Lettere å oppnå naturlig utseende. Må kompileres

Kan ha offline innhold Må distribueres via appstores.

Full tilgang til API’er Apper med mye nettbaserte funksjoner blir ”GUI-skall” med server-backend.

Potensielt raskere Går mot spesifikke versjoner av OS

Enklere å markedsføre Må ha lisenser

Må sende ut oppdateringer til bruker.

Tabell 14: Fordeler og ulemper ved native applikasjoner

113

6 Konklusjon

Vår endelige konklusjon trekkes på bakgrunn av erfaringer vi har gjort gjennom utviklingen i tillegg til

det som ble drøftet i forrige kapittel; webapplikasjon vs native.

Etter å ha laget en stor testapplikasjon, som Jobfinder er, har vi fått et omfattende inntrykk av

PhoneGap: hvordan det er å jobbe med og hvordan det presterer i praksis.

Måten vår applikasjon er bygget opp på gjør at det er betydelig mer bruk av JavaScript til

applikasjonslogikk enn det ville vært i en tilsvarende webapplikasjon. Hadde Jobfinder vært en

webapplikasjon, hadde mye av denne logikken vært lokalisert på server.

Vi mener fremdeles at PhoneGap er et svært godt rammeverk for kryssplattform utvikling, men man

kommer ikke unna de samme problemene som eksisterer når man jobber med webapplikasjoner. I

tillegg er det lettere å la en server gjøre mer av grovarbeidet med en webløsning.

Derfor mener vi at den beste tilnærmingen for WebCruiter er å lage en webapplikasjon. Ønsker man

fremdeles å lage en native versjon etter dette, er PhoneGap definitivt den beste løsningen. Det vil

være enkelte tilpasninger som må gjøres (avhengig av oppbygning på webapplikasjonen), men ikke i

nærheten av så mye som hvis man velger Mono (som vi mener er en sterk toer).

Skulle WebCruiter allikevel ønske å kjøre native fra starten av, holder vi fremdeles på PhoneGap som

det beste alternativet. Det gir mest felles kode, er lettest å jobbe med samtidig som det krever lite

arbeid å gjøre om til en webapplikasjon hvis det er ønskelig.

7 Kilder

7.1 Internettreferanser

1 http://en.wikipedia.org/wiki/Android_(operating_system)

[Sist besøkt: 02.05.2012]

2 http://en.wikipedia.org/wiki/WebKit

[Sist besøkt: 03.05.2012]

3 http://docs.phonegap.com/en/1.5.0/phonegap_storage_storage.md.html#localStorage

[Sist besøkt: 16.05.2012]

4 http://stud.webcruiter.com/operations.asmx

[Sist besøkt: 25.05.2012]

5 http://developer.bring.com/use/widget/validatepostalcode.html

[Sist besøkt: 22.05.2012]

6 http://stackoverflow.com/questions/822452/strip-html-from-text-javascript

114

[Sist besøkt: 18.05.2012]

7 https://developers.google.com/maps/documentation/javascript

[Sist besøkt: 15.05.2012]

8 http://www.movable-type.co.uk/scripts/latlong.html

[Sist besøkt: 19.05.2012]

9 http://en.wikipedia.org/wiki/Haversine_formula

[Sist besøkt: 19.05.2012]

10 http://jquerymobile.com/themeroller/

[Sist besøkt: 13.05.2012]

11 http://en.wikipedia.org/wiki/Responsive_Web_Design

[Sist besøkt: 22.05.2012]

12 http://www.scottlogic.co.uk/blog/colin/2011/09/developing-windows-phone-7-html5-apps-

with-phonegap/

[Sist besøkt: 22.05.2012]

13 http://ofps.oreilly.com/titles/9780596805784/

[Sist besøkt: 22.05.2012]

14 http://www.javascriptkit.com/javatutors/loadjavascriptcss.shtml

[Sist besøkt: 10.05.2012]

15 http://phonegap.com/

[Sist besøkt: 20.05.2012]

16 http://phonegap.com/about/features

[Sist besøkt: 15.04.2012]

17 http://phonegap.com/support#support-packages

[Sist besøkt: 12.04.2012]

18 http://groups.google.com/group/phonegap

[Sist besøkt: 18.04.2012]

19 http://wiki.phonegap.com/w/page/16494772/FrontPage

[Sist besøkt: 20.04.2012]

115

20 http://developer.android.com/sdk/index.html

[Sist besøkt: 10.04.2012]

21 http://developer.android.com/sdk/ndk/index.html

[Sist besøkt: 10.04.2012]

22 http://developer.android.com/sdk/ndk/overview.html

[Sist besøkt: 10.04.2012]

23 http://developer.android.com/sdk/eclipse-adt.html

[Sist besøkt: 10.04.2012]

24 http://www.techjail.net/starting-programming-for-android-with-netbeans.html

[Sist besøkt: 10.04.2012]

25 http://developer.android.com/guide/publishing/app-signing.html#debugmode

[Sist besøkt: 10.04.2012]

26 http://developer.android.com/guide/developing/device.html

[Sist besøkt: 10.04.2012]

27 https://blogs.oracle.com/geertjan/entry/procedure_for_android_development_on

[Sist besøkt: 11.04.2012]

28 http://code.google.com/intl/no-NO/android/add-ons/google-apis/mapkey.html

[Sist besøkt: 12.04.2012]

29 http://developer.android.com/sdk/win-usb.html

[Sist besøkt: 10.04.2012]

30 http://handheld.softpedia.com/get/Drivers/HTC-Hero-Drivers-81097.shtml

[Sist besøkt: 13.04.2012]

31 https://developer.apple.com/xcode/

[Sist besøkt: 16.04.2012]

32 https://developer.apple.com/ios/manage/overview/index.action

[Sist besøkt: 24.04.2012]

33 http://www.microsoft.com/download/en/details.aspx?id=27570

116

[Sist besøkt: 26.04.2012]

34 http://www.microsoft.com/maps/developers/web.aspx

[Sist besøkt: 08.05.2012]

35 http://www.codeproject.com/Articles/153467/Google-Maps-for-Windows-Phone-7-using-

Bing-Map-Con

[Sist besøkt: 12.05.2012]

36 http://code.google.com/intl/no-NO/android/add-ons/google-apis/mapkey.html

[Sist besøkt: 28.04.2012]

37 http://msdn.microsoft.com/en-us/library/ff769508(v=vs.92).aspx)

[Sist besøkt: 26.04.2012]

38 http://create.msdn.com/en-US/home/about/developer_registration_walkthrough

[Sist besøkt: 20.04.2012]

39 http://wiki.phonegap.com/w/page/30862722/phonegap-android-eclipse-quickstart

[Sist besøkt: 16.04.2012]

40 http://jquery.com/

[Sist besøkt: 25.05.2012]

41 http://jquerymobile.com/

[Sist besøkt: 24.05.2012]

42 http://googlegeodevelopers.blogspot.com/2010/03/introducing-new-google-geocoding-

web.html

[Sist besøkt: 04.05.2012]

43 http://docs.phonegap.com/en/1.4.1/index.html

[Sist besøkt: 16.05.2012]

44 http://ofps.oreilly.com/titles/9781449383268/ch02_id35816688.html

[Sist besøkt: 15.05.2012]

45 http://www.leemunroe.com/css-button/

[Sist besøkt: 13.05.2012]

46 http://www.dreamintech.net/2011/11/how-to-setup-and-use-nativecontrols-in-phonegap/

117

[Sist besøkt: 06.05.2012]

47 http://www.evoluted.net/thinktank/web-development/google-maps-api-v3-custom-

location-pins

[Sist besøkt: 09.05.2012]

48 http://docs.phonegap.com/en/1.4.1/phonegap_connection_connection.md.html#Connectio

n

[Sist besøkt: 15.05.2012]

49 http://yoavniran.wordpress.com/2009/08/02/creating-a-webservice-proxy-with-jquery/

[Sist besøkt: 16.05.2012]

50 http://www.iphonedevsdk.com/forum/iphone-sdk-development/10226-line-break-

uilabel.html

[Sist besøkt: 10.05.2012]

51 http://troybrant.net/blog/2010/01/set-the-zoom-level-of-an-mkmapview/

[Sist besøkt: 06.05.2012]

52 http://stackoverflow.com/questions/1166444/mkmapview-zoom-and-region

[Sist besøkt: 01.05.2012]

7.2 Bokreferanser

53 Allen, Sarah : Graupera, Vidal : Lundrigan, Lee (2010) : Pro SamrtPhone Cross-Platform

Development. iPhone, BlackBerry, Windows Mobile, and Android Development and

Distribution : New York : Apress