Bár Andris ismét beelőzött, én letöltöttem az SDK-t, és fél éjszakán keresztül szórakoztam a Google J2ME-újraértelmezésével.

Android képek itt, a feliratokat kapcsoljátok be (bazinagy i betű az elején)

(alant meg hosszú cikk)

1. A Java védelmében

Nagyon fellélegeztem, amikor kiderült, a Google a Java-t választotta keretnyelvnek, és nem tisztán linuxos programokat akarnak írni, és nem feltétlenül azért, mert annyira szeretem a Java-t, hanem mert ezzel megmarad egy csomó előny, amit a Java nyújt, ugyanakkor talán egységesebb képet adva eltűnik a J2ME hátrányainak egy része, sőt… de erről még lesz szó. A másik lehetőség egyébként a python lett volna (a Google hivatalos nyelvei a C++, Python és a Java), ami egy szintén jó választás lett volna, csak nem tartanak ott az eszközök, hogy nagy terjesztéssel használni lehessen.

Ugyanakkor felmerül a kérdés: miért is Java?

Először a “Miért Java dehiszen az lassú” embereknek szeretnék tisztázni pár dolgot: A Java két dolog: egyrészt egy programozási nyelv, másrészt egy keretrendszer. A nyelv nagyjából kényelmesre sikeredett, és jól lehet benne programozni (hogy miért, arra rátérek később), de ez akár C-re is fordulhatna, vagy mondjuk .NET-re (utóbbit úgy hívják, J#, de mintha lett volna J++ is), a lényeg az, hogy a csillagok megfelelő állása esetén gyorsabban lehet benne programozni, mint PHP-ban.

A Java-t mint keretrendszert viszont eredetileg látványosan elrontották, ami anno megmutatkozott hirhedt sebességében, és ezt a hibát csak 2004-ban sikerült orvosolni a .NET mintájára (a sztorihoz az is hozzátartozik, hogy a Microsoft közölte a Sun-nal, hogy máshogy kell megépíteni, nem hittek neki, és ezért indult el a .NET projekt - azóta észbekaptak).

A betöltések sebességét már ez előtt orvosolták a mobilokon (ezt az eljárást preverifying-nek hívják), sajnos azonban ez a kódmodul nem érhető el profi formában Mac OS X -re, ami sötét árnyékként vetül a platformon a J2ME fejlesztésekre. Ezen kívül a mobilokban külön Java processzor foglalkozik a rendszer futtatásával, hogy ne a főprocesszort terhelje.

Volt még baj a felületi rendszer sebességével is, a 2006 decemberében napvilágot látott Java SE 6 már ezekre is nyújt megoldást.

Tömören: a Java ma (2007) nem tekinthető lassúnak.

Továbbá: a Java alkalmazások hordozhatóak. Azaz, ha nekem van egy Nokia mobilom, és a rajta lévő java alkalmazást át akarom vinni egy Sony Ericsson mobilra, sanszos, hogy ezt meg tudom tenni. C / C++ alkalmazásokkal ez teljesen felejtős téma, úgy mint: KDE, Gnome, úgy általánosságban Linux. Nem tudok egy ubuntu és egy redhat linux közt másolni programokat, sőt, egy Ubuntu Linux 5.10 és 7.10 között se. Nem fog működni egyszerűen.

A Java nagy előnye még, hogy erősen típusos, tisztán imperatív és objektumorientált nyelv, amit röviden, szakzsargon nélkül úgy fogalmazhatunk meg: a Java egy klasszikus programozási nyelv. Ezekről a nyelvekről viszont rendkívül sokmindent tudunk, olyannyira, hogy a programozó feladatainak nagy részét számítógép is tudja segíteni. A legegyszerűbb példa erre, hogy ha valamit egy fájlban átnevezünk, a többiben automatikusan átnevezi, a bonyolultabb a legó-szerű programozás, az automatikus kódkiegészítés, sőt,nem ritkán kódírás.

Ebből következően telis-tele vagyunk olyan alkalmazásokkal, ahol a gépelés felét a számítógép végzi.

A Java ezen kívül egy ipari szabvány. Nem egy cég fejleszti és tartja karban, mint a .NET-et, hanem egy közösség és egy szabványügyi szervezet foglalkozik vele. Magyarul, ha jövő héten a Kis Józsi Bt kihoz egy saját keretrendszert, akkor nem fog szólni senki egy szót se, és sok dolog fog vele működni azonnal - illetve ez elsősorban a keretrendszer kódminőségétől függ, ha bugos, akkor persze nem.

Ennyit a Java védelmében, sajnos a blogokon a kommenteket látva a sztereotípiák még mindig élnek, ezért fontos ezt leírni.

Miért nem J2ME? Mit nyújt az Android a J2ME-hez képest?

Ez jó kérdés, talán a Google se tudja a választ, bár itt hozzáférhetőbb a platform többi része is. Ami engem jobban érdekelne: az Android miért nem J2ME-kompatibilis? Semmi értelmes indokot nem látok az SDK átnyálazása után, hogy ezt miért ne lehetne megtenni. Sőt, továbbmegyek: a legtöbb értelmes megoldás esetén édesmindegy, hogy az J2ME, vagy Android, mert az értelmes problémák körét a J2ME elég jól lefedi.

Amit pluszban nyújt az Android:

  • Adatbázis réteg (SQLite)
  • Webes alkalmazások kezelése
  • Multitask környezet
  • Alkalmazások közti kommunikáció (IPC)

Ezek közül:

  • Az adatbázisréteget meg lehetne írni J2ME-ben is
  • A webalkalmazásokat szintén (Opera Mini)
  • Multitask környezet nincs J2ME-ben, ez jó
  • Az előbbi miatt eddig nem lehetett szó IPC-ről, legfeljebb hálózaton, ez is jó

Minden mást támogat a J2ME, vagy különösebb erőfeszítés nélkül meg lehetne benne írni.

Innentől kezdve azért kezd vicces lenni egy java-alkalmazás keretrendszer mobilra, nem igaz?:)

Az átlagos alkalmazásírónak tehát sok újat nem hoz, én nagyon remélem, hogy a J2ME következő változatai tartalmazni fognak alapból adatbázismotort, mert bár nem lehetetlen egy beágyazott adatbázis kézi menedzselése, az ipari igény jogos.

Amit remélek, hogy a keretrendszerek támogatni fogják hibrid J2ME-Android alkalmazások létrehozását, mivel sok különbség a két rendszer között nincs. (Leginkább a Nokia kiterjesztett J2ME-jével lehet párhuzamot vonni).

Az SDK-ról

Az SDK nem annyira rossz, bár ismét meglátszik rajt a Google ocsmány programozási módszere.

Azt se nyeltem le szó nélkül, hogy a libjingle Singleton osztályait Golf -nak és Cricket -nek nevezték el, ami látványosan semmitmondó, ezúttal az erőforrások memóriacímeit tároló fájlt hívják R-nek. Ez egyébként fordítási időben generálódik újra, így ha berakunk egy új ikont vagy egy gombhoz való képet, előbb lefordítjuk a programot, majd utána tudunk rá hivatkozni. Továbbá az erőforrásfájlokat nem lehet elnevezni akárhogy (a képeket se!), mert a java változónevek nem kezdődhetnek számmal, ill. az Android szerint alsóvonal se lehet bennük, ergo ez a bizonyos R fájl nem fordul le, tehát a fordítás meghiusúl. Ezzel remélem jópár kollegát megkíméltem a többórás értelmetlen debuggolástól. Biztos vagyok benne egyébként, hogy erre lett volna ennél szebb megoldás is.

Az új layout engine-t XML-ben (ill. tisztán javaból is) lehet programozni, amit majd akkor fogunk komolyan venni, ha lesz hozzá űrlaptervező is - nekem egyébként a doksi szerint működőképes background=”kép R címe” paramétert nem vette be, de az említett eszköz megjelenéséig dísznek van az egész.

A fő fejlesztőkörnyezet jelenleg az Eclipse, ami bár a 3 nagy környezet (Sun NetBeans, JetBrains IntelliJ IDEA, IBM Eclipse) közül kétségtelenül a legbővíthetőbb, sokak szerint a legkényelmetlenebb, egyesek szerint a legbutább is. Várjuk a többiekhez a modulokat.

Elvileg lehet kézzel is fejleszteni, néhányan megpróbálták, de meg vagyok győződve róla, hogy aki ezt java-val komolyan akarja csinálni, az nem normális - hosszabbtávon nem kifizetődő.

Az emulátor qemu-alapú, ami egyrészt jó, merthogy kapunk egy teljesen működőképes műtelefont, másrészt any.d, mert minden egyes futtatási próbálkozáskor meg kell várnunk, amíg egy emulált ARM processzor és egy egész linux felbootol rajt, ami jelentősen növeli a fejlesztési időt és különben is kényelmetlen. Két futás közt egyébként megtartja a beállításokat, ez egyrészt szintén jó, másrészt sokat fog még csuklani Szergej anyukája ezért.

(Jelige: a java nem lassú, de ha egy 200Mhz-es processzorral és egy full linuxszal emuláljuk, úgy már nem mindig gyors)

Vannak mindenféle hozzáférés-alrendszerek, Sun-tól kölcsönözve XML-ben, ezek már a MIDLet-világban is voltak, talán így picit kényelmesebb, hogy az alkalmazás előre kéri az erőforrások hozzáférését, nem menetközben.

Magánörömök

Egyrészt XMPP-t (jabber) használ a p2p-szolgáltatásokra, és bár az XMPP önmagában minden, csak nem p2p, jó, hogy social networkünket közvetlenül használhatják az alkalmazások, és kár, hogy a saját kis IDL-nyelvén kommunikál rajtuk, hisz asztali jabberklienseket is rá lehetne izzítani a témára.

Másrészt WebKit van mögötte, amit én asztalon is használok, igaz, miután a Nokia telefonokban webkit van, ezt annyira nem volt nagy művészet portolni, sőt, talán nem is kellett.

Mindenekfelett azonban már a demovideón is mac os x-en fejlesztik, így van némi esély arra, hogy a J2ME-vel ellentétben rendesen lehet fejleszteni osx-en is android appokat :) )

Forrást, azt nem adtak ki az SDK-hoz, amin próbálok nem röhögni / hörögni, a vicc az, hogy ezt se a Slashdoton, se a HUP-on nem vette észre tegnap éjjelig senki, pedig valószínűleg az Apache licenc saját magukat is kötelezné erre. Érdekes lesz forrás nélkül opensource-ot játszani… :)

Amit még szeretnék látni: amikor komplett magándisztrók jelennek meg rá, mint a linksys-routerekre. Vajon mit fognak tudni?

UPDATE: a Dalek VM nem java VM, bár a végfelhasználó számára sok különbség nincs. A mobilos java VM Sun-licenszelésű, ez azért sokmindent megmagyaráz. Link (thx to Bártházi András)