Xamarin på tvers

Ved utvikling på tvers av plattformer får man fort spagettikode fra UI-laget og frem til webtjenestelaget. Kan Xamarin være en løsning på dette problemet og samtidig gi veiledende arkitektur?

Hvis du kombinerer dette med et stort forretningslag og flere ulike apper med samme funksjonalitet på ulike språk og plattformer kan utviklingsprosjektene bli lange og gjøre vedlikeholdsarbeidet til et mareritt.

Jeg har benyttet rammeverket Xamarin i denne type prosjekter. Her er noen av mine erfaringer hva gjelder valg av rammeverk for et mobilutviklingsprosjekt og hvordan Xamarin spesifikt kan brukes til å dele kode på tvers av plattformer.

mono Xamarin på tversHva er Xamarin

Xamarin er et rammeverk som bygger på Mono. Dette er et rammeverk for å utvikle applikasjoner (apps) for iOS, Android, Windows og Mac. Idéen som førte frem til lansering av et open-source mono prosjekt i 2001 var å kunne skrive og kompilere C#/.NET uten å nødvendigvis måtte bruke en Windows maskin. Xamarin tok dette prosjektet et steg videre i desember 2012 med utgivelsen av Xamarin.Mac som gjorde det mulig å bygge C# baserte applikasjoner for OSX og publisere dem på Apples App Store. Utgivelsen av versjon 2.0 i februar 2013 inkluderte et utviklingsverktøy for iOS, Android og OSX. Dette verktøyet er da Xamarin Studio. Versjon 2.0 utmerket seg også ved å gi full integrasjon mot Visual Studio.

Det er ingen hemmelighet at målgruppen til Xamarin er C#/.NET-utviklere som ønsker å utvikle apps på andre plattformer og appbutikker enn Windows Marketplace og Windows Store. Dokumentasjonen på Xamarins nettside er stort sett rettet mot .NET utviklere, men med noen få unntak, deriblant en begynnerguide for iOS utviklere. Når det er sagt, så finnes det fascinerende muligheter for utviklere generelt som ønsker å utvikle sine apper på tvers av plattformer. Disse mulighetene kommer vi tilbake til.

Hva er alternativene?

Det er viktig å legge til at utvikling på tvers av plattformer teknisk sett kan gjøres på flere forskjellige måter, skille mellom disse er viktig for å kunne gi råd og hjelpe våre kunder å velge riktig verktøy for jobben. Xamarin kompilerer C# koden til native apper, men annen metode for deling av kode på tvers av plattform er å dele biblioteker. Bibliotekene som deles vil eksempelvis være i C++. Binding mot C++ gjøres da fra Objective C++ på iOS og JNI C på Android. Enda en metode for deling på tvers av plattform er å utvikle apps i HTML, CSS og JavaScript sammen med produkter som Sencha Touch, Cordova, Titanium SDK, og Phone Gap, som igjen kan kombineres med populære rammeverk som AngularJS.

build diagram Xamarin på tversPhone Gap sin metode for utvikling på tvers av plattformer

Dessuten bør det ikke være utenkelig at en mobilvennlig responsiv nettside i mange tilfeller er godt nok for kunden. «Mobile First» tankegangen i form av responsiv design har gått fra å være en eksklusiv vare til en standard i måten webutvikling utføres. Unity bør også vurderes dersom det er et spill som skal utvikles med relativt omfattende grafikk i 2D eller 3D på flere plattformer.

Avgjørende faktorer for valg av rammeverk

Parametere som bør vurderes ved rådgivning relatert til utvikling av apps kan oppsummeres med følgende spørsmål:

  • Skal appen utgis på flere plattformer samtidig?
    Dersom utviklingsløpet er på tvers av flere plattformer og målet er å gi ut til for eksempel App Store og Google Play samtidig, da kan det tenkes at rammeverk for deling av kode gir en fordel i utviklingsløpet. Da under antakelsen om at forretningslaget er av betydelig størrelse.
  • Er ytelsen avgjørende?
    Native apps vil ha fordelen av å kunne snakke med maskinvaren uten å gå gjennom flere abstraksjonslag, som vil påvirke brukeropplevelsen. Er det viktig at applikasjonen bruker operativsystemet nyeste funksjonalitet samt at opplevelsen av navigasjonen(UX) er flytende og raskt når det gjelder respons til brukerens input? Da bør native app vurderes, og vil sannsynligvis være svaret. Native apper har også fordelen av å kunne øke ytelsen med Multitasking i form av flere tråder på ulike CPU-kjerner.
  • Er utviklingsbudsjettet stramt?
    Et utviklingsløp hvor mengden kode blir redusert pga. gjenbruk av kode vil kunne redusere utviklingsprisen betraktelig, men ikke i alle tilfeller. Apper hvor brukergrensesnittet skal være ulikt basert på plattform og funksjonaliteten skal variere basert på plattform vil da redusere gjenbrukbarheten på tvers av plattformene.
  • Skal brukergrensesnittet være unikt for hver plattform?
    Hvorvidt det er nødvendig å følge plattformens design er et stort emne i seg selv. En fordel med å bruke plattformens UI-spesifikke kontrollere og design prinsipper kan være kortere tilvenningstid for brukeren. På den andre siden så bør en ikke undervurdere hvor intuitivt et tilpasset design kan være for en app med et unikt design. Dette gjøres ved å lage et design som reflekterer appens funksjonalitet, og da ikke nødvendigvis med upopulære metoder som skeuomorfisme. Apples user experience guidelines (HIG) har unntak for «immersive apps». Dette handler om å skille mellom apper som skal fungere som verktøy kontra de som skal gi en opplevelse. Grafikktunge mobilspill havner ofte innenfor kategorien «immersive apps».

Det er mange andre spørsmål en burde stille seg før en velger et rammeverk eller i det hele tatt bestemmer seg for å utvikle på tvers av plattformer. Dersom en for enkelhet skyld begrenser avgjørelsen til spørsmålene ovenfor, så vil en kunne si at Xamarin tilfredsstiller og passer godt i et scenario der kunden svarer ja på alle nevnte spørsmål. Med et unntak på det siste spørsmålet, dersom forretningslaget ikke er av betydelig størrelse.

Hvordan dele kode på tvers av plattformer i Xamarin?

I Xamarin gjøres deling av kode på flere måter. Den nyeste måten å gjøre det på er å ta i bruk Portable Class Library støtten som kom ut i november 2013. PCL-biblioteker lar deg velge minste felles multiplum og sørger for at .NET versjonen innenfor biblioteket og bruken av andre biblioteker innenfor PCL-biblioteket støttes av valgte plattformer og rammeverk.studio Xamarin på tvers

PCL – Visual Studio. PCL – Xamarin Studio

Når en begynner å skrive kode i PCL-biblioteket og følgers begrensingene kan en være sikker på at dette vil kunne kompilere og kjøre på de valgte plattformene. Dette blir da naturligvis stedet hvor en utvikler et forretningslag, datatilgangslag og tjenestelaget med integrasjon mot webtjenester. Et annet godt eksempel vil da være relatert til et vilkårlig mobilspill. En vil da sørge for å ha den kunstige intelligensen, flerspillerdelen som aksesserer webtjenester, og spillets regler i et eller flere PCL prosjekter/biblioteker, slik at denne koden kan gjenbrukes på de ulike UI-prosjektene. Videre vil en rutinert utvikler se muligheten for å sette opp testprosjekter for å kunne verifisere at PCL bibliotekene oppfører seg som forventet. En kan da notere seg at testingen av denne koden vil gjelde for alle plattformer.

Delingen av kode stopper ikke nødvendigvis på forretningslaget. Det kan også gjøres helt frem til View-kontrollere. For utviklere som er komfortable med to-veis databindinger, så er «patterns» som MVVM nyttige for å holde orden på front-end arkitekturen. I Xamarin bruker en MvvmCross for å implementere to-veis databinding og for å ha løskoblet kode mellom modellen, View og View- kontrolleren. Fordelen vil da ikke kun være strukturert kode som følger MVVM kodemønsteret, men også gjenbrukbar kode på tvers av plattformene.

IC448690 Xamarin på tvers

Enda en spennende mulighet for deling av kode i Xamarin benyttes ved å ta i bruk komponenter i Xamarin Store. Xamarin Studio har Xamarin Store integrert hvor en har muligheten til å benytte seg av flere velfungerende komponenter, som stort sett kan brukes på tvers av iOS og Android. Komponentene er ofte godt dokumentert sammen med kildekodeeksempler. Eksempler på gode komponenter er følgende. Azure Mobile Services, Xamarin.Social, Xamarin.Mobile, SimpleStorage, Google Analytics, Google Maps og Json.NET. Alle nevnte komponenter er gratis, men det finnes også komponenter som Infragistics NucliOS med pris på $995.00.

Nedenfor følger et eksempel på hvordan en tar i bruk Xamarin.Social for å poste på brukerens Facebook side. Brukeren vil i dette tilfellet bli spurt om å tillatte facebook appen å poste på vedkommende sin side. Dette vil fungere både på iOS og Android. Merk #IF… direktiv som forteller kompilatoren hvilken plattform koden tilhører. Dette brukes i tilfeller der en ønsker at samme fil skal fungere på de ulike UI, som da ikke er nødvendig om en koder i et PCL-prosjekt. I dette tilfellet er ikke Xamarin.Social biblioteket PCL-kompatibelt, så en ønsker da å lenke inn en fil i både iOS og Android prosjektet, og fortelle kompilatoren hva som skal tas med til hvilken plattform.


Eksempelet i seg selv er kanskje ikke tidsbesparende, men hvis en tenker seg at appens forretningslogikk også skal flettes inn ved de ulike resultater av delingen og at komponenten skal gjenbrukes flere steder i appene, da vil potensielle feilkilder reduseres og gjenbrukbarheten til koden øke.

UI spesifikk kode i Xamarin

Dersom en allerede er kjent med Xcode på iOS og bruker vanligvis Storyboard til å tegne UI delen av appen, så vil en kunne fortsette å gjøre det med Xamarin. Det er nemlig slik at en kan bruke Xcode til å tegne UI, men å gjøre selve kodingen og bruken av UI (Outlets og Actions) i Xamarin Studio, eller Visual Studio. Samspillet mellom Xcode og Xamarin Studio har vist seg å være til tider uheldig, og kan med dagens standard ikke sies å være perfekt. Dette uheldige samspillet kan gjøre at en må tvinge Xamarin Studio å synkronisere, noe som i utgangspunktet burde være automatisk og feilfritt. Et alternativ er å bruke Xamarin Studio sin egen «Interface Builder», merk at denne er foreløpig kun i beta.

Når det gjelder Android, så har de et XML-basert UI. XML gjør det enklere å forholde seg til gjennom Xamarin uansett plattform. Her finnes det en editor i Xamarin Studio som gjør det enkelt å tegne opp UI. Dessuten så finnes det også en programvareutvidelse til Visual Studio med samme funksjonalitet.

Noen erfarne iOS utviklere foretrekker å kode UI manuelt uten å forholde seg til Storyboard. I tilfeller hvor unike UI kontrollere skal lages, kan det være en fordel å tegne disse med vektor grafikk. PaintCode kan generere både Objective-C og C# kode ut av vektorgrafikk. PaintCode vil en da også kunne bruke sammen med Xamarin, og da med C# koden PaintCode generer i stedet for Objective-C. Dette fører oss til en sentral del av hvordan Xamarin er laget og fungerer på UI delen. Når en skriver kode i C# for iOS sitt UI, så bruker en del av mono som heter monotouch. Her vil en finne API-et som snakker med iOS maskinvare. Monotouch er da i all hovedsak en tynt lag på toppen av Cocoa Touch. Det vil si at Xamarin bruker de samme komponentene og tilslutt kaller på den samme koden som native iOS app skrevet med Objective-C.

Et eksempel på likheten på koden er vist nedenfor. Den første kodesnutten er skrevet i C#/monotouch og nøyaktig samme funksjonalitet er på kodesnutten nedenfor i Objective-C.

Kostnad

Å utvikle i Xamarin for bedrifter er ikke gratis. Business lisensen koster $999.00. Lisenser kjøpes per utvikler og plattform med en varighet på et år. Det kan også nevnes at Xamarin gir god support til utviklere med business lisenser, men skal en ha tjenestenivåavtale (SLA) så må en betale for en Entreprise lisens på $1899.00.

Min erfaring

Xamarin kan være et alternativ dersom deling av kode på tvers av plattformer er en viktig del av utviklingsprosjektet, og da vanligvis gjennom et omfattende forretningslag og/eller stort integrasjonslag mot webtjenester. En annen viktig fordel med utvikling på tvers av plattformer er å kunne involvere de samme menneskene og da unngå kompetanseoverføring fra plattform til plattform.

Apper bygget i Xamarin er native apper, som vil da ikke være et alternativ om løsningen/prosjektet er bedre egnet for web apper. En native app utviklet med Xcode bør også være å foretrekke dersom kunden ikke har publiseringsplaner på de andre plattformene, eller ønsker å ha ulike apper uten samspill mellom plattformene. Xamarin har også sine begrensinger, og en vil potensielt ikke jobbe med nyeste versjon av iOS eller Android. Så langt har Xamarin klart å følge dette opp godt og ga ut iOS 7.0 støtten på utgivelsesdatoen til iOS7.0. Det er likevel merkbart at en ved bruk av Xamarin befinner seg et abstraksjonslag bak den utførende koden. Bruken av eksisterende biblioteker i Objective-C vil en måtte «wrappe» og lage bindinger til. Dette gir potensielle utfordringer. Heldigvis for Xamarin-utviklere så vil en i mange tilfeller komme langt uten bruken av eksterne Objective-C biblioteker.

En ting er sikkert, det er en fordel å kjenne til de ulike rammeverkene slik at en kan finne og løse kundens utfordringer med riktig verktøy.

Publisert