Den teoretiska delen av arbetet har visat på vad som krävs för att kunna utföra synkronisering mellan enheter i en modern miljö. Det visade sig att tidigare försök till synkronisering mellan ett flertal enheter kräver en långsam synkroniseringsprocess med ett väl utarbetat synkroniseringsschema för att kunna anpassa synkroniseringen till mobilernas begränsade resurser. Dock så visade också vår teoridel på en större problembild än den vi förutsåg vid arbetets inledning. Synkronisering är ett avancerat problem som många på den mobila sidan arbetat på för att försöka lösa. SAMD var det intressantaste alternativet vi hittade i litteraturen som verkade ha samma ambitioner som oss när det gällde att kunna fungera över multipla plattformar och med en enkelt implementation. Övriga lösningar var ofta bundna till endast vissa databaser eller plattformar.
Eftersom vi redan innan arbetet hade valt vilka tre plattformar vi ville fokusera på så fick vi i vår teoridel även mer information vad som var specifikt för just dessa plattformar. Vi kunde sedan använda denna information i vår egen implementation av synkroniseringen.
Några av de viktigaste aspekterna från teoridelen var dessa:
• Synkroniseringen kräver en långsam synkroniseringsprocess
• Synkroniseringen bör ha så få nätverksanrop som möjligt då dessa är kostsamma.
• Synkroniseringen bör ha ett väldefinierat synkroniseringsschema för att spara på den mobila enhetens resurser i bästa möjliga mån.
Vår empiri underströk också dessa punkter. Intervjun med Fredrik Ålund gav en värdefull inblick i hur ett etablerat företag arbetar med synkronisering av data och han visade på att vår problemformulering var korrekt och relevant. Detta gjorde den andra delen av empirin enklare då vi i programmeringsskedet visste vilka delar vi skulle koncentrera oss på.
CrossSync blev ett intressant experiment där vi direkt såg relevansen i teoridelens huvudpunkter. Vi valde våra datastrukturer efter det som var mest effektivt för mobilerna, valde HTTP-‐protokollet för överföring då detta bidrog till en tillförlitlig uppkoppling mot servern och jobbade med att begränsa nätverksanropen så mycket som möjligt.
I självaste synkroniseringen valde vi att använda tidsstämplar för att markera att en tabell blivit uppdaterad. I efterhand kan vi dock se att SAMD’s implementation av MD-‐5 hash på tabellerna möjligtvis hade varit mer tillförlitligt och framförallt inte hade satt kravet på databasen att kräva en kolumn för tidsstämplar i varje tabell.
5.1 Diskussion och generalisering
Vårt arbete har genererat en mängd data som vi valt att tolka på ett kvalitativt vis. Detta har inneburit att vi inte varit fokuserade på att få ut kvantitativa mängder av data utan snarat försökt komma fram till vår slutsats genom att analysera och tolka den information vi samlat genom intervjuer, litteratur och designprocessen av CrossSync. Här nedan redovisar vi de resultat vi anser oss nått med denna studie.
5.2 Slutsats
Det finns många olika sätt att implementera synkronisering på, inte minst om man går ner på kodnivå. Hur kod ska skrivas för att lösa problemet är väldigt individuellt och varje utvecklare har sitt tillvägagångsätt för att lösa problem. Därför har vi inte i detalj beskrivit i kod hur fullt funktionell synkronisering implementeras. Utan snarare i ord hur en fullt funktionell synkroniseringslösning ska fungera och se ut. I denna uppsats har vi istället kommit fram till bra riktlinjer och råd för hur man exempelvis ska skriva sin kod att exekvera i flera trådar, hur man ska paketera information och hantera data som tas bort ur databasen. Nedan följer en kort redogörelse för de slutsatser vi dragit av detta arbete;
Anrop mot server bör exekveras i en egen tråd för att undvika att applikationen låser sig om svarstiderna lär långa. Informationen som skickas bör paketeras med JSON istället för XML för att begränsa datamängden som skickas så mycket som möjligt, därtill hör också att man endast skickar den informationen som är förändrad. Detta görs bäst genom att jämföra tidstämplar eller genom att skapa hashsummor av databasen som sedan jämförs. Skulle en databas bli enormt stor så kan flags-‐metoden spara utrymme eftersom endast ett tecken
krävs, dock kompromissar det betydligt funktionaliteten och fungerar således bara i snabba synkroniseringsmodeller. Att välja Mimer Mobile framför SQLite skulle i vissa fall höja prestandan på synkroniseringen då en sådan databas aldrig låser och många kan därför läsa och skriva data samtidigt. Medan SQLite kan vara bättre då långa transaktioner görs, då databasen låser sig och förhindrar att transaktionen avbryts. Därför är det svårt att dra någon slutsats över vilken som presterar bättre än den andra då det beror på vad det är för typ av data man vill synkronisera.
5.3 Reflektion
Vi märkte tidigt att implementera en fullt funktionell långsam synkroniseringsmodell överhuvudtaget är mer komplicerat än vi förväntade oss. Därtill skulle vi hela tiden ha prestanda i åtanke. Vi har hela tiden försökt att välja det mest prestandamässigt effektiva alternativet under arbetets gång och försökt testa det i den mån det går. Dock är det flera alternativ vi skulle velat testat noggrannare som val av databas tillexempel. Vi vet hur databaserna fungerar i teorin men det hade varit intressesant att implementera en Mimer Mobile databas istället för att empiriskt testa vilken som presterar bäst. Ytterligare ett exempel på något vi hade planer på att testa men inte hann med var att ställa SAMD-‐
modellen mot vår lösning och jämföra vilken som presterar bäst.
I vårt exempel har vi använt oss av en privat server med en medioker uppkoppling. Det har varit intressant att implementera denna lösning på en ”high-‐end” server och testköra synkroniseringen med hög belastning. Vilket vi, i brist på resurser och tid, inte heller hann med att testa.
Vårt eget experiment CrossSync skulle behövt en bredare testning och jämförelse mot andra alternativ för att kunna dra tydliga slutsatser ifrån och kunna framkalla kvantitativ data.
Detta experiment bidrog dock till att svara till vårt syfte som var att få en ökad förståelse för synkroniseringsproblematiken. Vi kan såhär i efterhand se att vi aldrig hade förstått problemet utan att själva försöka oss på en implementation, så även om CrossSync inte bidrog till de kvantitativa data vi hade hoppats på så har den ökat vår förståelse och möjliggjort en underlättad identifiering av problemets alla sidor.
5.4 Förslag på vidare forskning
Under denna rubrik så placeras flera av de punkterna vi hade ”Reflektion” ovan. De vi inte hann med att testa mer noggrant är naturligtvis föremål för vidare forskning. Det vill säga prova andra typer av databaser, servrar och synkroniseringsmodeller.
I Sverige har vi ett annalkande 4G-‐nät i utveckling. När det är färdigbyggt och finns implementerat i mobiltelefoner vore det intressant att testa denna synkroniseringsmodell med 4G-‐nätet som medium för kommunikationen. Hastigheten kommer vara avsevärt högre
än dagens 3G-‐nät, och kanske svarstiderna kortare. De båda är faktorer som i hög grad påverkat detta arbete.
Huvudsakligen så är all teknik ständigt i utveckling med förbättrad prestanda som främsta resultat. Vilket innebär att man alltid kan testa nya tekniker för att se hur de påverkar effektiviteten på synkronisering.