Skal du lage en mobilapplikasjon som fungerer på både Android og iOS, må du i utgangspunktet lage to separate applikasjoner: En for Android og en for iOS. Xamarin lar deg utvikle apper for flere plattformer samtidig.
Har du noen gang lånt telefonen til en venn og følt deg litt lost? Det er du ikke alene om. Både Apple og Google har utviklet sine egne retningslinjer for hvordan de ønsker at apper på plattformene sine skal se ut og fungere. Google mener at deres Material Design er den perfekte måten å utforme en app på, mens Apple beskriver sin perfekte verden via Human Interface Guidelines. På samme måte har de tatt ulike valg på teknologifronten. Både programmeringsspråket og selve tankesettet rundt hvordan man på best mulig måte bygger en applikasjon rent teknisk, er vidt forskjellig. Skal man lage en mobilapplikasjon som fungerer på både Android og iOS må man i utgangspunktet lage to separate applikasjoner: En for Android og en for iOS.
Hvis man ser bort fra det overfladiske: Hvordan du navigerer deg gjennom appen eller utseendet på for eksempel knapper og datovelgere, så gjør jo en gitt app det samme enten den er på en iPhone eller en Android-telefon.
La oss se på et eksempel: E-post-klienten på telefonen vår. Utseendet på menyen, knapper og hvordan navigasjonen fungerer klassifiseres som UI (User Interface), eller brukergrensesnitt på norsk. I tillegg til UI har vi “business”-logikken. Denne logikken består av datamodeller som definerer hva en e-post er, at en e-post har en avsender, en mottaker, innhold, lest-status osv. Den vil også ha ansvaret for å håndtere kommunikasjon mot en server for å sørge for at e-poster blir sendt, mottatt, markert som lest, eller rapportert som spam. Business-logikken vil som oftest være helt lik på begge plattformene, sett bort fra at den er skrevet i forskjellige kodespråk.
Ifølge Microsoft utgjør business-logikken i snitt ca. 75 % av koden i en app, som betyr at vi som utvikler appen altså må gjenta 75 % av koden vi allerede har skrevet for en Android-app i et nytt språk for å gjøre den samme appen tilgjengelig på iOS.
Ulempene med dette er mange, ikke bare fordi det må brukes ekstra tid og ressurser på å gjenta kode, men fordi koden skal også vedlikeholdes. Både feilrettinger og ny funksjonalitet må derfor også implementeres to steder.
Denne problemstillingen har gitt liv til en rekke rammeverk for å dele kode mellom plattformene. Mange av disse benytter seg av web-teknologi som HTML, CSS og JavaScript for å tillate utvikleren å bygge appen mer eller mindre som en nettside. Det gjør at antall kodespråk utvikleren på ha kjennskap til reduseres vesentlig og man kan oppnå opp mot 100 % delt kode for de enkleste applikasjonene. Men ofte på bekostning av både ytelse, størrelse på app og tilgang på native funksjonalitet som sensorer. Et UI bygget i HTML og CSS vil i likhet med en nettside ofte bli lik på begge plattformer, og ikke ha et native utseende slik man gjerne forventer i en app. Det er her Xamarin kommer inn i bildet.
Xamarin er et rammeverk som lar deg utvikle apper for flere plattformer samtidig, og skiller seg fra de andre alternativene ved å la utvikleren implementere business-logikken én gang og heller skrive UI-koden hver for seg. Business-logikken skrives i kodespråket C# og kompileres ned til native koden før det kjører på telefonen. Dette gir oss en app med et native utseende og langt bedre ytelse enn ved bruk av javascript.
Selv om Microsoft uttaler at Xamarin har “Native performance”, så er dette litt unøyaktig. Koden som kjører på telefonen er kompilert til native kode, men for at koden som er skrevet i C# skal kunne kjøre på andre telefoner må vi pakke med litt ekstra funksjonalitet i appen vår. Blant annet logikk for minnehåndtering og for å støtte all annen funksjonalitet som er innebygget i språket. Dette gjør at appen ofte blir litt større enn en 100 % native app, og gjerne må kjøre litt ekstra kode som tar litt ekstra tid. Dette er snakk om millisekunder og noe en sluttbruker ikke vil legge merke til i en enkel applikasjon. Ytelsestap som følge av dårlig skrevet kode vil ofte utgjøre langt større ytelsestap enn bruk av C# over Androids native språk Java.
Selv om mye av koden vår er den samme for begge appene vil vi av og til måtte bruke innebygd funksjonalitet på telefonen. Det kan for eksempel være å åpne kameraet for å ta et bilde, eller for å lage en varsling med lyd for å gi beskjed om at du har fått en ny e-post. Dette er funksjoner som er bygget inn i telefonens operativsystem og er laget for å kalles fra programmeringsspråkene som brukes til native utvikling.
I Xamarin må vi fortsatt skille på hvordan vi lager en varsling på telefonen da dette ikke er likt på iOS og Android, men vi kan gjøre alt fra den delte koden vår. Xamarin inneholder en del oversettelser som gjør det mulig å kalle all denne funksjonaliteten i operativsystemet fra den delte koden, til tross for at vi bruker et annet språk. Det betyr at alt vi kan gjøre i en native app, kan vi også gjøre i Xamarin.
I 2015 ble Xamarin.Forms lansert. Det er et bibliotek som lar utvikleren også skrive UI-koden én gang for begge appene. Selve tanken med at UI skal være at native er beholdt da Xamarin forms oversetter den delte koden til native UI-komponenter. Hver plattform har egne rendrere for de ulike komponentene (som knapper, tekst etc.), som gjør at den ferdig genererte UI-koden får et native utseende og oppførsel, selv om den er basert på den samme oppskriften.
For de enkleste applikasjonene vil dette bety opp mot 100% delt kode i tillegg til at utvikleren kun trenger å sette seg inn i to språk: C# og XAML. Dette forutsetter at brukergrensesnittet ikke krever for store tilpasninger ettersom Xamarin.Forms har en litt begrenset verktøykasse i forhold til det man vanligvis har når man skriver native UI-kode.
Når Xamarin Forms ikke tillater de tilpasningene vi ønsker å gjøre, så må vi lage støtte for det selv. For eksempel finnes det ingen innebygget støtte for underline på tekst. Om vi ønsker dette er vi nødt til å implementere en egen renderer for hver plattform. Dette er ikke noen stor oppgave, men om vi ønsker å gjøre mange slike tilpasninger vil det være enklere å skrive native UI.
Det å generere native UI fra en felles kodebase er dessverre ikke gratis med tanke på ytelse. Xamarin.Forms fungerer som et lag mellom utvikleren og den native koden, som vil si at UI-koden man skriver for Xamarin.Forms til slutt blir oversatt til native UI når appen kjører. Vi introduserer med andre ord et mellomlag som både krever mer lagringsplass og prosesseringskraft for å generere native UI når appen kjører.
Det er vanskelig å argumentere for at bruk av Xamarin eller lignende rammeverk vil gi deg en bedre app enn ved native utvikling. Native utvikling vil sannsynligvis gi deg det beste resultatet i form av ytelse og størrelse på appen, gitt at utvikleren behersker språket som brukes. For et utviklerteam som allerede har kjennskap til C# og .NET vil Xamarin være et godt alternativ. Ikke bare kan man nærmest halvere jobben med å utvikle to apper, men man kan også bruke kompetansen man allerede har til å lage apper for nye plattformer. Dette åpner også opp muligheter for et mindre utviklerteam siden vi ikke trenger like bred kompetanse i flere ulike språk og rammeverk.
For de fleste appene jeg har jobbet med har jeg i stor grad brukt komponentene som er tilgjengelige i Xamarin.Forms med unntak av noen få tilpasninger. I tillegg til å nærmest halvere jobben med å utvikle applikasjonen slipper jeg å lære meg Swift, Java, AXML og bruk av storyboard-designeren til Apple. Ikke bare oppnår vi delt kode mellom appene, men i flere tilfeller har vi også brukt deler av samme business-logikk, også på serveren siden vi bruker samme språk der. Native utvikling vil fortsatt være det beste valget for en del prosjekter, men for mange team – spesielt de mindre og de som allerede kjenner teknologien – vil Xamarin være et veldig godt alternativ.