Genvejsmenu:
S - Indhold
1 - Forside
2 - Aktuelt
3 - Oversigt
4 - Søg

Sorter efter emne

21.10.11   |   kl. 08:13   |   Aktuelt, Prosabladet, Cross-platforme

Accedo droppede frameworket og udviklede native apps

Accedo satsede på tredjepartsframework til sin første mobile løsning. Drømmen om at genbruge udviklernes kompetencer og spare tid endte i masser af frustrationer og en beslutning om i stedet at udvikle native apps.

Michael Lykke, udvikler hos Accedo, slap for mange bekymringer, da han droppede tredjepartsframeworket og udviklede native apps til den mobile løsning. Foto: Søren Holm/Chili.

For et år siden, da Accedo i Aarhus skulle i gang med sin første mobile løsning til en eksisterende webkunde, erhvervsejendomsmæglerkæden Colliers, gav beslutningen rigtig god mening. Ved at anvende et tredjepartsframework til at udvikle en app til både iPhone og Android kunne man bruge de eksisterende kompetencer i huset og dermed spare tid og udgifter til efteruddannelse eller nyansættelser. Michael Lykke er udvikler hos Accedo, der i alt har 10 medarbejdere.

– Vi er i høj grad et PHP-hus og havde ikke de store C- og Java-kompetencer. Det er jo de færreste mennesker i webbranchen, der har lyst til at gå tilbage til at kode i C og skulle forholde sig til memoryhåndtering og den slags ting. Så ved at anvende et framework regnede vi med at kunne genbruge alle vores webteknologikompetencer inden for JavaScript, HTML og så videre, fortæller han.

Accedo havde efter en grundig undersøgelse af de forskellige muligheder valgt at bruge Appcelerator Titanium, fordi det benytter sig af JavaScript og indeholder en mængde wrappers, der kan kalde native controls. Man havde bevidst valgt de frameworks fra, der reelt ville resultere i en HTML-baseret app.

Fokus på brugeroplevelsen

Bag beslutningen om at udvikle en app frem for eksempelvis en mobiloptimeret webløsning lå der flere overvejelser. Kunden ønskede at nå en bestemt målgruppe, og med en app kunne man gå efter den optimale brugeroplevelse samt udnytte den markedsføringsmulighed, der ligger i app storen.

I begyndelsen af udviklingsforløbet så det lovende ud. Inden for en dags tid havde man fået flere elementer på plads, men snart begyndte virkeligheden at melde sig.

– Det viste sig, at der var rigtig mange fejl i frameworket. Det gjaldt både det værktøj, som står for 'kompileringen' til den specifikke platform, og det resultat, der kom ud af det. Og det kostede os rigtig meget tid. Specielt i forhold til Android var der meget store problemer, fortæller Michael Lykke.

Der kom andre udfordringer i løbet af udviklingsprocessen.

– Vi går meget op i, at brugeroplevelsen er helt i top. Men det viste sig for eksempel, at der var performanceproblemer selv på simple operationer som swipe, hvor app'en hakkede i det. Også i forbindelse med kortvisning rendte vi ind i performanceproblemer, hvis der skulle vises over 50 lokationer. Dertil kom, at det i flere tilfælde var svært eller umuligt at foretage forholdsvis enkle ændringer, hvis for eksempel kunden ønskede en anden farve i en bar, fortæller Michael Lykke.

Sled på den faglige stolthed

Han følte, at der efterhånden blev slidt noget på hans faglige stolthed – både når resultatet ikke levede op til hans ambitioner med hensyn til brugeroplevelsen, og når han endnu en gang skulle bede om udsættelse af en intern deadline på grund af uforudsete problemer.

– Jeg er helt på det rene med, at der kan være bugs i tidlige versioner af noget software. Og vi var heller ikke så naive at tro, at man blot udfører en kommando, og så får man genereret helt fejlfrie resultater på flere forskellige platforme. Men efter at have prøvet flere nyere versioner af frameworket, uden at det havde ændret noget væsentligt ved situationen, var det på tide at tage en kraftig beslutning, siger Michael Lykke.

Beslutning om native apps

Det havde i nogen tid været en stående joke i huset, at "det er garanteret hurtigere at lave to native versioner". Joken blev til en nødvendig beslutning, og så var spørgsmålet, hvordan man fik tilført de nødvendige kompetencer – hurtigst muligt. Michael Lykke undersøgte forskellige kursustilbud, men det endte med en lille uges meget målrettet hands-on-undervisning til de to Accedo-udviklere, der skulle lave iPhone-app'en. Underviseren var en udvikler med praktisk erfaring fra udvikling til iPhonen, og det var det helt rigtige i den situation, man stod i.

– Det gav os sindssygt meget. Vi havde jo meget af den teoretiske viden på forhånd, så det var det helt rigtige med det samme at kaste os over kodningen, siger Michael Lykke.

Selvom der skulle bruges tid på at lære nye teknologier, endte Michael og kollegerne med at udvikle en native iPhone-app hurtigere, end det havde taget at nå 80-90 procent i mål ved hjælp af tredjepartsframeworket.

Det blev besluttet at lægge udviklingen af Android-versionen ud af huset.

– For den enkelte udvikler kan det blive for meget at skulle holde styr på to forskellige teknologier, platforme og sprog på samme tid. Så også efterfølgende har vi valgt først at udvikle iPhone-versionen og så være projektledere på udviklingen af Android-versionen. På det tidspunkt i udviklingsforløbet har vi jo taget alle designbeslutningerne og defineret forretningslogikken, så det drejer sig 'kun' om selve kodningen, afslutter Michael Lykke.

PRINT

Kommentarer

Der er endnu ikke skrevet kommentarer til artiklen

God tone i debatten

Deltag i debatten

CAPTCHA billede for SPAM beskyttelse

Relevante links