View
11
Download
0
Category
Preview:
Citation preview
Datavetenskap
Claes Barthelson
PaddelAppen
Examensarbete
2015:01
PaddelAppen
Claes Barthelson
c© 2015 Författarna och Karlstads Universitet
Denna rapport är skriven som en del av det arbete som krävs för att
erhålla en kandidatexamen i datavetenskap. Allt material i denna
rapport, vilket inte är mitt eget, har blivit tydligt identifierat och
inget material är inkluderat som tidigare använts för erhållande av
annan examen.
Claes Barthelson
Godkänd, 2015-01-15
Handledare: Annika Klockar
Examinator: Donald F. Ross
iii
Sammanfattning
Mobila lösningar blir allt vanligare och appar kan utvecklas för att hjälpa mobilanvändare
med det mesta. Att utveckla appar är populärt och kan göras i en mängd olika språk och
utvecklingsmiljöer, och projektet har haft som mål att både utveckla en användbar app
och utvärdera en sådan utvecklingsmiljö.
PaddelAppen som utvecklats i projektet fyller ett tomrum genom att vara en resurs för
paddelintresserade. Samtidigt har utvecklingsarbetet resulterat i en utvärdering av utveck-
lingsmiljön Xamarin, som använts tillsammans med Visual Studio för att plattformsobe-
roende utveckla appen för både Android och Windows Phone.
v
Abstract
Mobile solutions are increasingly popular and apps can be developed to help mobile users
with almost anything. To develop is, as a result, also popular and can be done in a number
of programming languages and development environments, and the goal of this project was
to both develop a useful app and simultaneously evaluate such an environment.
PaddelAppen, the app developed in this project, fills a void by providing a resource
for paddlers. At the same time the development has resulted in an evaluation of Xamarin,
the development environment used together with Visual Studio to develop the app, cross-
platform, for both Android and Windows Phone.
vi
Innehåll
1 Introduktion 1
1.1 Projektsammanställning och översikt . . . . . . . . . . . . . . . . . . . . . 1
1.2 Projektresultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Bakgrund 3
2.1 Om Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Problemområde och bakgrundsinfo . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Att använda Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Xamarin.Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.3 MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4 Karta och kartpunkter . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.5 Databas för kartpunkter . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.6 XML-databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.7 SQL-databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.8 Användare, rättigheter och informationsinsamlande . . . . . . . . . 9
2.3 Kapitelsammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Projektdesign 11
3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Detaljer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 ViewModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Controllers och Custom Renderers . . . . . . . . . . . . . . . . . . . 19
3.3 Kapitelsammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Implementation 21
vii
4.1 Detaljer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2 ViewModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.6 Custom Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.7 Custom Renderers . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.8 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Resultat och Utvärdering 34
5.1 Introduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2 Implementationsbeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Utvärdering av app-utvecklingen . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4 Utvärdering av Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4.1 Diskussion kring Xamarin . . . . . . . . . . . . . . . . . . . . . . . 42
5.4.2 Alternativ till Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Kapitelsammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6 Slutsats 48
6.1 Slutsats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Projektutvärdering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.4 Framtida arbete - utveckling av projektet . . . . . . . . . . . . . . . . . . . 52
viii
Figurer
1.1 Prioriteringspunkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Översikt av projektet enlig MVVM . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Navigationssida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Listsida och navigationssida . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Nära vy av detaljsidan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Översikt över hur kartan får sin extra funktionalitet . . . . . . . . . . . . . 32
5.1 Startmenyn i implementationen . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Kartan i implementationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Listan i implmentationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.4 Detailjsidan i implementationen . . . . . . . . . . . . . . . . . . . . . . . . 39
5.5 Punkter i närheten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1 Prioriteringspunkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ix
1 Introduktion
Projektets mål var att utveckla en app för paddlare i vilken man kan hämta information om
platser som kan vara bra att känna till som paddlare samt att testa och utvärdera utveck-
lingsmiljön Xamarin. En kravspecifikation enligt figur 1.1 togs fram för appen. Ett antal
funktioner listades och gavs en prioritet efter hur viktig funktionen ansågs vara för appen.
Alla funktioner utom den med lägst prioritet, användarinloggning, har implementerats i
appen och störst vikt har lagts vid att få en väl fungerande karta. Därefter har en utvärde-
ring av hur väl Xamarin är lämpat för att åstadkomma detta gjorts. Dessutom diskuteras
olika utvecklingsmetoder som Xamarin erbjuder där fördelar vägs mot nackdelar.
Motivationen till projektet har kommit från två håll. Själva appidén i sig var ett resultat
av ett personligt fritidsintresse där IT-lösningar ofta saknas samt en önskan om att kunna
utforska vackra platser med hjälp av sin smartphone. En app där man kan hitta bra vatten
att paddla, hyra sin kajak eller sätta upp sitt tält är något som idag saknas.
Projektet skrevs på Sogeti i Karlstad och den andra delen i motivationen var Sogetis
önskan att se hur Xamarin fungerar och hur väl det lämpar sig för utveckling av appar
på flera plattformar och är anledningen till att just Xamarin använts och att projektet
utvecklats till två plattformar, Android och Windows Phone. En stor del av det resultat
som presenteras i rapporten är därför en utvärdering av hur Xamarin har upplevts under
projektperioden.
1.1 Projektsammanställning och översikt
Projektet har bestått av apputveckling och rapportskrivning med stor vikt vid den utvär-
dering som finns under resultat.
1
Figur 1.1: Prioriteringspunkter
1.2 Projektresultat
De förväntade projektresultaten var en app färdig att använda samt en rapport där utvärde-
ring är en viktigt del men som också förklarar appens uppbyggnad och utvecklingsförloppet.
2
2 Bakgrund
Utvecklingsmiljöer för att utveckla appar till flera plattformar samtidigt är visserligen inget
ovanligt nuförtiden [Bes], men att kunna göra det i C# och med gemensam kod för nästan
allting [Inci] är både nytt och intressant. Sogeti föreslog att utvecklingen av PaddelAppen
skulle ske i Xamarin för att få en idé om hur bra det fungerar, något som verkade kunna
bli både intressant och lärorikt.
2.1 Om Xamarin
Xamarin är en utvecklingsmiljö som tillåter plattformsoberoende utveckling av appar i C#
[Inci]. Utvecklingsmiljön existerar som en egen IDE samt integrerad i Visual Studio [Incf]
och kommer i två varianter, Xamarin för iOS och Xamarin för Android. Eftersom man
kan utveckla i Visual Studio finns därtill även stöd för Windows Phone. Programvaran är
byggd på .NET-ramverket Mono [Ale].
Idén är att man ska kunna dela så mycket kod som möjligt mellan de olika plattformar-
na, och på så sätt kunna skriva en app en gång, men ändå göra den tillgänglig på samtliga
plattformrar.
Enligt Xamarin själva ska man kunna dela upp till 90% [Inci] av all kod mellan de olika
mobila plattformarna. Resten av koden får anpassas till vardera plattform [Incj], och detta
gäller till största del gränssnittet, som kommer behöva se lite annorlunda ut på de olika
plattformarna. Här ger Xamarin dessutom möjligheten att designa gränssnitt i en grafisk
designer för vardera plattform.
Xamarin erbjuder även ett API för gränssnittskontroller [Incy] som kan delas mellan
alla plattformar för att ytterligare utöka den delade kodbasen, kallad Xamarin.Forms.
Xamarin.Forms kan designas i Extensible Application Markup Language, XAML [Micd;
Micg], eller C# och innehåller de flesta gränssnittselement från de tre plattformarna.
3
2.2 Problemområde och bakgrundsinfo
2.2.1 Att använda Xamarin
Xamarin kommer som tillägg till Visual Studio [Incf] eller som fristående miljö i form av
Xamarin Studio [Ince]. För att jobba mot Android eller iOS behöver man köpa en licens av
Xamarin avsedd för respektive ändamål [Inci], vill man jobba mot Windows Phone finns
det redan stöd i Visual Studio och man kan därför använda Xamarin utan licens. För att
jobba med iOS behöver man dessutom tillgång till en Mac - antingen att jobba på eller
använda som build server [Inco]
När man skapar ett projekt i Xamarin gör man det för en eller flera plattformar sam-
tidigt. I projektet ingår sedan flera underliggande projekt, ett för koden som delas mellan
de plattformar som inkluderats samt ett projekt för varje plattform [Inch]. För detta pro-
jekt skapas alltså ett Android/Windows Phone-projekt med totalt tre underliggande delar.
Utvecklingen av projekt sker sedan i programspråket C#, det språk som används vid ut-
veckling för Microsofts plattformar, och det som används för Windows Phone även i vanliga
fall. Att detta fungerar för Android och iOS, som använder Java respektive Objective-C,
beror på att Xamarin vid kompilering översätter från C# till rätt språk för vardera platt-
form [Incs].
All bakomliggande kod, såsom logik och databaser skrivs sedan i den del av projeket
som delas mellan plattformarna. Man har sedan två alternativ på var koden som utgör
användargränssnittet kan skrivas. Xamarin erbjuder nämligen användaren att bygga an-
vändargränssnitt separata, antingen med Xamarins visuella designer eller via kod, så att
man kan anpassa gränssnitten efter plattform, och dessa skrivs då i den del av projektet
som hör till respektive plattform [Incg]. Vill man hellre hålla ihop allting i den gemen-
samma kodbasen, även användargränssnitt, kan man använda Xamarins kontrollbibliotek,
Xamarin.Forms [Incy], som är en uppsättning kontroller som skrivs i XAML eller C# och
fungerar plattformsoberoende. Här får man dessutom möjlighet att (likt exempelvis utveck-
4
ling för Windows Phone) använda ModelViewViewModel-designmönstret [Gos], MVVM,
fullt ut med hjälp av MVVMCross [autc], något som kan vara en fördel för den som är van.
2.2.2 Xamarin.Forms
För att göra utvecklingen i Xamarin än mer enhetlig har Xamarin.Forms[Incc] utvecklats,
för att man ska kunna utveckla ett gränssnitt gemensamt för alla plattformar, istället för
ett gränssnitt för vardera. Xamarin.Forms är ett API som innehåller de flesta gränssnitts-
kontroller som finns över de tre plattformarna och låter användaren skriva ett gränssnitt
som sedan kan användas i alla plattformar genom att koden mappas mot motsvarande
interface-element på vardera plattform.
Xamarin.Forms kan designas både i C# och XAML och påminner således mycket om
Windows Presentation Foundation [Micf; Mich] eller Windows Phone-utveckling, och stö-
der alla vikta gränssnittskontrollers [Incy]. Men det finns begränsningar. Till exempel är
kartan, som är en viktig del i PaddelAppen, en av de kontroller som är minimalt utrustad
i Xamarin.Forms [Incv]. Funktionaliteten sträcker sig här såpass långt att det går att ta
fram en karta och det går att sätta ut punkter på kartan med hjälp av koordinater, men
därutöver finns inga fler funktioner. PaddelAppen kräver fler funktioner än så, och behöver
använda de plattformsspecifika kartorna istället för de som finns i Xamarin.Forms.
En nackdel med att använda Xamarin.Forms är att det inte finns något officiellt [Jas;
Dan] IntelliSense, en funktionalitet som erbjuder förslag på vad du försöker skriva när
du påbörjat ett ord, som man kanske är van vid om man skrivit XAML i Visual Studio
tidigare. Det finns dessutom inget bra sätt att hitta fel i XAML-koden, utan den enda
feedback man får är ett generellt felmeddelande vid kompilering, som inte erbjuder några
ledtrådar.
5
2.2.3 MVVM
Model-View-ViewModel [Gos] är ett designmönster eller standard att försöka hålla sig till
när man bygger mjukvara, vilken är till för att hjälpa utvecklaren skilja på kod med olika
uppgifter. I just MVVM skiljer man kod som rör användargränssnittet samt logiken bakom,
som i sin tur är uppdelad i logik som utnyttjas av användargränssnittet samt logik som
används i den bakomliggande koden.
När man kodar enligt MVVM delar man upp alla klasser i tre separata klasstyper. Alla
klasser som hanterar gränssnitt och ren gränssnittslogik är Views, medan klasser som hör
till backenden samt all data är Models. De klasser som binder ihop Views och Models,
alltså de som gör datan och logiken presenterbar i gränssnittet, är ViewModels.
ViewModels ska tillhandahålla egenskaper som Views kan binda mot och metoder som
Views kan använda samt ha koll på när olika Event triggas så att de kan reagera på detta
och uppdatera det som Views binder mot så att det får genomslag till gränssnittet. Views
i sin tur ska bygga upp gränssnittet och eventuellt hantera sådan logik som behövs för att
åstamdkomma önskat utseende i detsamma, samt binda mot egenskaper och metoder i sin
underliggande ViewModel.
För att fullt ut kunna anpassa sig efter MVVM i Xamarin finns hjälpmedel som
MVVMCross [autc].
2.2.4 Karta och kartpunkter
Den kanske mest vitala delen i appen är användning av kartan, då översikt över alla platser
som finns lagrade i databasen är den viktigaste delen i appens utformning. Kartorna är den
centrala delen i att skapa denna översikt. Appen måste alltså först och främst kunna visa
en karta. Kartor kan verka komplicerat i sig, men eftersom appen skrivs för Android och
Windows Phone kan deras respektive API:er för kartor användas. Det enda som krävs är
egentligen att man registrerar sig hos Google och får en nyckel som låser upp användningen
av deras API, samt för Windows Phone att man gör ett par inställningar i config-filen i
6
det projektet.
Sedan finns två alternativ för implementation av kartor i appen. Det första alternativet
är att använda kart-API:er för varje plattform för sig. Det vill säga, i Android-projektet
används Androids kart-API och i Windows Phone-projektet används Windows kart-API.
Den här koden skulle alltså inte delas utan vara separat för vardera plattform.
Men det finns möjligheter i Xamarin att utöka den gemensamma kodbasen till gräns-
snittet genom att använda Xamarin.Forms. Xamarin.Forms är skapat av Xamarin och är
en samling gränssnittskontroller som använder underliggande gränssnitts-API för vardera
plattform och på så vis erbjuder utvecklaren möjlighet att skriva ett gränssnitt som kan
användas på alla tre plattformar, och som, om man vill, kan anpassas via villkor för de
enskilda plattformarna. Rapporten går in mer i detalj på vad Xamarin och Xamarin.Forms
i avsnitt 2.2.2.
Xamarin.Forms innehåller de flesta gränssnittselement, däribland kartor [Incy]. I båda
alternativen är själva införandet av kartor i appen simpelt, man lägger till elementen via
XAML eller i koden.
Funktionaliteten i kartorna ska sedan utökas med möjligheten att sätta ut punkter,
vilket även detta är enkelt med båda alternativen då båda erbjuder metoder för att sätta
ut punkter på givna koordinater. Punkterna bör representera olika kategorier, till exempel
för uthyrningsplatser, rutter eller rastplatser där kategorin både anges av en unik färg samt
är tydlig i namnet som sätts på punkten.
Nästa utmaning är att rita linjer på kartan för att representera rutter. Det här saknas
stöd för i Xamarin.Forms version av kartan [Incv], men det bör ändå gå att hitta någon
form av lösning då Xamarin erbjuder specialanpassning av kontroller [Incj]. Alternativt kan
man utnyttja användandet av plattformsspecifika villkor för att nyttja funktionaliteten i
Google’s kart-API för att rita linjer.
7
2.2.5 Databas för kartpunkter
Appen kommer ha behov av att lagra en del data, bland annat i form av information om
platser, såsom koordinater, beskrivningar och namn. Då appen bör ha utrymme att växa,
dvs att antalet platser som ska lagras ska kunna bli ganska många, bör metoden att lagra
datan vara lämpad för stora mängder. Det finns ett par alternativ, Extensible Markup
Language (XML) och Structured Query Language (SQL) [Incr], för att lagra denna typ av
data som båda skulle lämpa sig, med vissa nackdelar för vardera implementation.
2.2.6 XML-databas
XML är ett markup-language, likt HTML, som används för att strukturera upp informa-
tion och samtidigt ge en indikation om vilken roll specifik information innehar [Wal]. Man
kan alltså spara information och märka upp den med till exempel kategorier. Det fungerar
utmärkt att spara information i XML-formatet och använda dokumentet som en databas,
men det kan bli lite osmidigt att hantera stora mängder information när den ska manipu-
leras, då XML främst är anpassat för att flytta data mellan andra typer av databaser eller
från en mjukvara till en databas [Har03].
2.2.7 SQL-databas
En SQL-databas är både enkelt, man slipper serialiseringen till XML, och effektivt, stora
mängder data går snabbt att söka igenom i en databas [SQL]. Xamarin själva rekommen-
derar att man använder SQLite.net för att hantera data [Incu]. SQLite.net finns att ladda
hem till projekt via NuGet, Visual Studio:s pakethanterare, och kan sedan användas för
att skapa databaser och utföra enkla frågor med hjälp av kod som den fil man laddar
hem tillhandahåller. Man kan med hälp av denna kod spara objekt som man definierat i
sitt projekt, så länge objekten har definierat vilka egenskaper som ska fungera som attri-
but och en primärnyckel. Dock är funktionaliteten förhållandevis låg, man kan exempelvis
inte använda sig av främmandenycklar för att länka objekt i olika databastabeller mot
8
varandra, något som skulle vara bra att kunna. Det finns ett tillägg till SQLite.net som
går att använda för att åstadkomma detta [Aut], och det finns dessutom en Query-metod
[Aut] i SQLite-filen som ger en möjlighet att skriva databasfrågor via C# mot databasen.
SQLite.net verkar således vara den smidigaste vägen att gå för att hantera appens data.
2.2.8 Användare, rättigheter och informationsinsamlande
En av de icke tekniska utmaningarna är hur man bör fylla appen med relevant information.
Den inledande tanken var att användare skulle kunna ladda upp platser de tror kan vara
av intresse för andra, samt betygsätta platser för att förenkla för andra användare. På
så sätt skulle appen kunna byggas av användarna, likt ett community, och från att den
publicerats mer eller mindre sköta sig själv. Efter samtal med kajak-kunniga på bland annat
kajakuthyrningar [Zet] framkom dock vissa risker med denna metod. Den främsta av dessa
risker är att vissa platser kan vara rentav farliga att paddla på under fel förutsättningar,
såsom vind eller vattenstånd, något som kanske undgår “vanliga” användare.
En metod som skulle undanröja en sådan risk vore att man ger vissa användare särskilt
tillstånd att ladda upp platser till databasen. Dessa användare skulle isåfall behöva utses
av någon, och skulle företrädesvis vara personer som jobbade med uthyrning av utrustning
eller höll kurser i paddling.
Ett tredje tillvägagångssätt, som också är det som implementerats, vore att utvecklaren
samlar så mycket befintlig information som möjligt och manuellt fyller upp databasen med
det som finns. Detta skulle dock innebära en väldigt begränsad databas om inte utvecklaren
flitigt uppdaterar den med ny data även efter projektets slut.
Ett webgränssnitt som har tillgång till databasen och via vilken man kan tillföra data
vore ett naturligt steg för samtliga alternativ. Ett krav är också att databasen är central
och kan uppdateras för alla användare.
9
2.3 Kapitelsammanfattning
Utvecklingen av appen kräver lösningar på ett flertal problem som generellt har presenterats
i kapitlet. För att över huvud taget kunna använda Xamarin behövs en licens samt antingen
att man installerar Xamarin Studio eller har en installation av Visual Studio att använda
tillsammans med Xamarin. Projektet skapas sedan för flera plattformar, med underliggande
projekt specifika för Android och Windows Phone.
Xamarin.Forms är Xamarins API för att tillåta göra gränssnittskod plattformsobero-
ende och har använts i projektet. Forms kan designas i både C# och XAML och passar
därför MVVM-designmönstret efter vilket appen designats. MVVM strukturerar klasserna
i appen efter funktion för att skilja gränssnitt från bakomliggande kod.
En fungerande karta med bakomliggande databas är en viktig del för appen. För att
kartan ska ha någonting att visa krävs data om platser och leder. En SQLite.NET-databas
används med fördel, något som också rekommenderas av Xamarin. Kartan behöver mycket
funktionalitet för att vara användbar men Xamarin.Forms version av kartan har bara stöd
för mycket enkel funktionalitet. Kartan behöver därför utökas med det som saknas.
10
3 Projektdesign
Appen, som fått projektnamnet PaddelAppen, är en app som låter användaren via en karta
hitta platser som är av intresse då man vill ut och paddla. Det kan vara uthyrningsplatser,
paddlingsleder eller rastplatser. Appen låter dessutom användaren ta reda på vilka av
dessa platser som finns i närheten samt betygsätta alla platser för att underlätta för andra
användare. Dessutom finns möjlighet för vissa användare att lägga upp och dela med sig
av platser de tycker kan vara bra för andra att veta om.
3.1 Design
Appen skrivs i C# enligt MVVM-designmönstret, och utvecklas parallellt till Android och
Windows Phone. Att utveckla i C# för Android är möjligt tack vare Xamarin.Android,
Windows Phone appar skrivs ursprungligen i C#. Appen består av tre delprojekt, ett
som håller den kod som delas mellan plattformarna ett projekt för vardera plattform som
egentligen bara innehåller det som krävs för att starta appen på den specifika plattformen.
Den grundläggande designen innebär alltså att tre projekt utgör appens källkod, men
bara två av dessa projekt kommer att kompileras till den slutliga appen. Ett av projekten
innehåller all den delade kod som både Android-versionen och Windows Phone-versionen
av appen kommer att använda sig av. De andra två projekten är plattformsspecifika och
innehåller var för sig endast kod som kommer att användas till Android respektive Windows
Phone.
I det delade projektet finns nära på all backend-kod, det som i MVVM kallas model, och
dessutom en hel del gränssnittskod. Det är här appen accessar databaser, hanterar använ-
darinput, och utför all logik. I de plattformsspecifika projekten finns den kod som behövs
för att starta upp appar på respektive plattformar och dessutom en del gränssnittskod
samt viss kod som behövs för att anpassa eller utöka den delade koden, exempelvis kart-
vyer. Även den klass som hanterar databasen med SQLite behöver initieras från dessa två
11
projekt separat, även om den i sig existerar i den delade koden.
Att appen designas i enlighet med MVVM-designmönstret innebär rent praktiskt att
de flesta klasser som skrivs delas in i Views, Models och ViewModels för att kunna skilja
på varje klass uppgift. Dessa delas in i egna mappar samt har en viss namnstandard för
att man enkelt ska se i vilken nivå man är och jobbar. Tack vare detta kan man jobba i
gränssnittet helt separat, utan att påverka hur någon av de andra delarna fungerar, och vice
versa. I figur 3.1 ses en översikt över projektet enligt MVVM. Här syns de tre klasstyperna
och vilket jobb det är tänkt att de olika typerna ska utföra. Dessutom syns hur mycket av
koden som kan delas mellan plattformar och vad som behöver anpassas specifikt.
Eftersom Xamarin.Forms finns tillgängligt och erbjuder utveckling av gränssnitt i XAML,
vilket är vad MVVM avsetts för [Incl], används det för att göra appens gränssnitt. XAML
är ett markup-språk, precis som HTML, och låter utvecklaren bygga gränssnitt på ungefär
samma vis som man bygger websidor med HTML. Detta innebär att för varje sida som
gränssnittet består av kommer en XAML-page att finnas i Views-mappen, med en under-
liggande C#-klass som binder sidan mot en underliggande ViewModel, så att man i sin
tur i XAML-koden kan binda till alla nödvändiga egenskaper.
Xamarin.Forms erbjuder egna varianter av kontroller, såsom knappar, menyer eller text-
fält, för de flesta kontroller som finns för respektive plattform, så alla sidor bör gå att skriva
med Xamarin.Forms som bas. Däremot är vissa kontroller något fattiga på funktionalitet,
i synnerhet kartorna, som därför behöver utökas med hjälp av lite specialanpassning.
3.2 Detaljer
Appen består som ovant nämnt av tre olika typer av klasser, nämligen Views, i fortsätt-
ningen hänvisade till som vyer, ViewModels, vymodeller, samt Models eller modeller. I
designfasen är det viktigt att se till att rätt filer får rätt tillhörighet, det vill säga att alla
de filer som har med datahantering eller logik att göra hamnar bland övriga modellerna,
att filer som bygger upp användargränssnittet hamnar bland vyerna samt att länkarna
12
Figur 3.1: Översikt av projektet enlig MVVM
13
däremellan är vymodeller.
3.2.1 Views
PaddelAppen använder sig till stor del av kartor och listor, så det är det första som tas med
i designen. Både listor och kartor behöver en snygg representation i användargränssnittet,
och dessutom bakomliggande logik som låter användaren navigera både i kartvy och listvy
för att enkelt kunna hitta det den vill komma åt. Både kartvy och listvy designas för att ta
upp hela skärmen, då översikt är viktigt för dessa två kontroller. Användaren ska dessutom
kunna klicka på punkter på kartan eller poster i listan för att få upp info om den platsen.
Både listvyn och kartvyn ska kunna visa olika typer av punkter, för att tydliggöra för
användaren om en punkt är led, uthyrning eller något annat. Detta ska vara någorlunda
enkelt att fixa i listvyn, men är någonting som behöver ganska mycket jobb i kartvyn,
då kontrollen för kartor i Xamarin.Forms inte stöder någonting annat än att helt enkelt
rita ut kartan och sedan sätta ut vanliga kartnålar på koordinater efter instruktioner från
sin vymodell. Det som krävs för att anpassa kartan efter sina behov är att man skapar
vad som kallas för en Custom Renderer. Detta är en klass som måste finnas i båda de
plattformsspecifika projekten och som används som ett lager mellan Androids eller Win-
dows Phones kart-API och Xamarin.Forms kartor. Custom Renderer:n används sedan för
att lägga till funktionalitet som finns i Androids och Windows Phones kartor men som
saknas i Xamarin.Forms kartor. Dessutom behöver en klass skapas i den delade koden som
ärver Xamarin.Forms.Maps och som har metoder för att hantera den funktionalitet som
Custom Renderer-klassen tillhandahåller. Det är också denna klass som används för att
skapa kartor i appen, istället för ursprungliga Xamarin.Forms.Maps. En enkel illustration
finns i figur 3.1, där de blå fälten visar Androids respektive Windows kart-API med den
överliggande Custom Renderer-klassen som skickar funktionalitet ett steg upp. Det gröna
fältet är den specialanpassade klass som ärver Xamarins karta och som sedan används för
att skapa nya, anpassade kartobjekt.
14
Med hjälp av dessa två nya klasser kan man sedan få kartan i sitt Xamarin.Forms-
baserade användargränssnitt att klara av allt som den underliggande kartan i Android eller
Windows Phone klarar av. I PaddelAppens fall rör det sig alltså om att kunna anpassa
punkterna som sätts ut på kartan (byta utseende) och göra dem klickbara. Dessutom läggs
stöd in i Custom Renderer:n för att rita ut linjer mellan koordinater på kartan, eftersom
Xamarin.Forms kartan inte klarar detta heller, eftersom detta behövs för att visa rutter
på ett bra sätt.
Övriga delar i användargränssnittet rör mest olika typer av navigation. Användaren ska
ju på ett enkelt sätt kunna ta sig fram till alla sidor appen består av. Det smidigaste sättet
att göra detta är att använda sig av navigationsstacken, som finns på smarta telefoner. Man
får då automatiskt tillgång till exempelvis en bakåtknapp, som bara tar bort den översta
sidan ur navigationsstacken och visar föregående. För att åstadkomma en sådan lägger man
helt enkelt in den första sidan man vill visa som en NavigationPage, och alla sidor man se-
dan öppnar via denna eller vidare hamnar på navigationsstacken och det fungerar utmärkt
att använda telefonens bakåtknapp för att navigera tillbaka i användargränssnittet. I figur
3.2 syns den sida som läggs in från början i navigationsstacken, navigationssidan, via vilken
man navigerar till resterande sidor. Här syns knappar man kan använda för att ta sig till
sidor som visar alla platser på en lista eller en karta, och sedan därifrån ta sig vidare till en
detaljsida som visar en mindre karta samt en beskrivning av den plats man valt. Figur 3.3
visar listsidan och kartsidan. Listsidan har en lista som största element, längst upp finns
också knappar för filtrering och en titel. Kartsidan visar enbart kartan och på kartan syns
alla punkter inom det område som visas. Detaljsidan visas i figur 3.4 och här finns övrig
info som kan vara bra att veta, tex om det finns rastplatser med möjlighet att sätta upp
tält eller elda, samt hur lång rutten är om det är en sådan man klickat sig till.
15
Figur 3.2: Navigationssida
Figur 3.3: Listsida och navigationssida
16
Figur 3.4: Nära vy av detaljsidan
17
3.2.2 ViewModels
Även om vyerna inte behöver någon vymodell för att fungera, så behöver ju varje vy någon
typ av logik bakom sig eller någon data att visa för att vara funktionella, i form av en
vymodell.
Vymodellen för navigationssidan behöver bara metoder för att skicka vidare användaren
till olika sidor. Detta kan göras genom att den sida som ska öppnas läggs på navigations-
stacken och på så sätt visas i appen och dessutom låter användaren backa med telefonens
bakåtknapp.
Kartvyn behöver en vymodell som hjälper till med att sätta ut alla platser som ska
visas på kartan, samt dra ruttlinjer. Vymodellen till kartvyn bör alltså ha koll på vilka
platser som ska sättas ut och vilka koordinater dessa har ska kunna passas till kartvyn.
Eftersom vymodellen också är kopplingen till modellerna ska den också hämta data den
behöver därifrån, i detta fall ur databasen som innehåller alla platser som ska ut på kartan.
Vymodellen bör dessutom kunna navigera till en detaljsida som hör till platsen som väljs
i kartvyn.
Listvyn behöver, likt kartvyn, en vymodell som har koll på alla platser. Dessa ska dock
i detta fall förstås laddas in i en lista som kan representeras i listvyn. I övrigt behöver
listvyn logik som på olika sätt kan sortera listan och filtrera resultaten i listan. Det behövs
metoder för att sortera efter tex bokstavsordning, längd på rutter, närhet till rutter (i detta
fall finns även specialfallet med sidan för närliggande rutter, och om metoden existerar här
kanske samma logik och lista kan användas) eller betyg. Även här behövs en metod för
att navigera vidare till nästa sida, för vald plats. Därtill behövs metoder för att hämta
data från modellerna, närmare bestämt det samma som i kartvyns vymodell, platsdata ur
databasen.
Detaljsidan behöver ganska mycket logik bakom sig för att vara funktionell. Bland annat
visas här en karta som visar var platsen ligger eller hur rutten är dragen, vymodellen
behöver således bidra med platsdata i form av koordinater. Därtill ska en beskrivning
18
hämtas ur databasen och göras tillgänglig för vyn och på samma sätt ska betyg, längd på
rutt och övrig info som lagrats i databasen göras tillgänglig för vyn. Här behöver vymodellen
dessutom tillhandahålla olika typer av ikoner för att göra informationen översiktlig för vyn.
3.2.3 Models
Till modellerna hör all logik som hanterar data samt hanterar databasen. Dessutom är alla
klasser som behövs för att skapa de objekt som representerar platser i koden modeller.
Dessa klasser behöver definiera vad som är attribut och primärnyckel, det behövs när de
objekt som skapas av klassen ska lagras i databasen.
Klassen som hanterar databasaccess är också en modell, och använder sig av SQLite.net-
klassen som finns att ladda hem i NuGet, den pakethanterare som finns i Visual Studio.
Denna klass ska tillhandahålla logik för att spara, plocka fram och ta bort data i en eller
flera databaser.
3.2.4 Controllers och Custom Renderers
Appen behöver utöka funktionaliteten hos Xamarin.Forms kartor och därför skapas en
kartklass som ärver Xamarins kartor samt utökar funktionaliteten med hjälp av en Custom
Renderer i de plattformsspecifika projekten. Här läggs funktionalitet in för att göra kart-
nålarna mer interaktiva samt för att kunna rita på kartan, linjer mellan olika koordinater.
I Custom Renderer:n görs den funktionalitet som finns i Androids och Windows Phones
kartor tillgänglig för den utökade kartklassen, så att dessa låses upp för användning.
3.3 Kapitelsammanfattning
Appen skrivs i C# enligt MVVM-designmönstret. Klasser delas därför upp i tre typer; vyer,
vymodeller och modeller där man skiljer grässnittskod från bakomliggande kod. Ytterligare
en distinktion ges genom att gränssnittet skrivs i XAML.
19
Vyerna består av en meny samt en karta och en lista. Menyn och listan går att ko-
da enligt kravspecifikationen genom att bara använda XAML och rätt logik i respektive
vymodell, medan kartan behöver specialanpassas. Till detta används en anpassningsklass,
Custom Renderer, för att bidra med den funktionalitet som saknas i kartan. Vyerna pre-
senteras dessutom genom grafiska skisser för att ge en idé om designen.
Vymodellerna är de klasser som binder ihop logiken, modellerna, med vyerna, så att
dessa har någonting att visa i gränssnittet. Vymodellen för menyn är den klass som bidrar
med metoder, dvs den klass som vet vad som ska hända när en knapp i menyn används.
Vymodellen för kartvyn hämtar data om platser från databasen och sätter ut dessa platser
på kartan så att de syns i vyn, precis som vymodellen för listvyn fyller listan med data att
visas i listvyn.
Modellerna håller all logik och hanterar databasanrop. Även klassen som representerar
platser är en modell.
Utöver de tre klasstyperna som finns i MVVM behövs också ett antal klasser för spe-
cialanpassning, av exempelvis kartan.
20
4 Implementation
4.1 Detaljer
4.1.1 View
BrowsePage
Sidan, som illustreras i figur 3.2, visar fyra knappar intill varandra, mitt på sidan,
två i en övre rad samt två i en undre rad. Detta åstadkoms i XAML-koden genom
att en Stacklayout skapas och som sedan innehåller ett Grid, med två rader och
två kolumner. När knapparna skapas placeras de samtidigt ut i Grid:et, och önskat
utseende uppnås.
MapPage
Denna sida visar endast en karta i grundutförande och syns i figur 3.3, och tillhörande
vymodell sköter tilläggning av ytterligare element, såsom kartnålar. Kartan i sig
läggs även den in via vymodellen, och det enda som existerar i XAML:en är en
Stacklayout i vilken kartan kan placeras. Stacklaouyten förses med ett namn och den
bakomliggande vymodellen kan sedan lägga till kartan genom en enkel add-metod på
Stacklayouten.
ListPage
ListPage visar en lista, som skapas inuti en Stacklayout i XAML-koden. Det är bara
listan som skapas och den fylls sedan av sedan av PointCells-objekt, som beskrivs
nedan, i sin vymodell. Som synes i figur 3.3 finns här också en del knappar längst
upp på sidan som är till för att filtrera resultaten som visas i listan.
PointCell
PointCell består av två labels placerade bredvid varandra i en Stacklayout. Det är
denna sida som utgör varje cell som läggs till i ListPage, på så sätt kan man skilja
listcellerna från själva listan och designa den som en egen sida. Varje label i PointCell
21
binder mot en egenskap, Name respektive Notes, som hör till det som cellen i sin tur
ska fyllas med, en plats.
DetailsPage
DetailsPage i figur 3.4 är till för att hålla utförlig information om en plats har en del
olika gränssnittselement. Det första är en karta som läggs in i XAML-koden, förutom
den omkringliggande Stacklayouten. Under kartan placeras sedan ett antal ikoner som
även dessa kan läggas in via XAML-kod. Dessa ikoner är egentligen typsnitt, och kan
läggas in som text. Ikoner finns för att visa att platsen har tex en eldplats, tältplats,
uthyrning eller andra intressanta saker. Dessutom finns en ikon för att öppna bilder
från platsen samt fem runda små ikoner för att visa vilket betyg rutten har fått av
andra användare. Därefter följer en TableView med en TableSection som i sin tur
håller två TextCells, där dels platsens beskrivning länkas in, och dels kommentarer
eller övrig info länkas in.
4.1.2 ViewModel
BrowsePageViewModel
BrowsePageViewModel står för logiken bakom vyn BrowsePage. Den har ett antal
Command objekt som de knappar som finns i BrowsePage kan binda till. Varje Com-
mand sätts sedan via metoder till en Task som asynkront öppnar en ny sida. Mer än
så behövs inte göras i den här klassen då detta ger den navigation som behövs. Genom
att navigationen sker via ett Navigation-objekt läggs nya sidor på navigationsstacken
som gör det enkelt att backa till föregående sida.
MapPageViewModel
MapPageViewModel är klassen bakom kartsidan MapPage och skapar ett objekt av
den specialanpassade kartklassen CustomMap utifrån den position som hämtats från
telefonens GPS. Därefter skapas ett antal menyknappar för filtrering. Varje knapp
22
använder sig av kartans AddPoints-metod för att visa endast en specifik typ av punkt
på kartan, alltså filtrera bort alla typer av punkter utom en, genom att ange en
viss typ som parameter. De olika knapparna kan filtrera fram punkter av typerna
rutt, lägerplats, uthyrning och återställa så att alla punkter visas. Därefter läggs alla
knappar in i navigationsmenyn och kartan läggs till i den LayoutStack som skapats
i MapPage-klassen avsedd för just kartan.
ListPageViewModel
ListPageViewModel liknar MapPageViewModel i det att den lägger till samma me-
nyknappar, men istället för en karta skapas en lista. Listans ItemTemplate och
ItemTemplate-binding sätts och därefter även listans ItemSource. Till ItemSource
sätts den lista man får från databasens GetPoI-metod. Här skapas även ett Command-
objekt som ett klick på ett objekt i listan som syns i ListPage kan binda till. Detta
kommando sätts till en Task som asynkront navigerar till detaljsidan för avsedd
punkt.
DetailsPageViewModel
DetailsPageViewModel har ett antal olika strängar. Dessa är till för att alla textfält
i DetailsPage ska ha något att binda till och returnerar helt enkelt ett strängvärde
från den punkt som är representerad på sidan. Därtill läggs en mindre karta till i
den MapStack som skapats i DetailsPage. Denna karta skapas i en egen metod med
center i den punkt sidan ska representera och som dessutom krympts till ett passande
format.
4.1.3 Model
PointOfInterest
PointOfInterest är klassen som representerar en punkt på kartan. Klassen håller infor-
mation om allting som användaren behöver veta om en plats samt allting själva appen
23
behöver veta för att representera platsen på kartan i form av en punkt. Egenskaperna
är således ganska många, det finns ett namn och en beskrivning samt koordinater.
Därtill finns ytterligare information som hur lång sträckan är ifall det rör som en rutt,
samt vilken användarpoäng platsen har tilldelats. Till sist finns det en typangivelse
som talar om vilken typ av plats det rör sig om, uthyrning, rutt eller övernattnings-
plats och dessutom en sträng som håller alla koordinater som behövs för att sätta
ihop en sträcka på kartan ifall platsen är av typen rutt.
Anledningen till att den här klassen håller koordinater som enskilda double-värden
för latitud respektive longitud istället för ett Location-objekt (som beskrivs nedan)
är att databasen inte klarar att lagra objekt som i sig håller objekt av en klass, utan
endast klarar av rena värden som tal och strängar. Detta är också anledningen till
att rutten lagras som sträng och inte tex en lista med Location-objekt - det går inte
att lagra en lista, som ju är ett objekt av klassen List, i databasen.
Objekt av den här klassen kommer att finnas lagrade i databasen och klassen har
därför implementerat SQLite’s Attribut-bibliotek, så att klassens egenskaper kan ses
som speciella attribut (såsom primärnyckel) i databasen genom att man lägger till
taggar innan man deklarerar egenskaperna. Detta görs enkelt genom att man på
raden ovan egenskaperna lägger in exempelvis [PrimaryKey, AutoIncrement], vilket
gör att egenskapen under ses som primärnyckelattributet i databasen, och dessutom
automatiskt tilldelas ett nummer högre än det objekt som lades till innan, så att man
slipper sätta primärnyckeln själv.
Location
Location är en klass som enbart håller två koordinater och används för att hålla
reda på var platser finns på kartan. Klassen används på en hel del platser i appen,
bland annat i MapExtensions för att göra om strängen som representerar en rutt i
PointOfInterest-klassen (som beskrivits ovan) till en lista med Location-objekt för
24
att läggas ut på kartan.
4.1.4 Extensions
MapExtensions
Den här klassen är en modifierad version av klassen MapExtensions, skriven av Ro-
bert Ecthen i projektet BindableMapTest [Ech].
Den här klassen håller en mängd metoder som används i olika delar i appen för att
utöka eller förbättra funktionalitet. Det är en statisk klass, just för att olika andra
klasser i appen ska kunna använda sig av metoderna i den. Dessutom finns här en
typdeklarering i form av en enum som kallas LocationType, där rutt, uthyrning samt
tält-/eldplats representeras och därför kan utnyttjas av hela appen när kontroll av
typ behöver göras.
De olika metoderna är dels en metod som används för att representera ett objekt
av appens specialanpassade kartnål (CustomPin) som en kartnål (Pin) som går att
placera ut på en Xamarin.Forms.Maps-karta. Detta är nödvändigt helt enkelt för att
man på en Xamarin.Forms.Maps-karta inte kan placera ut något annat än just objekt
av klassen Pin, och eftersom CustomPin är en egen klass som är en utökad version av
just Pin, måste man gå tillbaka till Pin innan man placerar ut punkterna på kartan.
Därtill finns två metoder för att hantera rutter och dess omvandling mellan sträng och
lista som beskrivits i avsnitten om PointOfInterest och Location ovan. Som bekant
kan PointOfInterest endast hålla rena värden, därför hålls en rutt som en sträng av
koordinater, medan på alla andra ställen i appkoden en rutt representeras som en lista
av Location-objekt. De två nämnda metoderna behövs alltså för att översätta från det
normala formatet i from av en lista till en sträng att lagra i databasen, och vice versa.
För att omvandla från lista till sträng används en metod kallad MakeTrailString som
tar en lista (ObservableCollection) med Location-objekt som parameter och sedan,
för varje objekt i listan plockar ut latitud och longitud och sparar i en sträng med
25
ett specialtecken som skiljetecken däremellan, och fortsätter så för varje objekt tills
listan är slut. Varje objekt skiljs i sin tur åt i strängen med ett annat skiljetecken.
Det hela sparas i en resultatsträng efterhand och returneras. För att vända på det
används metoden MakeTrailPoints, som returnerar en lista efter att ha fått en sträng
som parameter. Metoden delar först på strängen efter det skiljetecken som användes
för att skilja Location-objekten åt och lägger dessa in en sträng-array, varpå varje
sträng i denna sträng-array delas efter det skiljetecken som lades in mellan latitud och
longitud och dessa parsas sedan till double-värden och sparas i ett Location-objekt
som i sin tur sparas i en resultatlista, vilken sedan returneras.
4.1.5 Services
Alla klasser under den här kategorin är modifierade versioner av den kod [Bur] Amy Burns
skrivit som exempelkod för Xamarins webbplats enligt den guide [Incd] som behandlar
Backgrounding. Klasserna jobbar tillsammans för att i bakgrunden prenumerera på upp-
dateringar från enhetens GPS så att appen vet på vilka koordinater den befinner sig.
LocationProvider
LocationProvider hanterar objekt av övriga klasser och ett objekt av LocationPro-
vider används i Android-projektets MainActivity-klass för att uppdatera informa-
tion om GPS-koordinaterna i enheten i bakgrunden, genom att köra uppdatering-
en på en egen tråd. I LocationProvider finns ett privat LocationServiceConnection-
objekt och ett publikt LocationService-objekt, dock endast med get-funktion, samt
en EventHandler, LocationServiceConnected. Sedan körs på en bakgrundstråd genom
en Task. I den här Task:en sätts LocationServiceConnection-objektet för att man
ska kunna binda till Servicen då LocationServiceConnection innehåller ett Binder-
objekt. LocationServiceConnection innehåller även en EventHandler kallad Service-
Connected som också den sätts här till den EventHandler som finns i Location-
Provider, LocationServiceConnected. Detta för att MainActivity-klassen ska få ve-
26
ta när det är dags att börja uppdatera. Dessa EventHandlers kommer triggas av
OnServiceConnected-metoden i LocationServiceConnection. Till sist binds servicen
med LocationServiceConnection-objektet samt en Intent som skapas strax innan och
Task:en startas.
LocationServiceConnection
Som nämnt ovan har LocationServiceConnection en EventHandler, ServiceConnec-
ted, som triggas av OnServiceConnected-metoden för att det då är dags att börja
uppdatera data från enhetens GPS samt ett objekt av LocationServiceBinder-klassen.
OnServiceConnected-metoden anropas när klienten försöker binda till servicen varpå
systemet letar reda på den bindern som hör till den service som körs. Denna bin-
der castas sedan som en LocationServiceBinder och sätts till LocationServiceBinder-
objektet. När detta är gjort triggas ServiceConnected-eventet som låter MainActivity-
klassen veta att den nu kan börja uppdatera. Därefter anropas en metod i LocationServiceBinder-
objektets LocationService-objekt, nämligen StartLocationUpdates, för att börja sam-
la in data från GPS:en.
LocationServiceBinder
LocationServiceBinder har ett objekt, ett av typen LocationService, via vilken StartLocationUpdates-
metoden nås. Det viktiga i den här klassen är att den ärver Binder och således är en
Binder-subklass.
LocationService
LocationService har ett antal EventHandlers, för att få uppdateringar angående posi-
tion eller när GPS:en sätts på eller stängs av. Den har dessutom ett LocationManager-
objekt som sätts till Androids positionsservice. Här finns sedan den metod som fak-
tiskt anropar Android-systemets positionsservice för att få positionsuppdateringar.
Den här metoden heter StartLocationUpdates och börjar med att sätta vissa kriteri-
er, som hur noggranna uppdateringarna ska vara. Därefter hämtas det system (GPS
27
eller nätverk) som ska leverera uppdateringarna och därifrån begärs sedan en posi-
tionsuppdatering. LocationService prenumererar sedan på uppdateringar och får en
uppdatering varje gång en ny position upptäcks vilka sedan delegeras via EventHand-
lers till MainActivity som har en metod, HandleLocationChanged, för att göra det
som behövs när den får en positonsuppdatering.
4.1.6 Custom Controls
CutomMap
Den här klassen är en modifierad version av klassen ExtendedMap, skriven av Robert
Ecthen i projektet BindableMapTest [Ech].
CustomMap ärver och är en utbyggnad av Xamarin.Forms.Maps, och är till för att
lägga till funktionalitet som existerar i Googles kartor men som saknas i Xamarins.
För detta behövs, förutom denna klass, dessutom en så kallad Custom Renderer-klass
som beskrivs längre fram. Man kan säga att den här klassen är ett mellanlager mel-
lan Custom Renderer-klassen som skickar upp funktionalitet från Googles karta och
Xamarin.Forms karta som ska utnyttja funktionerna. Först och främst håller kartan
listor med objekt av typerna Location, respektive CustomPin, som är appens egen
version av Pin, Xamarin.Forms.Maps kartnålar (som också beskrivs nedan).
Listan med objekt av typen Location kommer att användas av den tillhörande Custom
Renderer-klassen där funktionalitet för att rita på kartan finns, så att rutter (som är
vad listan representerar) kan ritas ut på kartan med hjälp av Google Maps PolyLines
[Inca].
Ytterligare funktionalitet som det läggs till stöd för är att det på kartan går att klicka
på en kartnål och på så sätt välja den samt att det då visas en inforuta tillhörande den
valda kartnålen. Informationsrutan kan även den klickas på för att ta användaren till
den sida som tillhör den valda platsen. Detta görs genom att det i denna klass finns
en BindableProperty (som tillåter data bindning från Custom Renderer-klassen) för
28
den kartnål som användaren klickar på. Den valda kartnålen håller ett id som skickas
till den metod i CustomMap-klassen som sedan hämtar den plats med samma id i
databasen och lägger tillhörande sida på navigationsstacken.
Dessutom finns här metoder för att lägga till de kartnålar som är anpassade efter
appens ändamål, CustomPin. Det finns metoder för att lägga till alla platser i data-
basen som kartnålar, lägga till alla platser som uppfyller ett villkor om typ, samt en
enskild plats efter ID. Detta görs genom att alla önskvärda platser i databasen läggs
till som objekt av typen CustomPin i en lista, och alla objekt i denna lista läggs
sedan till Xamarin.Forms.Maps egen lista med Pins (sin egen klass för kartnålar)
med hjälp av en metod i CustomPin som översätter mellan just CustomPin och den
vanliga Pin.
En enkel beskrivning av CustomMap och hur den förhåller sig till övriga klasser finns
i figur 4.1.
CustomPin
Den här klassen är en modifierad version av klassen ExtendedPin, skriven av Robert
Ecthen i projektet BindableMapTest [Ech].
CutomPin-klassen är en utbyggnad, likt CustomMap, av Xamarin.Froms.Maps egna
Pin-klass. Den har fler egenskaper, för att kunna hålla bland annat all information
som finns i objekt av typen PointOfInterest, vilken CustomPin är avsedd att repre-
sentera på en karta. Dessutom finns en metod för att hämta ut en rutt med hjälp av
metoder ur MapExtensions-klassen. CustomPin används (även här, likt CustomMap)
av CustomMapRenderer som ett led i utökandet av funktionalitet för kartan, här i
form av anpassade kartnålar. CustomPin finns med två konstruktorer, en för att ange
all info i form av parametrar samt en för att helt enkelt bara skicka in ett objekt av
PointOfInterest och göra den till en kartnål.
29
4.1.7 Custom Renderers
CustomMapRenderer - Android
Den här klassen är en modifierad version av klassen ExtendedMapRenderer, skriven
av Robert Ecthen i projektet BindableMapTest [Ech].
CustomMapRenderer är den klass som har allra mest att göra med utökning av kart-
funktionaliteten. Den här klassen finns i Android-delen av projektet och lyfter fram
olika funktioner som finns i den för Android ursprungliga Google-kartan. Med hjälp
av den här klassen blir sådan funktionalitet som inte existerar i Xamarin.Forms.Maps,
ändå tillgänglig i den klass som beskrivits ovan, CustomMap, genom att denna är-
ven just Xamarin.Forms.Maps och samtidigt drar nytta av den funktionalitet som
CustomMapRenderer lyfter fram.
I den här klassen finns en mängd metoder för att lyfta fram all relevant funktionali-
tet. Det första som görs är att två EventHandlers, händelser som sker när någonting
ändras, tilldelas. Dels en för den händelse som triggas när användaren trycker på
ett informationsfönster (det fönster som poppar upp när man trycker på en kartnål)
och dels en för den händelse som triggas när samlingen av kartnålar på något sätt
förändras. Dessa två EventHandlers tilldelas metoder, i det ena fallet, där ett klick
på informationsfönstret triggar en händelse, anropar metoden helt enkelt motsvaran-
de metod i CustomMap-klassen som skickar användaren till en ny sida. Den andra
händelsen, där en förändring i samlingen kartnålar är vad som triggar, tilldelas en
metod som endast anropar metoden UpdatePins. UpdatePins har till uppgift att rita
ut alla kartnålar på kartan genom att lägga till en Marker, som kartnålarna kallas i
Android.
Innan detta görs så rensas kartan via dess Clear-metod, eftersom detta behöver göras
för att man varje gång metoden körs inte ska få en ny uppsättning markörer på de
gamla. Därefter läggs en EventHandler till för att reagera på när användaren klickar
30
på en markör. Att detta görs här, och inte tidigare, beror på att, eftersom kartan
rensas varje gång denna metod körs, existerar inte händelsen därefter, och måste
läggas till på nytt. Metoden fortsätter sedan med att hämta listan med CustomPin-
objekt från sitt CustomMap-objekt (vilket beskrivs i avsnittet om CustomMap ovan)
och lägger för CustomPin i listan till en ny markör enligt Google-kartans regler.
Metoden avslutar med att sätta en ikon på markören som är anpassad efter typ
genom att anropa metoden GetPinIcon och skicka typen som finns i CutomPin-
objektet (rutt, uthyrning eller rastplats) som parameter samt lägga till markören i
med hjälp av Android-kartans AddMarker-metod. I samband med detta sista steg
mappas dessutom markörens id (som är i form av sträng) mot CustomPin-objektets
id (som är detsamma som platsen den representerar som finns lagrat i databasen)
med hjälp av ett Dictionary. Detta görs för att det annars inte finns något sätt att
förknippa Google-kartans markörer med appens CustomPins- och PointOfInterest-
objekt, då Google-markörens id inte går att sätta utan sätts automatiskt till en
genererad sträng.
GetPinIcon-metoden som används i UpdatePins tar, som bekant, en typ som para-
meter och avgör med hjälp av den vilken ikon som ska returneras. Ikonerna har lagts
in under Androids Resurs-mapp och returneras rakt av.
Den andra metoden som används i UpdatePins, HandleMarkerClick, tar den mar-
kör som triggat händelsen som parameter och öppnar det infofönster som hör till
denna markör. Dessutom sätts CustomMap-objektets SelectedPin till en Custom-
Pin som får alla egenskaper av den markör som triggat eventet, detta för att även
CustomMap-objektet ska veta vad som klickats på. Det sista som görs här är att me-
toden AddPolyLines anropas, med markör-objektets id som parameter. Denna metod
ritar ut en rutt, ifall en sådan existerar, och behöver således ett id för att leta efter
rätt rutt.
I lite mer detalj så jobbar AddPolyLines-metoden mot en lista av PolyLine-objekt.
31
Figur 4.1: Översikt över hur kartan får sin extra funktionalitet
Det första som görs i metoden är att listan töms, vilket är enda sättet att slippa rita
ut linjer som är tillagda sedan innan, då det inte finns något sätt rensa dem utan att
rensa hela kartan (och alla kartpunkter därtill). Därefter skapas ett objekt av typen
PolyLineOptions, som kan ta en samling koordinater vilka den kan använda att rita
en linje mellan alla koordinater. Linjerna ritas sedan ut på kartan.
En översikt av hur CustomMapRenderer förhåller sig till övriga klasser finns i figur
4.1.
4.1.8 Data
PointDatabase
Den här klassen kopplar ihop appen med databasen genom att tillhandahålla metoder
för att lägga till och ta bort objekt på olika sätt.
När ett objekt av databas-klassen skapas så skapas också de tabeller som behövs i
databasen. I det här fallet behövs bara en tabell, då vi bara har objekt av typen
PointOfInterest att spara. Att jobba mot databasen görs med hjälp av ORM[Incu].
32
ORM står för Object Relational Mapping och innebär att man tillåts spara objekt
i en SQL-databas utan att använda SQL-frågor [Incu]. Databasklassen använder sig
av SQLite.NET’s hjälpbibliotek, som bland annat tillhandahåller funktioner för att
skapa (CreateTable), lägga till (Insert), ta bort (Delete) och hämta (Get eller via
Table). Dessutom kan man via metoden Query skriva SQL-frågor om man skulle
behöva göra något specifikt, som inte finns i hjälpbiblioteket. I PointDatabase behövs
detta bara göras i en metod, då en specifik typ av plats efterfrågas, tex en rutt eller
en uthyrning, då alla olika typer lagras i samma tabell.
Resten av metoderna i PointDatabase använder sig av ORM-bibliotekets metoder
och klarar av att hämta alla objekt i databasen, lägga till i databasen, hämta ett
specifikt objekt via ID, ta bort ett specifikt objekt via id samt ta bort alla objekt.
När man accessar databaser måste man se till att samma databas inte samtidigt kan
accessas från en annan tråd, därför använder alla metod en låsmekanism, som i appen
kallas locker. Om alla databasanrop omges av samma låsning kommer inget anrop
att kunna göras samtidigt som ett annat då det anrop som görs först kommer att
låsa tillgången för alla rader kod som omges av låsningen oavsett var den utförs.
Man måste dessutom se till att all kod som omges av en låsning är simpel. Skulle
man tex råka anropa en metod utanför den egna låsningen som också har en låsning
fastnar programmet i låsningen [Inck].
33
5 Resultat och Utvärdering
5.1 Introduktion
Resultatet består av två delar, där en del är implementationen och den andra en utvärdering
av utvecklingsmiljön som implementationen skrivits i.
5.2 Implementationsbeskrivning
Implementationen, eller appen, som är tänkt som ett hjälpmedel för paddelintresserade,
fungerar till fullo på Android och med begränsningar på Windows Phone och kan visa olika
typer av intressepunkter knutna till paddling på två olika sätt, karta och lista.
När appen startas sker anrop till det underliggande API som hanterar enhetens GPS och
kan ta fram en geografisk plats. Denna plats sparas och uppdateras sedan när när platsen
ändras, alltså när enheten flyttas, eller mer korrekt, när GPS-koordinaterna uppdateras.
Den första sidan som visas är menyn som ses i figur 5.1. Menyn har tre knappar för
olika alternativ, visar en titel och en kort vägledningstext. Varje knapp tar användaren
vidare till en ny sida där intressepunkter presenteras på olika sätt. Den första knappen tar
användaren till kartsidan, den andra till listan och den tredje till en sida där rutter som
finns i användarens närhet presenteras. Sidan är en navigationssida och har därför också
en meny längst upp som fungerar som en navigationsmeny, inte olikt den i en webläsare.
Den enda knappen som existerar där som standard är en knapp som indikerar att man
är på första sidan. Navigationsmenyn stannar genom alla sidor eftersom navigationen sker
med hjälp av att den sida som öppnas läggs på navigationsstacken och ligger ovanpå den
första sidan. När detta sker byts knappen i navigationsmenyn mot en bakåtknapp och
indikerar detta med en bakåtpil, så att användaren ser att den inte längre är på första
sidan. Navigationsmenyn kan dessutom användas för att lägga till knappar om så önskas,
vilket syns på nästa sida.
Kartsidan som syns i figur 5.2 visar enbart en karta, på vilken de intressepunkter som
34
finns inom kartans område visas. Användaren kan klicka på punkter på kartan för att få
upp mer info, såsom en dragen rutt och informationsruta, som även i sin tur går att klicka
på för att ta sig vidare till en detaljsida för vald punkt. I menyn syns även ett antal knappar
som kan användas för att filtrerar resultaten på kartan så att dessa enbart visar en viss typ
av punkt, om man exempelvis skulle vara intresserad av att bara se alla uthyrningsställen.
Listsidan visar enligt figur 5.3 en lista över intressepunkter och erbjuder samma fil-
trering som kartsidan. Även här tas man till en detaljsida om man klickar på någon av
punkterna.
På detaljsidan i figur 5.4 visas lite mer info om en punkt, såsom längd och en beskrivning
som lagts in av den som underhåller databasen. Här finns även en mindre karta så att man
kan se var punkten är.
Den sista sidan som syns i figur 5.5 är den som visar punkter som finns i närheten. Den
visar både en lista och en karta och presenterar den karta som finns inom ett vist avstånd
från enhetens position.
Som synes har varje sida kvar navigationsmenyn med vilken man kan backa genom navi-
gationsstacken. Det går dessutom att använda telefonens bakåtknappt för samma funktion.
5.3 Utvärdering av app-utvecklingen
Att arbeta i C# och Visual Studio med eller utan Xamarin innebär inga större förändringar,
bortsett från en del uteblivna hjälpmedel som lyfts fram i avsnitt 5.4.1. Detta betyder dock
inte att det inte finns mycket nytt att lära sig när man börjar utveckla med Xamarin. Det
finns det ett flertal API:er [Incw; Incz] som motsvarar de som finns på Android-, iOS
och Windowsplattformarna man behöver använda och man behöver viss förståelse för hur
Xamarin fungerar [Inct].
När man arbetar med något nytt hålls förväntningarna nere och man försöker vara öp-
pen för att kunna anpassa utvecklingen i takt med att den sker. Det enda som egentligen
förväntades var att det, just för att mycket var så nytt, skulle behövas läsas nästan lika
35
Figur 5.1: Startmenyn i implementationen
36
Figur 5.2: Kartan i implementationen
37
Figur 5.3: Listan i implmentationen
38
Figur 5.4: Detailjsidan i implementationen
39
Figur 5.5: Punkter i närheten
40
mycket som skrivas - och att det skulle dyka upp en hel del oväntade problem. Något som
också blivit just som det förväntades. Uppskattningsvis hälften av tiden lagd på implemen-
tation har spenderats i Xamarins guider, dokumentation och exempel, inte bara innan,
utan också under tiden, som projektet fortskridit. Något som gjorde att tiden lagd på att
faktiskt koda blev lidande, då läsandet blev en nödvändig del i arbetet.
Ganska tidigt i projektet, när vidden av Xamarins dokumentation uppdagades, höjdes
förväntningarna för resterande delar i implementationen. Det finns, på Xamarins hemsida
[Incx] guider och dokumentation för så gott som allt, och det ger ett intryck av att det går
att göra nästan allt i Xamarin. Det som saknas kom därför som en lite större överraskning
än det borde ha gjort. Att kartorna skulle sakna en del funktionalitet stod klart från början,
men hur mycket som skulle saknas var oväntat. Den överlägset största delen tid spenderad
på implementationen lades på få kartorna att fungera enligt kravspecen, och då bara för
en plattform. Att anpassa kartorna var ju som tidigare diskuterats plattformsspecifikt, och
det tog alltför mycket tid bara att få det att fungera på Android för att överväga att
göra en liknande insats för Windows Phone. Resten av implementationen gjordes dock för
båda plattformarna och även om menyer och listor, i princip allt utom kartan, fungerar på
Windows Phone så är appen inte helt användbar för denna plattform utan kartan.
Det har heller inte lagts mycket arbete på att snygga till appens utseende, utan först
och främst att få funktionerna att fungera, vilket de också gör. Appen har många vägar att
utvecklas vid projektets slut, och kanske också kommer göra det. Men projektet avslutas
med en fullt användbar app.
5.4 Utvärdering av Xamarin
Ett av de uttalade målen med projektet var att genom att använda Xamarin för att utveckla
en app sedan kunna utvärdera Xamarin som mjukvara. Som beskrivits används Xamarin
för att skriva appar till Android och iOS i C#, precis som Windows Phone, och erbjuder
dessutom möjligheten att dela kod mellan projekt i det fall då man vill skriva sin app
41
till fler än en plattform. Hur väl detta fungerar är den första delen av utvärderingen,
och bedöms utifrån hur väl Xamarin har fungerat för just den app som kodats i detta
projekt. Även om appen är förhållandevis begränsad i användningsområde och tiden till
utveckling varit begränsad till ett examensarbete har appen fått använda många olika
element både i bakomliggande kod och användargränssnitt, samt har en bakomliggande
databas, så Xamarin och dess funktioner har utnyttjats med bredd.
Den andra delen av utvärderingen gäller beslutet att använda Xamarin.Forms istället för
att utveckla användargränssnitt för varje app för sig. Xamarin.Forms är alltså det bibliotek
som Xamarin erbjuder som ett alternativ till plattformsspecifika användargränssnitt och
innehåller de allra flesta [Incy] kontroller som återfinns i de olika plattformarna så att man
som utvecklare bara behöver koda en typ av användargränssnitt, vilket sedan översätts av
Xamarin till varje specifik plattform. Det finns med Xamarin.Forms möjlighet att båda
använda XAML och C# [Incaa] samt anpassa sin app till MVVM [LeB].
5.4.1 Diskussion kring Xamarin
Till att börja med måste nämnas att Xamarin är under ständig utveckling och funktioner
som inte funnits tillgängliga under appens utveckling skulle mycket väl kunna vara under
utveckling och finnas tillgängliga i framtiden [Jas; Staa]. Till exempel introducerades Xa-
marin.Forms i samband med släppet av Xamarin 3 bara tre månader innan projektet drog
igång [Fri].
Den övergripande upplevelsen har under projektets gång varit att Xamarin är ett verk-
tyg med vilket man kan spara både tid och resurser när man utvecklar för fler plattformar
genom att bara behöva skriva stora delar av koden en gång, istället för två eller tre, men
att man noga bör planera i vilken utsträckning Xamarin används och vilka funktioner man
vill nyttja för inte hamna i en situation där tiden man förväntas spara på att använda
Xamarin går åt till att lösa oväntade svårigheter.
Efter att ha använt Xamarin i projektet har både fördelar och nackdelar med att an-
42
vända Xamarin blivit tydliga, även om fördelarna, åtmistone för författaren, varit fler. De
största fördelarna är den enhetlighet och överblick man får över sitt projekt. Istället för
att använda tre olika språk och tre olika utvecklingsmiljöer för att utveckla samma app för
de populäraste mobila plattformarna kan man ha hela sitt projekt i Visual Studio, eller
Xamarin Studio, och skriva all kod i C#. Det gör inte bara utvecklingen av appen mer
översiktligt, man slipper undan mycket redundans även i underhållet när man bara har en
kodbas att uppdatera. Om användandet av just C# som programspråk är en fördel eller ej
lämnas osagt, men C# är ett av de populäraste programspråken [tio; Cas] och bör således
ha en stor skara användare. C# är dessutom ett rent objektorienterat språk, och är väldigt
likt bland annat Java [Kir]. Det bör således vara enkelt att lära sig om man sedan innan
har kunskap om objektorienterade språk.
Dokumentationen är en annan av Xamarins starka sidor [Incx]. Nästan allting som går
att använda i Xamarin har någon form av guide [Incm] och det finns hundratals exempel
[Stab] att hämta inspiration och idéer ifrån. Om man inte skulle hitta det man behöver
i Xamarins officiella dokumenation finns det gott om tredjepartskällor där man kan hitta
exempel och även utökade bibliotek [autd; auta; autc]
Efter att appens användargränssnitt skrivits med Xamarin.Forms, den verktygslåda
Xamarin erbjuder för att skriva gränssnittskod som går att dela mellan plattformar, har
både fördelar och nackdelar med att använda denna upptäckts. Med Xamarin.Forms kan
man gå ytterligare ett steg mot att fullständigt dela kod mellan plattformar, där man
tidigare behövt skriva plattformsspecifik gränssnittskod kan man nu dela även denna mellan
Android, iOS och Windows Phone [Incc]. Detta ger förstås samma fördelar som delandet
av övrig kod ger, mer överblick och mindre att underhålla. Att Xamarin.Forms kan skrivas
med både XAML, Microsofts XML-baserade deklarativa markup-språk utvecklat för just
grafiska gränssnitt [Micd; Micg], och C# ger möjlighet att välja det man är mest bekväm
med. Men här finns också den första nackdelen med Xamarin.Forms. Har man tidigare
utvecklat appar för .NET-Ramverket och använt XAML för att koda gränssnitt är chansen
43
stor att man är van vid Microsofts IntelliSense [Micc], det verktyg som i Visual Studio
hjälper utvecklaren att skriva kod genom att exempelvis föreslå hur ett påbörjat ord ska
avslutas eller vilka egenskaper olika objekt har. Utan IntelliSense krävs att man utantill har
kunskap om alla objekt som kan läggas till i ett gränssnitt och alla egenskaper de besitter
för att kunna anpassa gränssnittet som man vill, eller att man helt enkelt tar reda på allt
man behöver veta genom att läsa dokumentationen. IntelliSense kan säkert anses vara en
bekväm lyx, men är i det här fallet klart saknad. Att IntelliSense saknas verkar bero på
tekniska barriärer, något som man på Xamarin jobbar på att lösa [Jas]. Tills vidare har
det under projektets gång introducerats en lösning som utvecklarna på Xamarin utvecklat
utanför arbetstid [Dan] och som finns att ladda ner som ett fristående tillägg till Visual
Studio sedan mitten av oktober [autb] och tillhandahåller IntelliSense för Xamarin.Forms.
Att Xamarin.Forms är omfattande råder ingen tvekan om, det innehåller alla de vanliga
gränssnittskontroller som finns över de tre plattformarna och har stora anpassningsmöj-
ligheter [Incy]. Men det finns kontroller som saknar viktig funktionalitet. Kartan, som
använts i appen, har visat sig vara en sådan. Kartan som Xamarin.Forms erbjuder är bara
ett kartelement som kan ritas ut, och sedan kan fasta kartnålar fästas på kartan via kod.
Något som appen krävde var att kartan skulle vara interaktiv och kunna rita ut linjer för
att representera rutter, något som nuvarande version av Xamarin.Forms.Maps inte klarar
[Incv]. Att kontroller saknar funktionalitet innebär dock inte att de inte går att använda.
Xamarin erbjuder en möjlighet att plocka upp den saknade funktionaliteten från underlig-
gande plattformsspecifika API:er [Incj]. Vid kompilering mappas Xamarin.Forms-kod mot
de kontroller som finns i det API som appen kompileras för. Alltså, om appen kompile-
ras för Android mappas Xamarin.Forms.Maps mot Googles kart-API. Som utvecklare har
man möjligheten att skriva ett par klasser, en Custom Renderer och en klass som ärver
den kontroll man vill använda, i det här fallet Maps. Man kan sedan via Custom Render-
klassen lyfta upp funktionalitet till sin nya anpassade klass av Maps och använda denna
klass när man lägger ut sin karta i appen, istället för den befintliga. Detta måste göras för
44
varje plattform för sig och man kommer således ifrån själva syftet med att använda Xama-
rin.Forms från början - möjligheten att dela kod. Det kräver dessutom att man sätter sig
in hur dessa funktioner fungerar för alla plattformar man vill att de ska fungera för, och
kan kosta en del tid.
En sista avsaknad av funktionalitet för plattformsöverskridande utveckling var möjlig-
heten att ta fram en geografisk plats med hjälp av telefonens GPS. Det finns möjlighet att
göra detta för varje specifik plattform [Incn], men att dela sådan kod går inte. Detta verkar
bero dels på hur olika detta fungerar över plattformarna och även över olika enheter. Vill
man lösa detta får man skriva kod specifikt för den plattform det gäller [Incq], eller använda
någon av de fristående lösningar som tillahandahålls. Xamarin utvecklar själva alternativet
Xamarin Mobile [Incb], och dessutom finns tredjepartslösningar som Xamarin.Forms.Labs
[autd] och ACR [auta].
Sammanfattningsvis har fördelarna med Xamarin övervägt nackdelarna. Med Xamarin
var det möjligt att utveckla PaddelAppen för två1 olika plattformar med ett gemensamt
programspråk och att dessutom kunna dela upp til 90% av all kod [Incp] är en källa till
ökad effektivitet och öppnar också möjligheter för den som tidigare inte haft kunskap att
utveckla för någon av plattformarna. Att det dessutom finns en stor skara utvecklare både
bakom Xamarin men också bland användarna som skapar fristående API:er och bidrar med
öppen källkod ökar potentialen ytterligare.
5.4.2 Alternativ till Xamarin
Jämförelsen av Xamarin och ett antal andra utvecklingsmiljöer som här följer har baserats
på vad som går att läsa sig till i de angivna källorna och är inte något som det i projektet
funnits utrymme att testa. Det är således enbart en jämförelse av hur de olika metoder som
används för att åstadkomma plattformsoberoende utveckling fungerar och en del funktio-
nalitet som vissa av miljöerna har men andra saknar. Det finns två huvudsakliga metoder
1Egentligen tre, men Xamarin.iOS var inte licensierat i projektet och har därför inte kunnat användas.
45
som nyttjas av utvecklingsmiljöer som tillåter plattformsoberoende utveckling. Det ena är,
som Xamarin, att låta användaren utveckla med ett visst språk som sedan översätts till
det för målplattformen ursprungliga språket. Det andra är att helt enkelt koda appen som
om den vore en hemsida, som sedan öppnas som en app i en webläsare och därför fungerar
på flertalet plattformar.
PhoneGap [Pho] är ett exempel på en miljö som låter användaren skriva HTML-
baserade webapplikationer som kan installeras som vanliga appar som körs i en web-vy
via plattformens webläsare. Precis som när man utvecklar en websida skrivar man i Pho-
neGap HTML, Cascading Style Sheets (CSS) och JavaScript och eftersom man är beroende
av en webläsare för att appen ska kunna köras beror därför också kvalitén på appen till stor
del på webläsaren [Sil]. Man är också beroende av att det finns stöd för specifika sensorer
på enheten appen ska användas på, och i HTML5 finns stöd för en del, men inte alla [Fir].
Appcelerator [App] är, likt Xamarin, en miljö där man utvecklar till flera plattformar
samtidigt med ett språk som sedan översätts. I Appcelerator skriver man i JavaScript och
översättningen sker först när koden distribuerats till enheten där den tolkas av den för
plattformen specifika javascript-motorn. Här skiljer sig Appcelerator från Xamarin mar-
kant, där man i Xamarin översätter till ursprungskoden för den avsedda plattformen vid
kompilering [Inci].
Xamarin är dessutom just nu den enda miljö som erbjuder en möjlighet till gräns-
snittskodning som använder ursprungs-API:erna på varje plattform via Xamarin.Forms.
5.5 Kapitelsammanfattning
Resultatet av projektet är en app samt en utvärdering av Xamarin. Appen har en databas
med platser som är av intresse för paddlare och kan presentera dessa på en karta, en ta
fram platser som finns i närheten utifrån den positon som läses från enhetens GPS.
Efter utfört projekt kan konstateras att även om Xamarin inte innebär att användandet
av Visual Studio och C# förändras finns ändå mycket nytt att lära sig i form av API:er och
46
hur man lägger upp ett projekt för fler plattformar. Dessutom har den specialanpassning
som behövts göras för att få in nödvändiga funktioner inneburit tidsbrist som drabbat
andra, mindre viktiga, funktioner.
En del brister med Xamarin har stötts på under projektets gång men det kan konstateras
att många av bristerna täcks in av fristående lösningar samt att Xamarin är i ständig
utveckling. Sammanfattningsvis är utvärderingen av Xamarin positiv, det är ett verktyg
med många fördelar bör kunna spara både tid och resurser.
47
6 Slutsats
6.1 Slutsats
Appen som del av projektet har tagit mer tid än väntat. Detta beror på många saker. Bland
annat har det varit väldigt mycket nytt att lära sig och det har krävts en hel del läsning.
Därtill är det mycket som inte har funnits dokumenterat vilket lett till att information
som behövts för att lösa vissa problem har fått hittas på annat håll, från tredje part. Det
har dessutom helt enkelt inte gått att använda Xamarin.Forms till vissa delar i projektet
och andra lösningar har fått tas fram för de delar i projektet där Xamarin.Forms varit
oanvändbart. Det fanns från början i projektet en lista med prioriteringar som synes i figur
6.1 för alla funktioner och de viktigaste, och några mindre viktiga, funktioner har kunnat
implementerats till fullo, medan några mindre viktiga har fått skjutas på framtiden till
följd av att ovanstående tagit mer tid i anspråk än väntat.
Problemen till trots så har det som implementerats gått bra, funktionerna fungerar som
de ska och appen kan användas som den är.
Projektet hade heller inte som mål sedan start att enbart skriva en app. Därtill ingick
att lära sig om och utvärdera en utvecklingsmiljö och även om koddelen i projektet har
stött på en del hinder, planering fått ändrats och målbilden för appen fått krympas en
aning har allt detta haft en stor del i utvärderingen av Xamarin. Det har blivit tydligt att
Xamarin är ett projekt under ständig utveckling, en hel del funktioner har tillkommit bara
under den tid appen varit under utveckling.
6.2 Projektutvärdering
Inledningsvis har projektet inneburit mycket kunskapsinsamlande. Xamarin är en väl ut-
vecklad miljö, dock inte helt utan brister, med omfattande dokumentation som projektet
haft stor nytta av. Projektet avslutas med fungerande mobilapplikation som till största del
möter målen i kravspecifikationen.
48
Figur 6.1: Prioriteringspunkter
Att sitta på ett företag och arbeta har inneburit att det alltid funnits konsulterings-
möjligheter vid problem och dessutom användande av deras Team Foundation Server för
källkodshantering.
Projektet har stött på en del problem, som diskuteras i nästa avsnitt, något som tvingat
fram djuplodande sökning efter lösningar. Valet att jobba själv i projektet har förmodligen
här också spelat in allra mest, och lett till att många förslag testats för att sedan förkastas
till fördel för nya till följd av svårigheten att ensam se problemen med ens egna idéer. Att
sitta på Sogeti har avhjälpt många av dessa problem då det där finns någon att fråga när
problem stötts på.
Att jobba själv har också inneburit vissa svårigheter att uppskatta tidsåtgång och
omfattning för en del idéer. För projektet har det inneburit att vissa saker blivit klara
mycket tidigare än väntat, och att några även blivit klara mycket senare, såsom kartan.
49
6.3 Problem
De flesta problem som uppstått under projektets gång har sin grund i att det för förfat-
taren är ett förhållandevis nytt område. Inledningen av projektet bestod uteslutande av
läsning för att sätta sig in i vad Xamarin innebar och hur det skulle användas, då det
finns en del olika sätt att jobba på [Inch], och dokumentationen användes som referens un-
der hela implementationen. Därtill behövde allting som kodades i projektet övervägas ett
flertal gånger och för varje lite mer avancerad funktion har flera olika möjligheter utfors-
kats. Trots all påläsning har det många gånger under projektet dykt upp oväntade saker,
speciellt rörande svårighetsgrader och omfattning på lösningar som behövt användas samt
begränsningar i de tillvägagångssätt som valts. Därtill har det ofta varit svårt, eller ibland
inte ens gått, att hitta förklaringar eller exempel på hur vissa av problemen skulle lösas
och det finns ett par problem där man helt enkelt fått prova sig fram tills man hittat något
som fungerat har därför tagit extra lång tid.
Ett område där de flesta av dessa problem uppstod är, som tidigare beskrivits, att
kartorna saknade nästan all funktionalitet utöver att faktiskt rita ut en karta. Det var
oväntat både att kartorna skulle vara såpass fattiga som de var på funktionalitet, och
att det som krävdes för att få den saknade funktionaliteten till kartorna var både såpass
omfattande och nästan helt saknade dokumentation på Xamarins webplats. I det här fallet
så fanns det en lösning på ett liknande problem av en Robert Echten [Ech] som kunde
användas som idégrund för att lösa det problem som här beskrivits. Det här exemplet
hade en lösning på hur man kunde sätta ut interaktiva punkter på kartan som sedan i
projektet kunde utökas för att även gälla utritande av linjer på kartan som ju behövdes
för att markera rutter.
Ett liknande problem var hur man skulle få fram koordinater till den plats användaren
och dennes mobiltelefon befann sig genom tillgång till dennes GPS. Det visade sig även här
att Xamarin.Forms i nuläget har en del begränsningar, och att det via dokumentationen inte
gick att hitta mer information. Däremot är det här ett exempel på hur mycket som går att få
50
tag på via tredje part. Det finns i det här fallet ett bibliotek som heter Xamarin.Forms.Labs
som erbjuder metoder för att i Xamarin.Forms få fram koordinater via en GeoLocation-
klass. Här uppstår tyvärr nästa problem, även detta bibliotek lämnade en hel del att önska
gällande dokumentation och en implementation av detta löstes aldrig i tid och en annan
metod valdes istället, som begränsar (precis som kartan) funktionaliteten till Android-
plattformen.
Hade mer tid lagts vid att läsa på och lära sig innan projektet drogs igång hade förmod-
ligen dessa problem kunnat undvikas, exempelvis genom att man beslutat att inte använda
Xamarin.Forms och fokuserat på att färdigställa appen för en plattform och påbörjat ar-
bete för den andra plattformen i mån av tid. Men då målet var att verkligen se hur mycket
man kunde utnyttja Xamarin för att samutveckla till flertalet plattformar och utvärdera
hur väl det fungerar var valet att använda Xamarin.Forms till fördel för projektet då det
gav en hel del insikt i vilka begränsningar det innebär.
Problem uppstod även utanför själva kodandet av appen, då appen skulle testas på både
Android och Windows Phone. För att testa mjukvara på Windows Phone kan man använda
en emulator som finns att ladda ner till Visual Studio som en komponent i Windows Phone
Software Development Kit [Mice]. För att sedan köra denna emulator behövs Hyper-V, ett
virtualiseringsverktyg som introducerades med Windows 8 [Mica; Micb].
Ska man däremot testa appen på Android behövs ett fristående program som bidrar
med en emulator för Android och i projektet valdes mjukvaran Genymotion via vilken man
kan ladda ner en rad olika emulatorer som emulerar olika smartphones eller tablets med
olika verisoner av Android. När Hyper-V är installerat på datorn startas det automatiskt
tillsammans med Windows, och det visade sig att när Hyper-V körs kan man inte göra
virtualiseringar av andra operativsystem via annan mjukvara. Lösningen på det här blev att
hitta ett sätt att starta Windows utan att Hyper-V startades, och sedan testa applikationen
på Android. Men då detta krävde omstart varje gång man behövde testa på den andra
plattformen var lösningen relativt osmidig, och det hade kanske varit smartare att testa
51
för den ena plattformen på en emulator och för den andra platformen faktiskt ha en fysisk
enhet att testa på vid sidan av och på sätt slippa starta om datorn.
Till sist visade sig även en del problem med att jobba själv i ett projekt, istället för
i par eller större grupp. Uppskattningar gällande tidsåtgång eller omfattning av uppgifter
har varit svåra att göra vilket ibland inneburit att vissa saker, även utan att andra problem
stötts på, har tagit längre tid än vad som förutsetts och vissa saker har blivit klara mycket
tidigare än väntat. Projektet har därför efterhand blivit ganska svårt att planera, någonting
som kanske inte heller haft så stor inverkan, då flexibiliteten det innebär att jobba själv
gör det enkelt att komma runt planeringsproblem. Det har också varit svårt att ensam se
nackdelar med ens egna idéer innan man hunnit prova dem i praktiken, vilket i sin tur lett
till att flera olika lösningar provats innan ett beslut om vilken som bör användas tagits.
Hade man jobbat i par eller grupp hade kanske tidsåtgången för vissa lösningar kunnat
minskas, inte bara för att man varit två som kunnat dela på jobbet, utan även för att
omfattningen kunnat uppskattas bättre och vissa idéer efter diskussion kunnat uteslutas i
ett tidigare skede.
Sammanfattningsvis var orsakerna till de flesta problem att kunskaper saknades från
början och mycket var nytt, vilket gjorde det svårt att förutsäga många av de problem
som uppstod. Som nämnts tidigare kunde det till viss del förhindrats av att förlänga peri-
oden av inläsning. Man kan också konstatera att projektet varit otroligt lärorikt och allt
praktiskt arbete som behövts göras, i efterhand varit minst lika värdefullt som en utökad
inläsningsperiod hade kunnat vara.
6.4 Framtida arbete - utveckling av projektet
Projektet skulle kunna vidareutvecklas både genom att lägga till de funktioner som inte
hanns med men också genom att utöka appen med nya funktioner och kanske även täcka
in andra områden. En av de saker som gärna hunnits med var såklart full implementation
över flera plattformar, något som till viss del hindrades av den ganska stora avsaknad
52
av funktioner i det gemensamma gränssnitts-biblioteket Xamarin.Forms. Här skulle krävas
att samma anpassning som gjordes för Android med Custom Renderers och skräddarsydda
klasser för även andra plattformar, först och främst Windows Phone.
Ytterligare en sak som fanns på önskelistan vid projektets början var att få med möj-
lighet för användare att logga in och utnyttja tillhörande funktioner, vilket hindrades av
att många andra delar i projektet tog längre tid än väntat. Som har diskuterats tidigare
finns olika möjligheter och vid en framtida implementation av denna funktionalitet är det
viktigt att ta hänsyn till god hantering av användaruppgifter samt se till att gränssnittet
blir smidigt att använda.
En funktion som kommit upp till diskussion under projektets gång men som inte tidigare
diskuterats i rapporten är möjligheten att underhålla databasen. För att databasen ska bli
enkel att fylla med information om nya platser och rutter vore det bra om det fanns
ett smidigt sätt att lägga in nya poster. Detta skulle exempelvis kunna göras via ett
webgränssnitt, där en administratör kan logga in på en websida som har kontakt med
databasen och där man kan lägga in olika typer av kartpunkter. Ett sådant webgränssnitt
skulle kunna vara av mycket enkel design då den bara skulle användas av ett fåtal, och
måste ha en funktion som låter användaren rita ut rutter på en karta och få dem sparade
i databasen.
Man skulle i framtiden även kunna titta på ideér som skulle kunna använda den be-
fintliga funktionalitet som finns i appen. Appen kan ju rita ut punkter och leder på en
karta och har en databas som håller information om alla platser, och steget att anpassa
appen för till exempel vandringsleder istället för paddelleder, eller varför inte stödja både
och, bör inte vara så långt. Det finns förmodligen möjlighet att göra en mer eller mindre
heltäckande friluftsapp där man visar intressanta platser för tältning, eldning, och all övrig
information man kan tänkas vilja ha när man är ute i naturen och dessutom kunna visa
en mängd olika leder, såsom vandringsleder, cykelleder, klättringsleder, skidspår och sko-
terleder. Skulle appen uttökas så här mycket bör man förmodligen titta på att optimera
53
hur man hämtar data från databasen. Man kanske bör dela in alla platser i geografiska
regioner så att man bara hämtar data från den region man befinner sig i eller den region
användaren anger, samt att man kan titta på att optimera själva databasanropen så att
de använder databasfrågor istället för de färdiga anrop som finns i SQLite.NET.
54
Referenser[Har03] Elliotte Rusty Harold. Effective XML: 50 Specific Ways to Improve Your XML.
1. utg. Addison-Wesley Professional, 2003. isbn: 978-0321150400.
[Ale] Rafael Teixeria Alexander Köplinger. About Mono. url: http://www.mono-project.com/docs/about-mono/.
[App] Appcelerator. Titanium Developer Portal. url: http://www.appcelerator.com/developers/.
[Aut] Various Authors. SQLite.NET. url: https : / / components . xamarin . com /gettingstarted/sqlite-net.
[auta] Various authors. ACR-Xamarin.Forms. url: https://github.com/aritchie/acr-xamarin-forms.
[autb] Various authors. Mobile Essentials GIT-repo. url: https : / / github . com /MobileEssentials/Gallery.
[autc] Various authors.MVVMCross. url: https://github.com/MvvmCross/MvvmCross.
[autd] Various authors. Xamarin.Forms.Labs. url: https : / / github . com / XLabs /Xamarin-Forms-Labs.
[Bes] Ten of the Best Cross-Platform Mobile Development Tools for Enterprises. Chri-sopher Reynolds. url: http : / / appindex . com / blog / ten - best - cross -platform-development-mobile-enterprises/.
[Bur] Amy Burns. Background Location Demo. url: https://github.com/xamarin/mobile-samples/tree/master/BackgroundLocationDemo/location.Android.
[Cas] Stephen Cass. Spectrums 2014 Ranking. url: http://spectrum.ieee.org/computing/software/top-10-programming-languages%5C#.
[Dan] Team Lead Xamarin Visual Studio Extension Daniel Cazzulino. Mobile Essen-tials: Productivity Tools for Mobile Developers. url: http://www.cazzulino.com/mobileessentials.html.
[Ech] Robert Echten. BindableMapTest. url: https://github.com/raechten/BindableMapTest.
[Fir] Maximiliano Firtman. HTML5 compatibility on mobile and tablet browsers withtesting on real devices. url: http://mobilehtml5.org/.
[Fri] Nat Friedman. Announcing Xamarin 3. url: http : / / blog . xamarin . com /announcing-xamarin-3/.
[Gos] John Gossman. Introduction to Model/View/ViewModel pattern for building WPFapps. url: http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx.
55
[Inca] Google Inc. PolyLine Class. url: https://developers.google.com/maps/documentation/javascript/reference#Polyline.
[Incb] Xamarin Inc. Accelerate with Xamarin Mobile. url: http://xamarin.com/mobileapi.
[Incc] Xamarin Inc. An Introduction to Xamarin.Forms. url: http://developer.xamarin.com/guides/cross-platform/xamarin-forms/introduction-to-xamarin-forms/.
[Incd] Xamarin Inc. Backgrounding. url: http://developer.xamarin.com/guides/android/application_fundamentals/backgrounding/.
[Ince] Xamarin Inc. Build better apps for iOS, Android and Mac with Xamarin Studio.url: http://xamarin.com/studio.
[Incf] Xamarin Inc. Build native iOS, Android and Windows apps in Visual Studio.url: http://xamarin.com/visual-studio.
[Incg] Xamarin Inc. Building Cross Platform Applications Overview. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_0_-_overview/.
[Inch] Xamarin Inc. Building Cross-Plattform Applications. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/.
[Inci] Xamarin Inc. Create Native iOS, Android, Mac and Windows Apps in C. url:http://xamarin.com/platform.
[Incj] Xamarin Inc. Customizing Controls for Each Platform. url: http://developer.xamarin.com/guides/cross-platform/xamarin-forms/custom-renderer/.
[Inck] Xamarin Inc. Database Configuration. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/data/part_2_configuration/.
[Incl] Xamarin Inc. From Data Bindings to MVVM. url: http://developer.xamarin.com/guides/cross-platform/xamarin-forms/xaml-for-xamarin-forms/data_bindings_to_mvvm/.
[Incm] Xamarin Inc. Guides. url: http://developer.xamarin.com/guides/.
[Incn] Xamarin Inc.Handling Platform Divergence and Features. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_4_-_platform_divergence_abstraction_divergent_implementation/.
[Inco] Xamarin Inc. Installing Xamarin.iOS on Windows. url: http://developer.xamarin.com/guides/ios/getting_started/installation/windows/.
56
[Incp] Xamarin Inc. Introduction to Mobile Development. url: http://developer.xamarin.com/guides/cross-platform/getting_started/introduction_to_mobile_development/.
[Incq] Xamarin Inc. Location Services. url: http://developer.xamarin.com/guides/android/platform_features/maps_and_location/location/.
[Incr] Xamarin Inc. Typical Application Layers. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_2_-_architecture/.
[Incs] Xamarin Inc. Understanding the Xamarin Mobile Platform. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_- _understanding_the_xamarin_mobile_platform/.
[Inct] Xamarin Inc. Understanding the Xamarin Mobile Platform. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/part_1_- _understanding_the_xamarin_mobile_platform/.
[Incu] Xamarin Inc. Using SQLite.NET ORM. url: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/data/part_3_using_sqlite_orm/.
[Incv] Xamarin Inc. Working with Maps. url: http://developer.xamarin.com/guides/cross-platform/xamarin-forms/working-with/maps/.
[Incw] Xamarin Inc. Xamarin Android APIs. url: http://androidapi.xamarin.com/.
[Incx] Xamarin Inc. Xamarin Developers Documentation. url: http://developer.xamarin.com.
[Incy] Xamarin Inc. Xamarin Forms. url: http://xamarin.com/forms.
[Incz] Xamarin Inc. Xamarin iOS APIs. url: http://iosapi.xamarin.com/.
[Incaa] Xamarin Inc. XAML for Xamarin.Forms. url: http://developer.xamarin.com/guides/cross-platform/xamarin-forms/xaml-for-xamarin-forms/.
[Jas] Xamarin.Forms Lead Engineer Jason Smith. XAML IntelliSense? url: http://forums.xamarin.com/discussion/comment/82222/%5C#Comment_82222.
[Kir] Windows Embedded MVP Senior Software Engineering Consultant Kirk Ra-deck. C and Java: Comparing Programming Languages. url: http://msdn.microsoft.com/en-us/library/ms836794.aspx.
[LeB] Thomas LeBrun. Build MVVM Apps with Xamarin and MvvmCross. url: http://msdn.microsoft.com/en-us/magazine/dn759442.aspx.
57
[Mica] Microsoft. Client Hyper-V. url: http://technet.microsoft.com/library/hh857623.aspx.
[Micb] Microsoft. Hyper-V Overview. url: http : / / technet . microsoft . com / en -us/library/hh831531(v=ws.11).
[Micc] Microsoft. Using IntelliSense. url: http://msdn.microsoft.com/en- us/library/hcw1s69b.aspx.
[Micd] Microsoft. What is XAML? url: http : / / msdn . microsoft . com / en - us /library/cc295302.aspx.
[Mice] Microsoft. Windows Phone SDK Archives. url: http://dev.windows.com/en-us/develop/download-phone-sdk.
[Micf] Microsoft. Windows Presentation Foundation. url: http://msdn.microsoft.com/en-us/library/ms754130(v=vs.110).aspx.
[Micg] Microsoft. XAML Overview. url: http : / / msdn . microsoft . com / en - us /library/ms752059(v=vs.110).aspx.
[Mich] Microsoft. XAML Overview (WPF). url: http://msdn.microsoft.com/en-us/library/ms752059(v=vs.110).aspx.
[Pho] PhoneGap. PhoneGap Documentation. url: http://docs.phonegap.com/en/4.0.0/index.html.
[Sil] Amanda Silver. Cross-Platform Mobile Development with Visual Studio. url:http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/511.
[SQL] SQLite.org. SQLite Documentation. url: http://www.sqlite.org/docs.html.
[Staa] Xamarin Staff. Xamarin Blog. url: http://blog.xamarin.com/.
[Stab] Xamarin Inc. Staff. Sample Applications. url: http://developer.xamarin.com/samples-all/.
[tio] tiobe.com. TIOBE Index for January 2015. url: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.
[Wal] Norman Walsh. A Technical Introduction to XML. url: http://www.xml.com/pub/a/98/10/guide0.html?page=2%5C#AEN58.
[Zet] Björn Zethelius. Vänerkajak. url: http://www.vanerkajak.se/.
58
Recommended