Diskussion kring Xamarin

Till att börja med måste nämnas att Xamarin är under ständig utveckling och funktioner som inte funnits tillgängliga under appens utveckling skulle mycket väl kunna vara under utveckling och finnas tillgängliga i framtiden [Jas; Staa]. Till exempel introducerades Xa-marin.Forms i samband med släppet av Xamarin 3 bara tre månader innan projektet drog igång [Fri].

Den övergripande upplevelsen har under projektets gång varit att Xamarin är ett verk-tyg med vilket man kan spara både tid och resurser när man utvecklar för fler plattformar genom att bara behöva skriva stora delar av koden en gång, istället för två eller tre, men att man noga bör planera i vilken utsträckning Xamarin används och vilka funktioner man vill nyttja för inte hamna i en situation där tiden man förväntas spara på att använda Xamarin går åt till att lösa oväntade svårigheter.

Efter att ha använt Xamarin i projektet har både fördelar och nackdelar med att

an-vända Xamarin blivit tydliga, även om fördelarna, åtmistone för författaren, varit fler. De största fördelarna är den enhetlighet och överblick man får över sitt projekt. Istället för att använda tre olika språk och tre olika utvecklingsmiljöer för att utveckla samma app för de populäraste mobila plattformarna kan man ha hela sitt projekt i Visual Studio, eller Xamarin Studio, och skriva all kod i C#. Det gör inte bara utvecklingen av appen mer översiktligt, man slipper undan mycket redundans även i underhållet när man bara har en kodbas att uppdatera. Om användandet av just C# som programspråk är en fördel eller ej lämnas osagt, men C# är ett av de populäraste programspråken [tio; Cas] och bör således ha en stor skara användare. C# är dessutom ett rent objektorienterat språk, och är väldigt likt bland annat Java [Kir]. Det bör således vara enkelt att lära sig om man sedan innan har kunskap om objektorienterade språk.

Dokumentationen är en annan av Xamarins starka sidor [Incx]. Nästan allting som går att använda i Xamarin har någon form av guide [Incm] och det finns hundratals exempel [Stab] att hämta inspiration och idéer ifrån. Om man inte skulle hitta det man behöver i Xamarins officiella dokumenation finns det gott om tredjepartskällor där man kan hitta exempel och även utökade bibliotek [autd; auta; autc]

Efter att appens användargränssnitt skrivits med Xamarin.Forms, den verktygslåda Xamarin erbjuder för att skriva gränssnittskod som går att dela mellan plattformar, har både fördelar och nackdelar med att använda denna upptäckts. Med Xamarin.Forms kan man gå ytterligare ett steg mot att fullständigt dela kod mellan plattformar, där man tidigare behövt skriva plattformsspecifik gränssnittskod kan man nu dela även denna mellan Android, iOS och Windows Phone [Incc]. Detta ger förstås samma fördelar som delandet av övrig kod ger, mer överblick och mindre att underhålla. Att Xamarin.Forms kan skrivas med både XAML, Microsofts XML-baserade deklarativa markup-språk utvecklat för just grafiska gränssnitt [Micd; Micg], och C# ger möjlighet att välja det man är mest bekväm med. Men här finns också den första nackdelen med Xamarin.Forms. Har man tidigare utvecklat appar för .NET-Ramverket och använt XAML för att koda gränssnitt är chansen

stor att man är van vid Microsofts IntelliSense [Micc], det verktyg som i Visual Studio hjälper utvecklaren att skriva kod genom att exempelvis föreslå hur ett påbörjat ord ska avslutas eller vilka egenskaper olika objekt har. Utan IntelliSense krävs att man utantill har kunskap om alla objekt som kan läggas till i ett gränssnitt och alla egenskaper de besitter för att kunna anpassa gränssnittet som man vill, eller att man helt enkelt tar reda på allt man behöver veta genom att läsa dokumentationen. IntelliSense kan säkert anses vara en bekväm lyx, men är i det här fallet klart saknad. Att IntelliSense saknas verkar bero på tekniska barriärer, något som man på Xamarin jobbar på att lösa [Jas]. Tills vidare har det under projektets gång introducerats en lösning som utvecklarna på Xamarin utvecklat utanför arbetstid [Dan] och som finns att ladda ner som ett fristående tillägg till Visual Studio sedan mitten av oktober [autb] och tillhandahåller IntelliSense för Xamarin.Forms.

Att Xamarin.Forms är omfattande råder ingen tvekan om, det innehåller alla de vanliga gränssnittskontroller som finns över de tre plattformarna och har stora anpassningsmöj-ligheter [Incy]. Men det finns kontroller som saknar viktig funktionalitet. Kartan, som använts i appen, har visat sig vara en sådan. Kartan som Xamarin.Forms erbjuder är bara ett kartelement som kan ritas ut, och sedan kan fasta kartnålar fästas på kartan via kod.

Något som appen krävde var att kartan skulle vara interaktiv och kunna rita ut linjer för att representera rutter, något som nuvarande version av Xamarin.Forms.Maps inte klarar [Incv]. Att kontroller saknar funktionalitet innebär dock inte att de inte går att använda.

Xamarin erbjuder en möjlighet att plocka upp den saknade funktionaliteten från underlig-gande plattformsspecifika API:er [Incj]. Vid kompilering mappas Xamarin.Forms-kod mot de kontroller som finns i det API som appen kompileras för. Alltså, om appen kompile-ras för Android mappas Xamarin.Forms.Maps mot Googles kart-API. Som utvecklare har man möjligheten att skriva ett par klasser, en Custom Renderer och en klass som ärver den kontroll man vill använda, i det här fallet Maps. Man kan sedan via Custom Render-klassen lyfta upp funktionalitet till sin nya anpassade klass av Maps och använda denna klass när man lägger ut sin karta i appen, istället för den befintliga. Detta måste göras för

varje plattform för sig och man kommer således ifrån själva syftet med att använda Xama-rin.Forms från början - möjligheten att dela kod. Det kräver dessutom att man sätter sig in hur dessa funktioner fungerar för alla plattformar man vill att de ska fungera för, och kan kosta en del tid.

En sista avsaknad av funktionalitet för plattformsöverskridande utveckling var möjlig-heten att ta fram en geografisk plats med hjälp av telefonens GPS. Det finns möjlighet att göra detta för varje specifik plattform [Incn], men att dela sådan kod går inte. Detta verkar bero dels på hur olika detta fungerar över plattformarna och även över olika enheter. Vill man lösa detta får man skriva kod specifikt för den plattform det gäller [Incq], eller använda någon av de fristående lösningar som tillahandahålls. Xamarin utvecklar själva alternativet Xamarin Mobile [Incb], och dessutom finns tredjepartslösningar som Xamarin.Forms.Labs [autd] och ACR [auta].

Sammanfattningsvis har fördelarna med Xamarin övervägt nackdelarna. Med Xamarin var det möjligt att utveckla PaddelAppen för två¹ olika plattformar med ett gemensamt programspråk och att dessutom kunna dela upp til 90% av all kod [Incp] är en källa till ökad effektivitet och öppnar också möjligheter för den som tidigare inte haft kunskap att utveckla för någon av plattformarna. Att det dessutom finns en stor skara utvecklare både bakom Xamarin men också bland användarna som skapar fristående API:er och bidrar med öppen källkod ökar potentialen ytterligare.