Egy kóddal mennek a Google Inbox mobilos és webes kliensei

A keresztplatformos fejlesztés a modern mobilos alkalmazások egyik legnagyobb kihívása. Hogyan lehet a releváns platformokra és a webre is elkészíteni egy szolgáltatás kimenetét úgy, hogy több, egymásnak is ellentmondó kritérium is megvalósuljon?

A Google most egy egészen egyedi utat próbált ki a nemrég indult Inbox fejlesztése során. Az Inbox nem új szolgáltatás, hanem egy új felhasználói felület a cég meglévő Gmail infrastruktúrájához, a fejlesztés legnagyobb része így nem is a szerveroldalt, hanem a webes és mobilos appot jelentette. Ahelyett azonban, hogy az androidos, az iOS-es és a webes csapat külön-külön elkészítette volna saját verzióját az alkalmazásból, egyetlen közös alkalmazás készült, amelyre csupán vékony platformspecifikus UI kerül. Ez önmagában még nem lenne újdonság, az már sokkal érdekesebb, hogy a Google a Javát használta a feladathoz.

^{Google Inbox az iPhone-on - Java akcióban.}

Ahhoz, hogy a keresztplatformos megközelítés működjön, előbb a tervezett alkalmazás feldarabolására volt szükség olyan elemekre, amelyek szükségszerűen natívak (a UI), és amelyek megoldhatóak a közös kóddal (a "model" és a "model-view-controller"). Ebben a felosztásban az Inbox egyedi funkcióit ("beszélgetések", emlékeztetők, névjegyek és címkék) megvalósító modulokhoz belső API-n keresztül kapcsolódik a felhasználói interfész rétege. Ez egyébként mára a mainstream filozófiává vált a keresztplatformos fejlesztés világában, ugyanezt támogatja szinte minden eszköz a Xamarintól PhoneGapig.

Javából mindent

Az androidos app készítése a legegyszerűbb: a Javában megírt adatmodellekhez a fejlesztők elkészítették a natív, már Material Design irányelveket követő alkalmazást - a futtatásról pedig a Dalvik illetve az új generációs ART futtatókörnyezet gondoskodik, további teendőre emiatt nincs szükség. Az iPhone-on azonban nem futtatható közvetlenül a Java kód, ebben a Google fejlesztése, a tavaly megnyitott forráskódú J2ObjC eszköz segít. Ez (nevéből sejtetően) Javából állít elő futtatható Objective-C kódot, amelyre az iOS-es fejlesztők ráépíthetik az Apple-ízlés szerint átszabott felhasználói felületet.

A Java-Objective-C váltás persze rengeteg izgalmas kérdést felvet, a legfontosabb megoldandó problémát az eltérő memóriakezelési filozófia jelentette. A Java szemétgyűjtése (garbage collection) nehezen párosítható az Objective-C-ben egy ideje működő ARC referenciaszámlálással. A J2ObjC ebben az Objective-C "autorelease pool" funkciójára támaszkodik, a normálisan szemétgyűjtéssel takarított objektumok memóriafoglalását így akkor üríti a rendszer, amikor ez a pool kiürül. Azt a Google is elismeri, hogy a megközelítéssel vannak problémák, az automatizált tesztrendszert azonban felkészítették az ebből eredő memóriaszivárgás gyors kiszűrésére.

^{(forrás: javaworld.com)}

Nyerd meg az 5 darab, 1000 eurós Craft konferenciajegy egyikét! A kétnapos, nemzetközi fejlesztői konferencia apropójából a HWSW kraftie nyereményjátékot indít.

A harmadik nagy platform, amit az Inbox megcéloz, az maga a web, amely szintén ugyanarról a Java kódbázisról fut, mint a két mobilapp. Ehhez a Google egy külső fejlesztést, a GWT-t hívta segítségül, amellyel a javás adatmodellek konvertálhatóak JavaScriptre. Természetesen a webapp szintén saját egyedi felületet kap, amelyet a webes frontend-csapat készít, a kliensoldalon a UI alatt futó kód azonban megegyezik az androidos és az iOS-es verzióval.

Nagyban bevált

A megközelítés előnye, hogy a közös kódbázissal és a moduláris felépítéssel a fejlesztés hosszabb távon nagyon hatékony tud lenni. Egyrészt tud gyorsulni a fejlesztés, az új funkciókat nem kell három különböző platformon implementálni, teszteli, debuggolni, bevezetni, ezt elegendő csak egyszer elvégezni. Emiatt a fejlesztés olcsóbb is.

A nagy kérdés természetesen, hogy a konvertált kód teljesítménye hogyan viszonyul a szakértő kézzel írt és optimalizált, egyedi kódéhoz. A sebesség természetesen nem ideális, de a visszalépés nem is túlságosan drámai - mondja a Google. Az Ars Technicának nyilatkozó Garrick Toubassi, az Inbox-csapat tagja elmondta, hogy rengeteg mérést végeztek a fejlesztés során, és jelentős különbséget nem tapasztaltak. A J2ObjC-vel előállított kód nagyjából azonos számú objektumot és hasonló objektumgráf-komplexitást hordoz, mint az eredeti, így sebességben sincs komoly különbség. Mivel nincs futás közben működő kompatibilitási réteg, a konverzió még a nyers kód szintjén lezajlik, ez alapvetően logikus.

A Google tehát bízik a J2ObjC-ben, annyira, hogy a következő generációs Gmail-felület, az Inbox fejlesztésének integrált részévé vált az eszköz. Ez mindenképp azt jelenti, hogy a projekt előrelátható időn belül komoly támogatást kap a cég részéről, így külső fejlesztők számára is érdekes alternatívát jelent a keresztplatformos fejlesztéshez.