Produktrapport - HiOAstudent.cs.hioa.no/hovedprosjekter/data/2012/15/... · 2012-05-31 · 1 Forord...
Transcript of Produktrapport - HiOAstudent.cs.hioa.no/hovedprosjekter/data/2012/15/... · 2012-05-31 · 1 Forord...
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: [email protected].
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