Strategier för mobilutveckling på multipla plattformar

03 December 2014 // Christian Hilmersson

Idag var jag på ett föredrag på Rich Web Experience av Pratik Patel som handlade om olika strategier för utveckling och underhåll av mobil-appar på flera plattformar.

Pratik presenterade tre huvudspår.

1 Ren native-implementation

Att skriva en ren native-implementation för varje plattform som skall stödjas ger uppenbart fördelar i det att du som utvecklare har full kontroll på alla delar utan att nödvändigtvis behöva vara beroende av mjukvara från tredje part. Detta angrepps-sätt lämpar sig väl när prestandan är viktig, t.ex. vid applikationer som kräver avancerade GUIn, spelutvecking etc. Det är dock dyrt och kan leda till större risk för buggar då man har fler kodbaser att hantera.

Exempel: Ren Objective-C eller Java-implementation rakt mot IOS eller Android

Fördelar: 
	+ Absolut bästa prestandan
    + Möjlighet att anpassa snabbt vid OS-uppdateringar
    + Inga beroenden till utvecklare av mellanlager
Nackdelar:
	- Dyrt
    - Höga inlärningströsklar
    - Duplicering av kod
    - Större risk för fel
    - Långsam round-trip vid utveckling p.g.a. kompilering

2 Inbyggt mellanlager/tolk/kompilator

Det finns ramverk som möjliggör utveckling i andra språk än en specifik plattforms native-språk. Dessa ramverk lägger ett lager i din app ovanpå operativsystemet och ger åtkomst till native-funktionalitet på ett sätt som kan liknas vid Javas JNI. (JNI - Java Native Interface låter program skrivna i Java få tillång till underliggande native-funktionalitet.) Dessa ramverk bygger bland anant på skript-tolkning eller JIT/AOT-kompilering till respektive plattform.

Exempel: Titanium (JavaScript), Xamarin (C#)

Fördelar: 
	+ Nästan lika bra prestanda som native, Pratik berättade att
    	Appcelerator som gör Titanium räknar på ca 90-93% av native-
        prestanda för Titanium och prestandan skall enligt uppgift vara
        ytterligare några procent högre för Xamarin.
    + Möjlighet att koda i ett enda språk och välja ett språk som man redan
    	är van vid
    + Gemensam kodbas/Återanvändning av kod
    
Nackdelar: 
	- Låser sig till en viss produkt
    - Aningen långsammare uppdateringstakt vid nya OS-releaser
    - Lätt att glömma bort att man måste förstå målplattformen

Ytterligare en lösning som Pratik inte pratade om men som fungerar på liknande sätt är RoboVM som låter dig skriva IOS-appar i Java.

3 Web view/browser-baserade ramverk

Den sista strategin som Pratik talade om idag var den som de flesta förmodligen redan hört talas om för att dela kodbas mellan mobila plattformar, nämligen att köra sin applikation i en inbäddad webb-läsare med extra funktionalitet för åtkomst till native-funktionalitet. Detta alternativet har av uppenbara skäl blivit väldigt populärt bland webbutvecklare då inlärningströskeln blir väldigt låg om man redan utvecklar applikationer för webben. Nackdelen är att man tappar väldigt mycket av den prestanda som i en mobil enhet redan är relativt beränsad. Det är också lätt att glömma bort att man som utvecklare behöver känna till en hel del om hur de plattformar som man utvecklar för fungerar om man utvecklar för t.ex. PhoneGap. Med det sagt så finns det gånger då det lämpar sig väl med en lösning av detta slaget t.ex. i enklare affärs-applikationer utan höga krav på responsivitet i GUI:t.

Exempel: PhoneGap

Fördelar: 
	+ Låg inlärningströskel
    + Gemensam kodbas/Återanvändning av kod
    + Enkelt att hitta utvecklare som kan arbeta med koden
    + Billigt
    
Nackdelar:
	- Mycket lägre prestanda, ca 20-30% av native enligt Pratik.
    - Lätt att glömma bort att man måste förstå målplattformen
    - Ofta ganska dålig responsivitet i gränssnitten