GYMKEEPER ANDREAS SÖDERSTRÖM

Transkript

1 GYMKEEPER ANDREAS SÖDERSTRÖM

2 ABSTRAKT En post mortem på mitt ios-projekt. Utmaningen låg i att under 10 veckors tid sätta sig in i en plattform och programspråk jag aldrig använt förut. Jag har kommit fram till flera do s and don ts i generell mjukvaruutveckling men även specifika problem som går att undvika i Objective-C och Apple s utvecklingsmiljö Xcode. Här följer mina erfarenheter i utvecklingen av en verktygsapplikation med temat träning/hälsa.

3 FÖRORD Alla någorlunda teknik intresserade som har skaffat sig en smartphone och även köpt någon utav superhit-appsen har nog någon idé liggandes som de önskar realisera. Så har det varit för mig i alla fall. Jag tror att den genomsnittsliga smartphone användaren är oförlåtande och har ett väldigt kort fönster öppet där man som utvecklare kan skapa intresse och behålla det. Att ta en användarupplevelse och destillera den till det absolut nödvändigaste är fascinerande. Det är vad som drev mig till att välja just detta projekt. TEKNISKA TERMER: Xcode Är Apple s utvecklingsmiljö för att skriva MacOSX / ios applikationer Core Data Framework Ett ramverk utvecklat av Apple för att spara data permanent i applikationer på användarens iphone. Objective-C Programspråket som används för att skriva MaxOSX / ios applikationer

4 INLEDNING / BAKGRUND Första idén till projektet var ett mindre spel, men då jag aldrig öppnat Xcode förut och aldrig sett Objective-C kod förut så kände jag att skriva spelmekanik och lära sig tillräckligt om språket på 10 veckor var alldeles för snävt. Jag bestämde mig då för att istället producera någon slags verktygs-applikation. Tanken var enkel, identifiera ett formulär av något slag och bygg en applikation runt det. Jag valde att ersätta pappret gymbesökare använder för att logga sina träningsresultat på. Då redan många gymbesökare använder sina smartphones som musikspelare så är det en mottaglig målgrupp för en ny applikation. Efter att ha utfört en konkurrensundersökning på Apple AppStore så drog jag slutsatsen att just denna niche var fortfarande ganska öppen för nya applikationer. De få applikationer jag hittade som utförde just detta låg antingen väldigt högt i pris eller hade ett otroligt stökigt användargränssnitt. Så målsättningen blev att skapa ett verktyg för träningen som hade ett konkret och snabbt gränssnitt. Nästa steg blev att prototypa applikationen med papper och penna och bestämma funktionalitet. Applikationen skulle ha tre delar : Träning [ Lägga till träningspass och logga övningar ] Statistik[ Se hur träningsprestationen ökat under användandet av applikationen ] BMI [ Ett enkelt Body Mass Index analysverktyg ] När idén var formulerad till en skiss av applikationen så var det svårt att sätta igång när plattformen och programmeringsspråket var så okänt för mig. Så jag gjorde vad vilken annan programmeringskurs skulle be mig göra, Jag började utföra mindre laborationer av typen Hello World, Gissa Talet och så vidare för att få grepp om syntax och struktur. Denna typ av arbetssätt återkom flera gånger under projektet när nya tekniker, eller delar av applikationen skulle produceras och jag behövde lära mig hur. Då släppte jag huvudapplikationen och skrev en mindre riktad applikation enbart för att testa viss kod eller teknik.

5 POSITIVA ERFARENHETER Det var ett viktigt mål för mig att känna på att kastas rätt in i ett programmeringsspråk jag aldrig sett förut och framförallt utan en kursplanering och lärarstöd för att hålla en i handen. Det har givit mig mycket användbar erfarenhet som har fått mig att växa som programmerare. Att inte stångas direkt med produktionen av applikationen utan ta sig tid att göra mindre applikationer med endast syftet att lära sig arbetsverktygen var ett bra tillvägagångssätt för att komma igång och undvika en hel del problem. Jag tycker att min riskanalys var ganska bra och de moment som jag identifierade som högriskdelar visade sig mycket riktigt ta mycket utav tiden. Att jobba på ett agilt arbetssätt har verkligen givit en aha-upplevelse, dels i att få upp ögonen för vad som kan verka trivialt kan ta stora resurser och att försöka anpassa nästa sprint efter det. Det känns framförallt som ett måste att vara väldigt anpassningsbar och snabb på att attackera nya problem när man utvecklar något till en okänd plattform. Apple Developer Library var en väldigt bra resurs för att ta reda på information när man kört fast och rekommenderas varmt till den som vill testa ios-utveckling. Jag valde tidigt att investera i en Apple Developer License med rättigheter att publicera applikationer på AppStore så målet har alltid varit där att släppa applikationen kommersiellt. Detta gav en verklighetsankytning till projektet som fungerande som en extra drivkraft.

6 NEGATIVA ERFARENHETER Att utveckla en applikation i Objective-C / Xcode är väldigt annorlunda och har en snäv inlärningskurva. En ny version av Xcode och ios har precis släppts och en hel del förändringar i Xcode samt hur ios behandlar koden har ändrats vilket har gjort att material man hittade sällan var aktuellt och krävde en hel del trial&error på egen hand. Mycket av minneshanteringen har till exempel förändrats i ios. Jag såg det som ett naturligt steg att försöka skapa någon slags navigation i applikationen då det känns som ett bra steg för en nybörjare. Så här i efterhand kan jag säga att den lättaste och minst problemfyllda vägen hade varit att börja med funktionaliteten och byggt ett gränssnitt kring detta. Mycket av problemen man stöter på under ios-utveckling förebygger man snarare än löser senare. Framförallt blir det väldigt svårt att lösa senare. Ett exempel är det absolut största hindret och risken under projektet: Core Data Framework. Core Data Framework var omständigt och rent av dåligt att försöka implementera i efterhand i en existerande applikation. Det rätta arbetssättet hade snarare varit att skapa databasen och bygga appen med Core Data Framework i grunden som binder ihop allt. När man öppnar Xcode och ser dess grafiska gränssnitt Storyboard där man kan dra ut och släppa färdiga kontroller luras man lätt att tro att det är lätt. Vad man senare har insett är att det krävs en hel del jobb och kunskap för att få det mest grundläggande funktioner att fungera som det ska. Några exempel är att man behöver skriva en fix för att se till att ios tangentbordet försvinner när det ska, eller hur objekt sparas i minnet för att uppdatera en tabell. Vad man lätt glömmer är att med en ny plattform följer även ett nytt operativsystem. Jag underskattade helt klart att man är tvungen att öppna huven och faktiskt veta vad som sker och hur ios behandlar koden. Xcode som verktyg har väldigt starka sidor, ett oerhört bra hjälpverktyg och ett stort bibliotek av information och även källkod att titta på. Men jag känner att man blivit lite bortskämd med Visual Studio s felmeddelanden när något går snett. Det var omständigare och klumpigare att leta fel, detta har dock absolut också att göra med att bristande kunskap om hur ios fungerar.

7 SAMMANFATTNING En utav anledningarna att jag valde ett okänt språk för mig och plattform är att jag har en misstanke om att denna typ av situation kan lätt uppstå i arbetslivet där kund efterfrågar en tjänst och det är faktiskt upp till utvecklaren att hitta rätt verktyg för jobbet och sätta sig in i det. Jag känner att jag har ännu ett verktyg som programmerare och bredare kunskap. I det här fallet så känns det som att det är inte det programmeringstekniska som har varit viktigt för mig utan snarare att kasta mig in i ett projekt utan laborations-instruktioner och, åtminstone simulerad brist på skyddsnät. Jag har fått större självförtroende som programmerare och är definitivt mer orädd för att testa för mig okänd teknologi. Jag kan säga att min åsikt om Objective-C är blandad, det är ett rätt klumpigt språk på sina ställen och smidigt på andra. Man märker definitivt åldern på språket med så enkla saker som en string-deklaration. Applikationen tappade ett av sina tre baskrav och fick ett annat utav dem nedbantat. Planen var trots allt att kunna gruppera sina övningar i olika gympass och se övergripande statistik. När jag väl stångats färdigt med Core Data Framework var jag rädd att inte hinna ha någon applikation alls att visa så jag valde att inte ge mig in i flera relationsobject i SQLite databasen som driver det utan nöjde mig med ett till att börja med, Applikationen utför sitt syfte visserligen men mycket av användarupplevelsen tappades med det beslutet. Statistiken hade involverat ännu ett ramverk att sätta sig in i i kombination med Core Data Framework, den risken kunde jag inte ta med tanke på var jag befann mig i projektet när datalagringen fungerande. Jag är trots allt inte besviken över att min applikationen inte träffade mitt i prick på utsatt mål, jag visste om risken när jag valde Objective-C och ios, även om jag hoppades att lyckas implementera allt. Applikationen bör byggas om från grunden för att vara i ett skick att accepteras av Apple. Frågan återstår nu om jag kommer göra det, Det verkar för mig som att nyckeln till att behärska Objective-C är att ta några steg tillbaka och producera mindre applikationer som endast är beroende av en dataklass och har endast ett mindre syfte att fylla. Jag är snarare inspirerade att gå tillbaka, lära mig mer, och återkomma och göra en kraftfullare applikationen än vad denna skulle bli.