Xamarin tapasztalatok

Szívesen. Az elmúlt hónapokban eléggé meghatározó elem volt a hétköznapokban. Már régóta a célkeresztemben volt, de ugyanígy nem akartam saját zsebre belevágni... Végül sikerült a munkahelyemen elérni hogy kipróbáljuk - nagyon csábító lehetőség arra, hogy a háromplatformos fejlesztések ne igényeljenek 4x annyi időt, mint egy platformra.

Röviden én a következőket vártam egyszerre tőle:
1) A C# miatt hatékonyabb fejlesztést, mint Obj-C-vel és Javaval.
2) Közös üzleti logikát és adatkezelést, ezáltal kevesebb (és tisztább) nettó kódmennyiséget.
3) Az előző két pont következtében konzisztens, jobb minőségű végeredményt.

---

Ugye az alapkoncepció az, hogy leképezik (szinte) a teljes Android és iOS API SDK-t .NET osztályokra és nyelvi elemekre - ennek a megvalósítása önmagában is zseniális -, adnak egy Mono runtime-ot (saját GC-vel és mindennel), illetve oda-vissza áthidalást a "natív" világba. (Idézőjelben, mert Androidon JNI-n keresztül beszél a Mono a Java világgal, iOS-en meg az AOT fordító összefordítja a kettőt. A folytatásban a "natív" szó alatt az "őshonos" környezetet értem; vö. Mono.)

Az SDK azonosságán felül a két platform sajátosságait is integrálták.
Például Androidon ugyanúgy kell kezelni a resource-okat, mint natívan: ugyanúgy szerveződnek a mappák a különböző konfigurációkhoz, centire ugyanolyan layout XML-ek vannak (bár .axml a kiterjesztésük, és példányosíthatóak .NET osztályok is), az R.java megfelelőjét az IDE automatikusan generálja; de ugyanúgy van AndroidManifest.xml is, csak megspékelve egy olyan könnyítéssel, hogy az osztályokra rakott attribútumokból magától is ki tudja generálni a toolchain.
iOS-en ugyanúgy vannak XIB-ek és Storyboardok (előbbihez az XCode-ot indítja be a Studio, utóbbit tudja házilag szerkeszteni), ugyanúgy kell Plist fájlokat szerkeszteni (bár az IDE segít), aláírásokkal mókázni.

A lényeg, hogy a C# nyelv ismerete nem mentesít az iOS és Android platformok alapos ismerete alól, ugyanis pontosan ugyanazt az életciklust, ugyanolyan struktúrákban, ugyanazokból az elemekből kell összerakni. És a Mac vásárlástól se, mert az iOS app projektekhez kell XCode.

Az első pontom ettől függetlenül szerintem teljesül. A teljes .NET 4.5 frameworkben, ami elérhető mindkét platformon, van bőven okosság: például a LINQ, az async Taskok és az await kulcsszó sokkal kifejezőbb és tömörebb, mint a natív lehetőségekkel szórakozni.
Az Objective-C-vel szemben különösen rikít, hogy mennyit számít a generikus osztályok léte és az, hogy minden típusbiztos (vö. nincsenek és semmi sem az). Nem véletlenül sarokpontok ezek a Swiftben.

---

Viszont a második ponttól kezd bonyolódni a történet. Nem sokáig maradtunk a natúr Xamarinnál, mert önmagában nagyon lábbalhajtós a fejlesztés. Kell egy jó framework.

Az MVVM architektúra és a data binding nagyon jól működik Windowson, jó lenne a két új platformon is ezeket használni, és megosztani a VM rétegig mindent a három platform között. Windows Phone/Store fejlesztésnél azelőtt MvvmLightot használtam, ez sajnos nem elég. Viszont nem is keresgéltem sokáig, az MvvmCross azonnal szembejött, és miután megfejtettük a lelkivilágát (meg a viewmodel-first gondolkodást), remekül bevált.

Az MvvmCross struktúrája miatt minden képernyőhöz tartozik egy VM (és ezek VM-ek navigálnak egymás között), a hozzájuk tartozó UIViewController / Activity (Fragment) / Page osztályok pedig név alapján kapcsolódnak össze. Maga az adatkötés WP alatt kb. ugyanúgy megy, mint eddig (XAML binding); Androidon a layout XML-ben saját XML attribútumokkal vagy a C# kódban; iOS-en pedig a UIViewController C# kódjában lehet többféleképpen is felsorolni, melyik VM property hova menjen és milyen konverziókon essen át.

A felállás a következő lett: minden modell osztály, üzleti logika, viewmodel egy PCL (Profile 78) projektben lakozik. Emellett van a három alkalmazásprojekt. Ha van valami platformfüggő szolgáltatás, arra vagy NuGetről vadásztunk egy plugint, vagy írtunk sajátot - a megfelelő implementációt meg az IoC konténer tolja be a platformfüggetlen modulnak.

Persze egy ekkora framework tele van meglepetésekkel és kezelendő akadályokkal. Elég sokat bújtuk a StackOverflow-t, a forráskódot, alkalmanként a Xamarin bug tracking rendszerét (sajnos futottunk ezen a szinten is lyukra, de más is, ezért hamar patchelték), sikerült átvergődni rajtuk.

Azért elég jó élmény, amikor mindhárom platform egyszerre mozdul és ugyanazt csinálja, még ha vizuálisan el is tér a három felület.

---

És akkor a harmadik ponttal visszatérek az eredeti kérdésre, a licencelésre.

- Az ingyenes verzió semmire se jó, pont. Az a 32KB IL kód korlát már arra is kevés, hogy a Xamarin példakódokat kipróbálja az ember... Nem is értem, mi ezzel a céljuk, több szót nem érdemel.

- Az Indie licenc, amit szeptemberben állítottak át éves díjról havi díjra, elég jó ár/érték aránnyal bír, hiszen már bármit le lehet vele fordítani, és az eredmény publikálható.

De azért vannak hiányosságai, amik a végeredmény minőségének a rovására mennek. Egyrészt a fejlesztést nagyon lassítja a Visual Studio támogatás elvétele - nem lehet egy gépen, egy IDE-vel mindhárom platformot kezelni, váltani kell a Mac és Windows között, és a VS-ben még külön szórakozni kell az iOS/Android projektek unloadolásával egy WP buildhez. Három platformon egyszerre refaktorálni is lehetetlen így...

A másik érvágás a continuous integration teljes hiánya. Csak a Xamarin Studion belül indítható build, így már automatizáltan fordítani is lehetetlen a projekteket, nemhogy teszteket futtatni rajtuk... Ez a négy fős csapattal folyamatos ütközésekhez és kiszámíthatatlan minőségi problémákhoz vezetett, amit lassan, intenzív erőfeszítésekkel tudtunk csak korrigálni.

Ettől függetlenül lehet vele dolgozni, privát/kiscsoportos használatra némi fogszívás mellett.

- A Business verzió az aduász, de nem egyszerű évi nettó 2000 dollárt kitermelni a két platformhoz. Az előző problémák megszűnnek, nem lesz ez az ad-hoc, garázs- és izzadtságszagú jellege a munkának.

Ezt csak azért tudom kijelenteni, mert a Trial mód ennek a szintnek felel meg azzal a megkötéssel, hogy az így készült buildek 24 óráig működnek, aztán nem indulnak el többet. Célszerű a Trialt jókor kezdeni és kimaxolni a hasznosságát.

Ha van a környezetben egyetemista, akkor a diákkedvezmény elég vonzó alternatíva lehet - tizedáron kaphatják meg a full Business csomagot egy évig.

- Az Enterprise-ról nem tudok nyilatkozni.

---

Remélem hasznos volt, ha van még kérdés, hozzászólásban válaszolok.