edudroid.hu

Ahogyan a korábbi években, most is kint leszünk a Kutatók Éjszakáján. Az Edudroid az Ericsson-nal együttműködésben az Ericsson Irinyi József utca 4, -i épületében állítja ki érdekességeit. A standunkon az érdeklődők játszhatnak a  már jól ismert DroidFoci-val. Érdemes elhozni az Android telefonokat, mert két pályán is összemérhetik ügyességüket a vendégek!

A klasszikus játék mellett itt mutatjuk be először a SmartSwitch otthonvezérlő rendszerünket. A rendszert úgy terveztük hogy alacsony árával végre elhozza az intelligens otthonok kényelmét minden lakásba. A SmartSwitch nevéből is adódóan először a világítás reformálását céloztuk meg, de a hálózatot és a csomópontokat is univerzálisra terveztük. Ennek bemutatására egy kis játékot is fejlesztettünk. 3D nyomtatott alkatrészek segítségével SmartSwitch node-okat illesztettünk LEGO járművekhez. A lánctalpasok így a hálózaton keresztül távolról is vezérelhetőek a SmartSwitch mobil alkalmazáson keresztül.

Vége a várakozásnak, kigördült műhelyünkből az Időkép mobil alkalmazása, melyen Nagy Lászlóval és Nagy Szabolccsal dolgoztunk az elmúlt hetekben. A felhasználói visszajelzések alapján akad még benne hiba, hiányosság, de összességében pozitív a visszhang. A közösség egyik legnagyobb igénye a 2.1-es támogatás és a mozgó térképek. Az előbbin már dolgozunk, így a Galaxy 3, X8 és X10 mini tulajdonosoknak már nem kell sokat várni az alkalmazás használatára. A hiányzó multitouch-ot a térképeknél és a webkameráknál gombokkal fogjuk ellensúlyozni.

Stabilitási problémák merültek azonban fel. Az alkalmazás erősen támaszkodik a hálózati kommunikációra és a felhasználó lokációjára. Ezekhez sok asszinkron művelet és callback regisztráció kötődik, amik különböző feltételek egybeesése (pld. várakozás hálózazti adatra, közben beérkező telefonhívás, felület-váltás) a lassabb hálózatokon éleződik ki, ezért a fejlesztés során nem találkoztunk velük.

Az első hibajavításokkal és 2.1-es támogatással érkező verzió még a mia napon elérhető lesz. Addig is töltsétek és használjátok a mostani verziót!

Nem haltunk ki, a hosszas hallgatás oka a túlzott elfoglaltság volt. Egyrészt az Ericssonnal együttműködve készült egy kutatási célokat szolgáló - szupertitkos - alkalmazás, ezzel párhuzamosan a szabadidőmben az Időkép prototípus-pályázat pályaművén dolgoztam Nagy Lászlóval és Nagy Szabolccsal.

A pályázat győzteseként neki is kezdtünk a fejlesztésnek. Sajnos erről a projektről sem publikálhatok, de remélem a félév lezárása után lesz egy kis időm a saját projektjeimre, kerülnek fel szépen újabb és újabb elemek a TODO listára.

Sok mindennel foglalkoztam az elmúlt hetekben, főként Androidos témákban, de sajnos megosztanom egyiket sem szabad, különböző irányú titoktartási kötelezettségek miatt.

 Viszont ma reggel végre forrasztottam néhány LED-et, meg tápot az IOIO-mnak, és összeállt egy kis próbapanel, amivel lehet játszani: hat LED hat kimeneten, lehetne okosabb is, de a következő projekthez ennyi elegendő is. A tüskesort Moldován István már múlt héten forrasztott nekem az IOIO-ra, de azóta nem tudtam magam rávenni a további tennivalók elvégzésére. Az igazat megvalva féltem egy kicsit, hogy valami pont nem lesz otthon, vagy még rosszabb, valami nem sikerül, és napokon át kell debuggolnom. De a szokásos Java verzió / Android target / Library projekt beállítások után karikacsapásszerűen fordult.

Programozni végtelenül egyszerű a kis boardot, legalábbis ami a digitális outputokat illeti. Viszont a forrasztásnál figyelni kell, hogy a biztonságos üzemi áramerősség 20mA lábanként, viszont nincs a boardon szabályozva. Tehát LED-et ellenállás nélkül nem ajánlatos az eszközre kötni...

És akkor íme az első alkotásom!

Ma egy újabb SSH-hoz kötődő élményemet osztom meg veletek. Miközben itthon felügyeltem taknyos gyermekem, gondoltam biztonságba helyezem az egyik projektemet. Mivel már jó ideje git-et használok verziókövetésre, így a fejlesztőtársam által javasolt github-ra a local repo-mat gondoltam feltölteni.

Az oldalon már regisztrált felhasználó voltam, a github által ajánlott MsysGit-et használtam jómagam is, és a github részletes útmutatója alapján a távoli repo-hoz szükséges paraméterek beállítása sem okozott gondot. És ekkor jött a jól megérdemelt git push. Amint beírtam a helyesen felparaméterezett parancsot, a Windows informatív párbeszédablakban közölte, hogy az ssh.exe elszállt: „ssh.exe has stopped working”.

Jó felhasználóként tudtam, hogy csak én ronthattam el valamit. Gyors ellenőrzés, hogy jó SSH kulcsot töltöttem-e fel: Putty, SSH kulcs transzformálás ppk-vá, csatlakozás a git@github.com. Siker, üdvözöljük lajthabalazs-t. No, akkor biztosan a git beállításokat rontottam el. Végigcsináltam még egyszer, újra ssh.exe hiba. Ennek a fele sem tréfa – gondoltam – és nekiugrottam a Google-nek. A problémára természetesen megoldás nem volt, Windows 7 64 bit alatt többen találkoztak vele, és az újracsatlakozástól az operációs rendszer újrainstallálásig mindenféle tanácsot kaptak épp csak ecetes ollót nem.

Mérnök kreatív, ha nem jó az ssh.exe, szerzek egy másikat. Cygwin feltesz, PATH átír, ssh.exe átnevez, és újabb próbálkozás. MsysGit azonban nem néz bele a Path-ba, csak a saját ssh.exe-jét keresi, és nem találja. No akkor ssh.exe másolás. Persze cygwin is relatív utakon hivatkozza a dll-jeit, az első hármat átmásoltam, aztán mikor újabb és újabb függőségek kerültek elő, migráltam az egész bin könyvtárat.

Három óra vergődés után ment a push, nyugodtan aludhatok. Addig is megyek megkeresem a stackoverflow kérdéseket, és bezsebelek néhány pontot.

A Google Maps API egyre följebb kerül az Android tutorial-listákon, lassan a Hello World-öt is térképre fogják kirajzolni. Ezért lehet bosszantó, amikor a fejlesztésbe Windows platformon belevágó fiatal a Java 7.0 keytool-ját próbálja meg felhasználni a Google által elvárt MD5 hash generálásához.

A keytool egy SHA1 lenyomatot fog kiküpni a fejlesztői útmutatóban leírt parancsra:

keytool -list -keystore ~/.android/debug.keystore

Ezt természetesen nem fogja elfogadni a Google. ("The fingerprint you entered is not valid. Please press the Back button on your browser and enter a valid certificate fingerprint.") A legegyszerűbb megoldás a -v opcióval verbose módban mindent kiíratni, így az SHA1-es és SHA256-os hash-ek mellett az MD5-öst is meg fogjuk találni. Tehát a parancs helyesen:

keytool -list -keystore ~/.android/debug.keystore

A keystore-ban a debug kulcs neve egyébként androiddebugkey, a jelszó android.

Elkészült egy újabb Edudroid alkalmazás, ezúttal egy játék. A SpaceStation-ben a játékosoknak az épülő Halál Csillagot kell megvédeniük a lázadók egyre keményebb hullámaitól. A gyenge pajzsgenerátor és a könnyű fegyverzet ebben nem sok segítséget nyújt, így a nyolc pályán csak a legügyesebbek és legszerencsésebbek juthatnak túl. A fejlesztés természetesen folytatódik, akik új kihívásokra vágynak, azok számára az utolsó pálya után megnyílik a végtelen mód, ahol pontos matematika szorítja le a túlélés esélyeit nullára az idő múlásával.

Hamarosan érkeznek a frissítések – ha csak Lucas bácsi bele nem szól... Töltsétek le, ha tetszett, értékeljétek, ha nem tetszett, írjátok meg emailben, hogy miért, és igyekszem javítani, kiegészíteni. Következő fejlesztés a High-score követés lesz, és természetesen újabb és újabb pályák. Jó szórakozást, az erő legyen veletek!

Véget ért az első Android tanfolyam, amit a Centroszet segítségével tarthattunk meg. A 8-10 fővel tervezett tanfolyam végül 18 fővel indult, és így is voltak, akik már csak a második kurzusra kaphattak helyet. Szinte mindenki fel tudta venni az iramot, és sikerrel végezte el a tanfolyamot.

Bár már tavaly tavasszal megszületett a képzés terve, és nyár óta készültünk, minket is értek meglepetések. A hardveres és szoftveres környezetet a Centroszet biztosította, szerencsére volt meleg-tartalék, így mindenki követni tudta a gyakorlatok anyagát. Az első nagyobb problémát a driverek okozták, ahány hallgatónk érkezett, annyiféle telefonon, tableten szerettek volna dolgozni.

Szintén kihívást jelentett a jelentkezők különböző mértékű felkészültsége. Bár az egyetemen már megszoktuk, hogy nincs két egyforma képességű diák, ott legalább abban biztosak lehettünk, hogy néhány tárgyat mindenki hallgatott. A tanfolyamra viszont nagyon színes palettáról érkeztek jelentkezők. Élelmiszeripari mérnöktől rendszer-adminisztrátoron keresztül multinacionális cégnél alkalmazott szoftvertesztelőig széles volt a skála. Miközben az egyetemen már alapértelmezett a Java tudás, a tanfolyamra érkező diákok közül volt, aki a nyelv születése előtt szerezte meg műszaki diplomáját. Az egyetlen közös pont, amire építhettünk a tanfolyam alatt a lelkesedés, és a tudás iránti vágy volt.

Bár előzőleg jól átgondoltuk a tematikát, a gyakorlatban nem minden elképzelésünk állta meg a helyét. Szerencsére vizsgaidőszak lévén a visszajelzések és tapasztaltak alapján sikerült az anyagot a hallgatósághoz igazítani. Két nagy kihívással szembesültünk: az Android logikája meglehetősen távol esik a hagyományos futtatási modellektől, így elsajátításához több ismétlésre és példára van szükség, mint előzőleg gondoltuk. Másrészt arra kellett rádöbbennünk, hogy a vezetett laborok követése nem feltétlenül a legszórakoztatóbb feladat, így péntek este nem várható el még egy érdeklődő és lelkes hallgatótól sem, hogy több tucatnyi sort gépeljen be megszakítás nélkül. Az első alkalom után gyorsan átdolgoztuk az órák felépítését, hogy a gyakorlat és elmélet váltakozásával színesítsük az alkalmakat, és belépési pontokat készítettünk elő, hogy ha egy-egy részfeladat nem sikerül, akkor is folytatni tudja a munkát a hallgató.

Szintén több időt fogunk a következő alkalommal a fejlesztői környezet – értsd Eclipse – megismerésének szentelni, és nagyobb hangsúlyt fektetünk a kiadott anyagokban az objektum-orientált szemlélet bemutatására, és az Android API főbb fejezeteinek ismertetésére.

Összességében jó hangulatban telt a tanfolyam, a visszajelzések alapján sikerült teljesítenünk feladatunkat, és megismertetni a hallgatókat az Android platformmal és a fejlesztés alapfogásaival. Ezek mellett nyolc alkalom során legalább annyit tanultunk mi a felnőttképzésről, mint a hallgatók az Androidról – az API alapos újra-olvasásával egyébként mi is fedeztünk fel új részleteket. Így bizakodva nézünk a következő alkalom elébe. A helyek már telnek, az indulás tervezett időpontja 2012. március 23. A tematikáról, jelentkezési feltételekről a Centroszet Kft honlapján találhattok részleteket.

Ez a tavasz az újjászületés jegyében telik az Edudroidnál. Új vezetés alatt új oldalról közelítjük meg a hallgatói önálló feladatokat. Az elmúlt másfél év sikereiből és kudarcaiból tanulva mind a munkarenden, mint a célokon és követelményeken módosítva hatékonyabban és eredményesebben fogunk dolgozni, hogy diákjaink ne csak a szoftverfejlesztés mérnöki feladataival találkozzanak, hanem az alkalmazás készítésének egyéb vetületeivel is.

De a félév nem csak változást hoz, a sok új projekt mellett néhány régebbi ötlet is újraformálódott.

A korábban nagy lelkesedéssel indult H.A.V.E.R fejlesztőgárdája folytatja munkáját, mellyel diákok ezreinek életét fogja megkönnyíteni elkészültekor. Nagy István iránymutatásával és segítségével már az előző félévben elkészültek a helyfüggő szolgáltatást támogató térkép- és helymegatározó-modulok, és ebben a félévben a kissé lemaradt közösségi oldal is megkapja az egyetemhez kötődő szolgáltatásait.

Fél évnyi lappangás után újra előkerült a Droidfoci. A pozitív közönség-visszhangtól és szakmai berkekből érkező visszajelzésektől fellelkesülve újra elindult a fejlesztés, menetelünk a játékpiacra.

Persze az alapvető testi szükségletekről sem feledkeztünk meg, így készül már az étterem-keresőnk végre kiadható változata is, és az ebédszervezőt is átgondoltuk, és nekilátunk a fejlesztésének.

A Tower Defense most már csak a grafikai anyagokat és néhány pályát vár, és végre kiadható lesz, a motorjára épülve pedig készül már egy stratégiai játék is.

A Centroszet Kft szervezésében szeptemberben egy Androidos kurzust indítunk, programozási előismeretekkel rendelkező lelkes amatőrök számára. A résztvevők az alapoktól indulva ismerhetik meg a platformot, és a 8 alkalom végére képesek lesznek saját programok elkészítésére, az egyszerűbb játékoktól lokalizációt igénylő, hálózati alkalmazásokig.

A férőhelyek száma elég szűkös, az ár baráti. Részletek a Centroszet honlapján.

A TMIT az őszi félévben www.vik.bme.hu/kepzes/targyak/VITMAV01/ címmel indítja Android platformhoz kötődő szabadon választható tárgyát. Mivel Androidon programozni az előző félév tanulsága alapján kis segítséggel könnyen meg lehet tanulni, mi azokra a témákra fogunk koncentrálni, melyek talán egy kicsit mélyebbek, több utánajárást erőfeszítést igényelne az elsajátításuk. A előadásokon és gyakorlatokon olyan módszereket, eszközöket, projekteket fogunk bemutatni, melyek az Android platform határait feszegetik. Megtanulhatjátok, hogyan épül fel egy ROM és hogyan készíthettek sajátot, milyen támadások ellen, és hogyan lehet védekezni, milyen hálózati lehetőségeket rejt el előletek a Java API hivatalos konfiguráló felület. Foglalkozni fogunk az energiagazdálkodással, a lokalizációval, és túllépve az alkalmazásfejlesztésen érintünk olyan kérdéseket, melyekkel az alkalmazás terjesztése, supportja kapcsán találkozhattok: reklámok és egyéb bevételforrások, hálózat-terhelés, felhasználói logok gyűjtése és kezelése, hosting lehetőségek és azok skálázódása.

Várunk minden érdeklődőt, fejlődő eszközparkkal és oktatói gárdával. Bár az előadások anyaga érthető lesz Android tudás nélkül is, aki eddig nem programozott Androidot nézzen bele, jobb, ha nem a gyakorlatokon lát először Android kódot. Ebben a szemináriumok anyagai segyíthetnek. 

 Az Android levelezőlistán megszaporodtak a Google+ hozzáférésre - meghívóra - vonatkozó kérdések. Cserébe a Facebook falamon rögtön egy intő hozzászólás fogadott. Utánanéztem egy kicsit hogy mit is gondolt a Google hozzáadni a közösségi médiához, amitől hirtelen elszürkülhet a Facebook kékje.

Nem részletezném a találtakat, a Wired lehozott egy cikket, mely ezt megteszi helyettem, bőséges háttérinformációval kiegészítve a szűkös Facebook-klón szolgáltatás-csomagot.

A tanszéken az utóbbi hónapban több magasröptű megbeszélésünk is volt a saját közösségi alkalmazásunk kapcsán. E mellett az elmúlt napokban Csikor Levente munkásságától ihletve, sokak bosszúságára elkezdtem tesztelgetni egy kezdetleges Facebook ágenst. Így amikor megtudtam, hogy mi is az a Google+, végre megfogalmazódott bennem - is - a közösségi média fundamentális hibája.

Miközben a világ eseményei összefonódnak, sok féle relációval kötődnek egymáshoz, melyek közül az ember számára legtanulságosabb a kazualitás, addig a közösségi média semmilyen eszközt nem ad ezen kapcsolatok ábrázolására, sőt, a felhasználókat nem csak hogy nem motiválja ezek felfedezésére, hanem egyenesen igyekszik azokat a felhasználó elől elrejteni. Ha sikerül is feedjeinket megtisztogatni a felesleges "információtól" akkor is csak kronológiai sorrendjét láthatjuk a különböző eseményeknek.

Konstruktív, értékteremtő párbeszédek, beszélgetések helyett a egymás mellett kiabáló emberek sokasága tárul a közösségi oldalra belépő felhasználó elé (nem véletlen, hogy sokkal könnyem emberszabású robotot írni Facebookhoz mint akár csak egy ügyfélszolgálathoz, hogy a személyes chatelést ne is említsük). És hogy a kiabálásban még nehezebb legyen eligazodni: nem lehet a feedet rendszerezni, nem lehet tagelni, nem lehet egy üzenetet hivatkozni. Nem lehet két felhasználó közt folyt interakciókat összegyűjteni (ha azok nem üzenetek formájában, hanem mondjuk kommentekben zajlottak). A közösségi felhasználók egy erős profilból, és rövid posztok összefüggéstelen, ellenőrizhetetlen halmazából állnak.

És a Google+ mindezt kiegészíti egy algoritmusok által hasznosnak talált feeddel (vajon hol láttunk már ilyet?), még jobban tagolva a felhasználó elé tárt világot, promotálva a vizuális tartalmat, 2 perces érdekességekkel árasztva el a felhasználót: minimális attention-span, valódi vélemény-alkotás helyett egy Like az érdekesség/esemény megismerése, megértése nélkül.

Hogy lehetne jobban csinálni? Július elsején indul a H.A.V.E.R kódnevű rendszer fejlesztése, amely több fentebb vázolt problémára fog megoldást adni. A tervek szerint a minimális tanulmányi és szociális funkció-csomag már a regisztrációs héten elérhető lesz - és ez nem egy meghívókkal körülzárt beta lesz, hanem egy igazi, bugos 0.3-as release.

A Google elhatározta, hogy támogatni fogja az elektronikus kiegészítők (accessory-k) kapcsolását az Android készülékekhez. Ehhez egy Android Open Accessory Development Kit (ADK) kiadásával járult hozzá, amely USB-s kiegészítők kapcsolódását támogatja 2.3.4 verzió fölött. No de mi is ez az egész, és mire is jó?

Ahhoz, hogy egy külső hardver eszközt vezérelni tudjunk Android alatt, szükség van valami szabványos kapcsolódási módra, amivel a hardvert az Androiddal össze tudjuk kötni. Természetesen több lehetőség van (Bluetooth, USB, WiFi, bizonyos készülékeknél soros interfész) de egyik módszer sem egyszerre univerzális, egyszerű, olcsó és felhasználóbarát.  Ezen kívül szükség van egy könnyen kezelhető API-ra, ami lehetővé teszi az egyszerű és gyors fejlesztést.

Az ADK tehát szabványos USB kapcsolódási lehetőséget és API támogatást nyújt Android kiegészítő (accessory) üzemmódban kapcsolódó kütyük vezérlésére.  Az ADK kiadásával egyidejűleg természetesen kiadtak egy referencia platformot is, ami egy népszerű Arduino modulra épül. Az ADK használhatósága persze nem korlátozódik erre a modulra, már több alternatív platformot is bejelentettek. A referencia platform tulajdonképpen két részből áll: egy Arduino Mega 2560 formátumú mikrokontroller kártyából (bal oldal) és egy „demo shield” elnevezésű kiegészítő lapból (jobb oldal) amelyen a demóban használt szenzorok, LED-ek, relék, nyomógombok és egy analóg joystick található.

A Google által kiadott DemoKit alkalmazás tulajdonképpen ennek a hardvernek a vezérlését mutatja be.

Sajnos a referencia platformnak húzós ára van (~$400), de ennek ellenére elkapkodták. Az alternatívák (Microchip, stb.) még nem elérhetők. De miért olyan különlegesek ezek az eszközök? Nem lehetne egyet készíteni házilag? Dehogynem. Az ADK honlapján megtalálhatók az információk hogy hogyan, ebből kiindulva elkészült az Edudroid Accessory board.

Elsősorban tekintsük át a megoldás lényegét. Amint már említettem, USB alapú megoldásról van szó. A megoldás során gondolom szempont volt a platformtól való függetlenség, azaz hogy bármilyen telefonon használható legyen. Bár a legelegánsabb megoldás az lett volna, ha az Android eszköz játssza az USB host szerepét, az telefon hardvertől való függetlenségi követelmény nagyjából kizárta a host módot mivel semmi garancia nincs arra, hogy ezt minden készülék hardvere támogatja. Az USB host mód vagy az USB OTG (On-The-Go, szükség esetén átválthat host módba mint pl. a digitális fényképezők nyomtatáskor) hardveres támogatást igényel a telefon USB vezérlőben. Marad tehát a device mód az Android oldalon, amiből egyenesen következik a legfontosabb követelmény az mikrokontroller oldalon: a host mód támogatása. Ez a követelmény igencsak behatárolja az alkalmas mikrokontrollerek számát, vagy pedig egy host módú kiegészítő használatát igényli, mint ahogy a referencia platform esetében is történt. Ugyanis a referencia platformon az AVR mikrokontroller mellett ott figyel a MAX3421 USB host vezérlő.

Nekem történetesen ott figyelt a fiókban egy régebben elkészített Cypress EZ-HOST CY7C67300 alapú fejlesztő kártya, és rögtön arra gondoltam, hogy ez felhasználható akár kiegészítő host vezérlőként egy mikrokontroller mellett, vagy alapvető feladatok ellátására önmagában is alkalmas. Az EZ-HOST fontosabb tulajdonságai:

-        4 USB port,  host vagy device mód

-        48 MHz RISC mikrokontroller

-        16Kbyte belső RAM, külsőleg bővíthető 64Kbyte-ig

-        akár 32 GPIO láb

-        2 soros port

-        SPI port

-        HPI interfész (gyors párhuzamos interfész koprocesszor üzemmódhoz)

-        I2C port

-        IDE vezérlő (igen, vinyót lehet rá kötni!)

A fejlesztői kártyán helyet kapott egy külső RAM, ami komplexebb programok futtatását teszi lehetővé, így viszont kevesebb GPIO port maradt. Kivezetésre kerültek az SPI, az I2C, a PWM interfészek, a soros port, egy host és egy debug/fejlesztői USB port valamint 12 általános célú GPIO láb.
 

Az EZ-Host egy nyílt forrású GNU C fejlesztői környezetben programozható, ami letölthető a Cypress honlapjáról. Ugyanitt példaprogramokat is találunk, amik alapján gyorsan megvalósítható a host működés. A feladat tehát az volt, hogy megírjam a host vezérlő programját úgy, hogy Android kiegészítőként ismerje fel a telefon.

Az USB host szabványos működési elve a következő.  Először is detektáljuk, hogy fizikailag csatlakoztatva van-e egy eszköz, majd „enumeráljuk”, azaz kiolvassuk az alapvető paramétereit (gyártó/termék azonosító, kommunikációs paraméterek). Ezután megkeressük, hogy milyen szabványos interfészeket támogat (pl. USB háttértár vagy HID (Human Interface Device) beviteli eszköz), majd eldöntjük milyen drivert használjunk hozzá.  Azután megkeressük a felhasználni kívánt szolgáltatás kommunikációs végpontjait, és aktiváljuk a kívánt konfigurációt mindezt szabványos vezérlő parancsokkal. A Google viszont egy kicsit módosított az inicializáláson: az enumerálás után egy nem szabványos lekérdezést indítunk a vezérlő végponton, amire válaszként megkapjuk, hogy az eszköz támogatja-e az accessory módot és ha igen, milyen verziót. Ha támogatott az accessory mód, elküldjük az eszköz azonosítóit (gyártó, modell, verzió, szériaszám stb.) majd kiadjuk a parancsot az accessory mód bekapcsolására. A parancs kiadása után újra „enumerálni” kell a készüléket, ami most már a Google gyártói azonosítóját jelenti (0x18D1) és a termékazonosító 0x2D00 (vagy 0x2D01 ha ADB-t is támogat) lesz.  Hogy miért kellett egy ilyen furcsa módszerrel megoldani egy új szolgáltatás szabványos meghirdetése helyett, azt csak a Google tudja (találgatni lehet). Viszont leprogramozni USB host oldalról így elég kényelmes: nem kell a szolgáltatásokat enumerálni, keresgélni, egyszerűen megnézem, hogy a gyártó/termék azonosítója 0x18D1/0x2D00? Ha nem, megpróbálom átkapcsolni, és újra enumerálom… Ha minden OK, még meg kell keresni a felajánlott BULK végpontokat (a Nexus S esetében ez az 5 (be)-ös és 7-es (ki)) és a konfigurációt 1-re állítani, aztán mehet a móka.

Tehát ott tartunk, hogy él az USB kapcsolat a telefon és az eszköz között. Mit tudunk csinálni? Üzeneteket tudunk küldeni az eszköznek és az eszköz üzeneteket tud küldeni a telefonnak. A DemoKit alkalmazás egy egyszerű 3 bájtos üzenetet használ, amelynek az értelmezése egyszerű:

1.      byte:  Kontroller Osztály. Ez lehet Szervo vezérlő, LED vezérlő, relé vezérlő stb.

2.      byte:  Az osztályon belül a címzett gomb, LED száma, vagy két bájtos (szenzor) átvitel esetén az MSB. Joystick esetén az X koordináta.

3.      byte:  Kiolvasott/elküldött érték byte, vagy LSB a szenzoroknál és Y a joysticknál.

 Az első bájt esetében a következő értékek értelmezettek:

1.      Gombok                     <= 

2.      LED-ek és szervók       =>

3.      Relék                        =>

4.      Hőmérséklet szenzor    <=          

5.      Fény szenzor              <=

6.      Joystick                     <=

Természetesen ez a kommunikáció nincs kőbe vésve, egyszerűen a DemoKit App és a referencia platform között ez a kommunikáció. Az egyszerűség kedvéért én is ezt használtam, és készült egy igen egyszerű „Demo Shield” az EZ-Host kártyához is, amelyen van 4 LED és 4 gomb. A firmware-t meg úgy írtam meg, hogy kompatibilis legyen a DemoKit app-al, így lehet vele tesztelni.

A kapcsolat szépen létrejön, és a LED-ek vezérlése meg a gombok állapotváltásai szépen működnek. Az egyetlen gondot a telefon áramfelvétele jelenti: az USB kapcsolaton a telefon elkezd tölteni, és ez rendesen fűti a táp stabilizátorát. De egy jó kis hűtőborda megoldja a problémát.

Ez egy rövid élménybeszámoló a tegnap megrendezett SmartMobil konferenciáról, nem összefoglaló, hanem személyes benyomások és gondolatok a konferencia kapcsán, kizárólag a szerző véleményét tükrözi. Az írásban megjelenő személyek, helyek és időpontok hasonlósága valós személyekkel, helyekkel és időpontokkal azonban nem a véletlen műve.

Nem írok regisztrációról, helyszínről, büféről, ebédről, technikai nehézségekről, tűzriadóról, erről van elég hozzászólás a Twitteren (itt vagy itt). Szintén megjelenik a feedekben mindenféle kivonat az előadásokból, főként számok, amikről itt egy összefoglaló is olvasható. Az előadók fontosabb gondolatait Polgár Péter barátom blogján találhatjátok meg.

Számomra a legérdekesebb üzenet Lassi Kurkijarvi hozta a Holland Sanomadigital-tól: ameddig a marketingesek azt hangsúlyozták, hogy a mobiltelefon személyes, a mobiltelefonon keresztül jól célozható a reklám, addig Lassi a felhasználó részeként tekintette a mobiltelefont, mint a felhasználót kiegészítő eszközt, ami különleges képességekkel ruházza fel a tulajdonosát. Bár Szabó Róbert future internet előadásaiban már megjelentek hasonló gondolatok - emberközeli szenzorok, gép-gép kapcsolat, mikrotranzakció, ennyire direkt módon még nem hallottam kimondva, hogy az okostelefon a gazdáját tesz többé, jobbá, felruházva őt a Wikipedia minden tudásával, a nyelveken szólás tudásával (Google translate), korlátlan és pontos memóriával. Ez érdekes következő lépése a mobil-evolúciónak: kezdetben az volt a kérdés, mit tud a telefon, van-e kamerája, számológépe, játékok rajta, lehet-e WAP-olni. Napjainban a felhasználói élmény kezd a központba kerülni: milyen használni a telefont, mit ad a telefon? A jövőben pedig az lesz a kérdés, hogy milyen lesz a felhasználó a telefon által (persze mindig is ez volt a kérdés, hiszen a fogyasztás egy személyes kijelentés is, de most sokkal közvetlenebb lesz a kapcsolat a fejlesztések és a célok közt). Olyan telefonokat, alkalmazásokat kell készíteni, amitől a felhasználó okosabb lesz, gyorsabban fut, vonzóbbá válik a nők (férfiak) számára, gazdagabb lesz, amikor nála van a telefon, hiszen bármit megvehet.

Az egész konferencián érződött, hogy nagyon nagyok az elvárások az okostelefonokkal szemben, és hasonló csodafegyvernek tekintik a tableteket. A média és marketing képviselői megváltásként várják az új csatorna felemelkedését, mely bőséget és gazdagságot hoz majd a fokgefegyártóktól az autógyártókig mindenkinek.

A mobil piacot és a tabletek piacát mint új, kiaknázatlan területet említették, ami majd leváltja a PC-ket (a mostani 4%-os részesedésük 50%-ra nő 2014-ig a teljes internetforgalomból). Meglepő volt számomra, hogy miközben többen a tabletek teljesítménynövekedéséről beszélnek, teljesen elkülönítik a most már 10"-os tableteket a PC piactól. Én egyre inkább úgy látom, hogy záródik be a piac az okostelefonok és tabletek körül, és ha lecseng az iPad hype, 2-3 éven belül helyükre fognak kerülni a dolgok: megjelennek a nagyobb számítási kapacitású tabletek két maggal, grafikus gyorsítóval, 720p-s 10-13"-os kijelzőkkel, a netbookok árfekvésében (még idén), és desktop operációs rendszerrel (szerintem a Windows 8-al).

A fejlesztőknek nem tesz jót a mobilos fregmentáció és a mobil korlátozások, melyeknek két célja az volt, hogy a telefónia szolgáltatások jól működjenek (ha csörög a telefon, fel lehessen venni és ne akadjon a beszélgetés, mert éppen egy szimuláció vagy játék fut), és az üzemidő elfogadható legyen. Az előbbi nem szempont a tableteknél, az utóbbit pedig nem sikerült elérni. Három dolog adja el a tableteket: a böngésző, a játékok és a közösségi oldalak. Ezek mindegyike jobban működik mondjuk egy Windows 7 operációs rendszeren, mint Androidon.

Az okostelefonok személyes társai, kiegészítői lesznek a felhasználónak. Ha sikerül megfelelő méretben értelmes üzemidőt produkálniuk, akkor nagyrészt kiváltják a feature phone-okat, az én becslésem szerint Android operációs rendszerrel az alsó, WP7, Android és iOS rendszerrel a felső árkategóriában, ebben a sorrendben. A tabletek beolvadnak a netbook (notebook) piacba, az érintőfelületre módosított asztali operációs rendszerekkel, főként Windows-zal, a különcök pedig Androidot, esetleg iOS-t használnak majd.

De vissza a konferenciára és az okostelefonokra. Miközben mindenki az Appokról és webappokról beszélt, azok tervezéséről, fejlesztéséről, és főként eladásáról, Dojcsák Dániel említette egyedül a szolgáltatásokat mint külön kategóriát. Persze nehéz elválasztani az appot a szolgáltatástól, a szolgáltatások nagyrészét appokon keresztül veszik igénybe a felhasználók. De az igazán jó szolgáltatás az, ahol a felhasználó nem látja az appot. Jó szolgáltatás lehetne a hangposta, a hálózati telefonkönyv, az automatikus file és beállítás backup. És jó szolgáltatás a média-stream, a lokáció, a navigáció, a keresés.

Az okostelefonnak egy egységes, integrált megoldásnak kell lennie, amit a szolgáltató ad a felhasználónak, a szolgáltató supportál. Egy felületnek, amiről a szolgáltatások gördülékenyen érhetőek el, a fizetés gondnélküli, vagy azért, mert flat-rate, vagy azért, mert a mikrotranzakciókat a szolgáltató kezeli. Szolgáltatásként kellene érkeznie a - tématikájában, minőségében, terjedelmében és gyakoriságában - személyre szabott hírcsatornának, az offline médiatartalomnak, a - video, audio, text - kommunikációnak. A HTC tervezi bevezetni szolgáltatásként a játékot.

Itt a tavasz, csicseregnek a madarak, virágoznak a fák és tüzelnek a macskák - mindenki készül a szaporodásra. A lelkes mobilosok száma is nő, ezért piknikről piknikre emelkednek a keretszámok. Valószínüleg a mostani piknikre is hamar betelik a kiírt 120 hely.

És persze a link: http://mobilpiknik.hu/. Akik nem tudják, miről van szó: fiatalok fiataloknak mobil projektekről, fejlesztési tippekről, tervezési megfontolásokról. És ha neked is van kedved megosztani problémáidat, sikereidet a mobil fejlesztéssel kapcsolatban, a piknik végén 5 perces előadások formájában van rá lehetőséged.

A belső oldal már a harmadik laboron megadta megát, újabb erőforrásokat kellett allokálni a virtuális gépnek. Ma pedig a verziókövető szerver érezte úgy, hogy mindenképpen újra kellene induljon - ennek oka mint kiderült manuális árammegvonás volt. Túl közel 40 önlabos diák munkatervén és 5 diploma- és szakdolgozat feladatkiíráson lassan én is újraindulnék.

Ez már az 5. hét, és vannak lelkes csapatok. A benzin ár kereső alkalmazás lehet hogy egy hét múlva a Marketen lesz, még egy apró jogi vonzatot kell áttekinteni, de remélem egy logó beszúrásával ezt meg is fogjuk oldani. A többi projekt is halad, a 7. héten már nem fog magányosan ücsörögni a pizzakalkulátor és a droidfoci az edudroidos alkalmazások polcán.

Lement a szeminárium ismétlése kibővítve a Facebook és Maps API előadással és egy új, haladó felülettervezési alkalommal. Most az Schönertzes elsőévesek (KSZK Mobiliteam) számára kell átalakítanom a sorozatot, mert az első alkalom azt mutatta, hogy mégiscsak oktatnak valamit az egyetem első három évében, és ezért jobban lehet haladni a BSc-sekkel, mint a gólyákkal. E mellett jön még három előadás a Web és eSzolgáltatások tárgyban, és három P2P gyakorlat, kezdem úgy érezni, hogy összejönne egy félévnyi anyag, ha a nyáron egy kicsit ráfeküdnék. Igény úgy tűnik van rá.

A bejegyzések egyébként nem (csak) emiatt csappantak meg, hanem mert új fórumra tértem át. Biztonsági okokból a belső oldal egyelőre belső oldal, de dolgozunk rajta, hogy nemsokára megnyithassuk nagyobb közönségnek is. A diákok egyelőre nem nyíltak meg, de remélem ahogy egy kis fejlesztői tapasztalatot szereznek, kedvet kapnak annak megosztásához is. Az Schönertzes levlista jól működik, de jobb lenne rendszerezni a tudást.

Több mint 20 hallgató jelentkezett valamelyik edudroid-os témára. Kicsit későn kaptunk észbe, de örrömmel jelenthetem, hogy elkészült a béta változata az önlabos témákat összefogó oldalnak.

Ezzel összefolyik a két blog, amivel rontottam a levegőt a blog.hu-n, ugyanis sok verejték és Linuxos segítség eredményeként up-and-running a Drupal-ban készített oldalunk. Még közel sem tökéletes, de reméljük, hogy a félév során a hallgatói projektekkel párhuzamosan az infrastruktúra is elkészül.

Elkerülendő a kör-emaileket, ezen a felületen is kérek mindenkit aki velünk fogja végezni önlabját, szakdolgozatát, diplomamunkáját, hogy regisztráljon és járjon el az ott talált információk szerint. Ahogy az oldal, a tartalom bővül, úgy újabb és újabb feladatok hárulnak rátok is, jó lenne, ha szorosan követnétek az oldalt, mert így lehet a leghatékonyabb az együttműködésünk.

Egyelőre az oldal csak a tanszéki hallgatók számára kínál tartalmat, de remélhetőleg amint megoldódnak a gyermekbetegségek, a blog kiegészítéseként az edudroid.tmit.bme.hu oldal tartalma is elérhető lesz a nagyközönség számára.

Igéretemhez híven megosztom veletek a rövid reklám-kisérlet eredményét.

Az AdMob reklám-közvetítő Android API-ját használtam a múlt héten egy teszt-alkalmazásban, hogy megvizsgáljam a rendszer működését. Az API-val és a szolgáltatással kapcsolatos tapasztalataim a következők voltak.

A milliós reklámbevételek felé az első lépés, hogy a fejlesztő regisztrál egyenes publisher fiókot az AdMob oldalon. Ezek után hozzá kell adnia az alkalmazást a fiókhoz. Ennek eredményeként kap egy azonosítót. Ezt az azonosítót kell az alkalmazás forrásában feltüntetni: innen tudja a szerver, hogy küldjön-e reklámot, és hogy hova könyvelje az esetleges bevételt. A felületen beállíthatjuk a fogadott reklámokkal kapcsolatos preferenciáinkat. Például kizárhatunk reklámokat szöveges és URL filterek alapján. A reklámok listáját is áttekinthetjük, és ellenőrizhetjük, hogy mely szűrő mely reklámokat tiltja le. Ez régen fordítva működött, megengedő szűrőket kellett definiálni, így kicsit furcsa, hogy azt ellenőrizhetjük, hogy mit tudunk egy adott filterrel kitiltani. Én a paralelepipedonhoz kapcsolódó reklámokról mondtam le, tekintettel a felhasználóbázisom finom geometriai izlésére.

Az API dokumentációja elég szájbarágós. Szolgáltat egy minta-alkalmazást is, amely látszólag nem működik majd, ennek okaira még kitérek. Az API két féle reklám használatát engedélyezi. Az egyik az AdView, mely valószínüleg minden felhasználónak ismerős: egy sor a képernyő alján vagy tetején. A mérete 320x48 DIP (device independent pixel) A HTC Desire-en ez természetesen több fizikai pixelt jelent: 400 körüli szélesség és arányos magasság. A másik reklám a teljes-képernyős InterstitialAd, ezt nem használtam a teszt során. Az AdView reklámfelület egy hagyományos nézet, amit LinearLayout belsejében lehet elhelyezni. Csak akkor jeleníti meg tartalmát, ha rendelkezésére áll a szükséges terület.

AdView esetén a felülethez hozzáadáskor kér először megjelenítendő reklámot, majd periodikus frissítést állíthatunk be, de kérhetünk azonnali frissítést is. Az InterstitialAd működése más koncepciót követ. Ez nem egy nézet és nem is egy Activity. A megjelenítés független a példányosítástól és a reklám-lekéréstől. Létrehozás után megkisérli betölteni a tartalmat. Ha már rendelkezik reklámmal, akkor válik megjeleníthetővé. Megjelenítéskor egy új Activity-t indít. Mindkét reklámhordozó kitöltöttségéről eseménykezelők segítségével értesülhetünk, megtudhatjuk, hogy a reklám kérése vagy frissítése sikeres volt-e vagy sem. Azt, hogy a felhasználó kattintott-e a reklám API-n keresztül nem tudjuk meg, ezt nem lehet feltételként szabni az alkalmazás folytatásához.

És végül a számok. A reklámkampány során $1.37-t kerestem. Ehhez tesztelés közben 1964 reklámot kértem (Requests) és 31.36%-ban kaptam is reklámot (Fill rate). A legfontosabb mérőszám az eCPM, ami azt mutatja meg, hogy 1000 megtekintés vélhetően mennyi pénzt hoz, tartalmazza a reklámok árát, és az átkattintások arányát. Ebből tudhatjuk, hogy mit várjunk napi 250.000 felhasználótól, ha azok a felhasználók is úgy kattintanak reklámra, mint az eddigiek. Ez az érték az esetemben $2.20 dollár volt, ami jónak számít. Végül az RPM, ami az eCMP korrekciója a Fill Rate-el, és lekérésekre vetíti a bevételt. Ez nálam a szánalmas $0.70 értéken állt meg. A kezdeti Fill Rate nagyon alacsony volt, az első 80 lekérésre nem is kaptam reklámot, 120-nál kezdtek folytonosan jönni, aztán mikor elkezdtem frissíteni esett le újra a Fill Rate. Ezért nem működik a minta-alkalmazás sem, nem küld reklámot a szolgáltató. Ha csak a felületi elemeket szeretnénk tesztelni, akkor be kell állítanunk az AdManager-ben az eszközünket tesz-eszköznek, és így kaphatunk dummy-reklámot, hogy tesztelhessük a felületet.

És mi a helyzet külföldön? Nos, a rövid idő alatt, ameddig New York-ban teszteltem az alkalmazást - Mock Location-nel - 100%-os Fill Rate-et értem el. Kicsit más reklámokat is kaptam, és azonnal töltődtek. Úgyhogy ha valaki tesztelgetni szeretné az alkalmazását, érdemes költözni. Sajnos a Mock Location-t engedélyeztetni kell, úgyhogy nincs lehetőség arra, hogy a felhasználó tudta nélkül dobjuk át egy másik kontinensre, pedig az sokat segítene a reklámbevételeken.

Összességében elég lehangoló a kép, egy Magyarországon jelentősnek számító 4-5000 fős stabil felhasználóbázissal, napi egy indítással havi 30.000Ft körüli bevétel érhető el. Zsebpénznek nem rossz, de a visszatérő felhasználókért folyamatosan dolgozni kell.
 

Kezdenek rendeződni a bolognai rendszerváltás által összekuszált sorok, és ennek az Edudroid is megérezte kellemes mellékhatását. Már most is sokan jelentkeztek, jelentkeztetek a különböző kiírt önálló laboratórium és diplomaterv témáinkra.

Azoknak, akik már jelentkeztek Androidos témára, vagy még ugyan nem vették fel a kapcsolatot az Androidos konzulensekkel, de gondolkodnak azon, hogy tegyék, érdemes eljönniük 2011. február 9.-én szerdán 16:00-kor az általános tájékoztatásra az IE355-ös terembe, ahol megismerheti a támákat és a témákon dolgozó diákokat, oktatókat.

Sziasztok!

Megint egy QR kód... Egy kis segítséget szeretnék kérni tőletek. Elkészült egy reklám-tesztelő alkalmazásom, és egyenlőre nem kap reklámokat. Hogy megoszthassam veletek a tapasztalataimat, előtte meg kéne szerezni őket.Töltsétek le, és nyomkodjátok ráérő időtökben, állítólag lesz ez még jobb is, sok vélemény kering az interneten a kérdésben.

Szóval kérlek, nyomkodjátok. Ha sikerül jó sok reklámot megjeleníteni, akkor kaptok egy játékot érte.

Azok, akik úgy látják, hogy ez egy csúnya módja a pénzszerzésnek megnyugodhatnak. Pénzt csak akkor szereznék, ha a megjelenő reklámra is rákattintanának, de erre nem kérlek titeket.

Ez a bejegyzés kicsit elrugaszkodik az Androidos technikai kérdésektől. Az apropója egy ma reggeli beszélgetés, ahol lelkes amatőrökként próbáltuk kitalálni, hogy vajon melyik platformra érdemes fejleszteni, mik a kilátások, és hogyan publikáljuk alkalmazásunkat.

Mint Android-felhasználó, először a saját platformomon gondolkodtam el. Vennék-e alkalmazást? Mennyiért vennék alkalmazást? Hogyan vennék alkalmazást?! Ha nem rootolt a készülék, a Google Marketen lehetőségem sincs 30%-ot a Google zsebébe csorgatva megvennem egy alkalmazást. Tegnap még szomorúnak tartottam, hogy a Pann Telenor App ötlet börzéjét egy Magyar Alkalmazás Piac nyerte meg. Ma rá kellett jönnöm, hogy ennek bizony sok értelme van, főleg, ha a Market üzemeltetőjének szemszögéből nézzük a dolgot.
 

Ha ezzel előbb utóbb megoldottnak látjuk a hogyan kérdését, lépjünk tovább az árra. 150Ft-ot gond nélkül kiadnék egy jó alkalmazásért. Akár a dupláját is. Biztos van, aki nem ennyire fukar, és akár 500-600Ft-tal is támogatja a fejlesztőt - az ő figyelmükbe ajánlom a Pizza-Kalkulátort :)

És most jön a fontos kérdés. Kiadnám érte? Egy jó alkalmazásért csak akkor nem, ha van olcsóbb. És úgy látszik mindig van. És ha nem is olyan jó, ár/érték arányban verhetetlen, ameddig a nevezően nem áll 0.
 

Milyen lehetőségei vannak ezek után egy Android fejlesztőnek, aki szereti, ha megfizetik a munkáját?

Google készségesen siet a segítségünkre: tegyünk az alkalmazásba reklámot. Most gyűröm a keretrendszert, a mellé csomagolt minta alkalmazás egyenlőre nem működik. Itt most ne menjünk részletes anyagiakba és elvi kérdésekbe. Ez egy opció, olyan, amilyen.

Következő lehetőségünk, hogy olyan alkotunk, amilyen még nincs a Marketen. Valid opció, aminek nincs alternatívája, az definíció szerint a legjobb. 300.000 alkalmazás átböngészése után felkutathatjuk a piaci réseket, ráugorhatunk, és kihozhatjuk alkalmazásunkat. Ezt követően már csak abban kell reménykednünk, hogy a siker nyomán megjelenő ingyenes klónok nem fognak tudni konkurálni az alkalmazásunkkal. Vagy azért mert sokkal okosabbak vagyunk a többi fejlesztőnél, vagy azért, mert hamar fölveszünk néhány programozót, designert, ergonómust, matematikust, akik éjt nappallá téve biztosítják, hogy ne ne lehessen egy lapon említeni 3$-os alkotásunkat egy ingyenes sufni-szoftverrel. Esetleg gondosan reklámba forgatjuk a megkeresett pénz, hogy ha a szoftverünk nem is jobb, mindenki azt higyje.

Bízva a felhasználó jóindulatában megkockáztathatunk egy Donate gombot is az ingyenes alkalmazásban. Így megkerüljük a Google 30%-át, és nem lesz olyan kis pénztárca, ami ne engedhetné meg magának az alkalmazást.

Végül bár a Marketen a szoftverek nagyrésze a felhasználóknak készül, készíthetünk szoftvert megrendelőnek is. AdMob helyett kereshetünk egy igazi szponzort, akinek eladhatjuk ötletünket, munkaidőnket, lelkülnket.

Összességében mégis kilátástalan a helyzet. Miért is alakult ez így? Hogy sikerült elérni, hogy a Marketbe januárban 29.293 alkalmazást töltsenek fel a fejlesztők?

Először is, akinek van PC-je, az tud Androidra fejleszteni. Jól-rosszul ez más kérdés, de tud, legrosszabb esetben feltölti a Marketbe a Hello World-öt - van rá számos példa, lehet keresni, az 51 találat legalább fele valószínüleg a világot köszöntő üres projekt.

Másodszor: jó Androidos programot sem nehéz írni - kell hozzá egy jó Java program. De félretéve a tréfát, a környezet jól tanulható, Java-ra épít, ami mára része lett az alapműveltségnek. Az IDE is ismerős és kényelmes.

A harmadik akadály is könnyen vehető: ha készen vagyunk az alkalmazással, 25$-ért igyenesen elérhetővé tehetjük.

És ezután? Csillagok, kommentek, update-ek. Google olcsón megoldotta a tesztelést, ellenőrzést: rábízta a felhasználókra. Az alkalmazásunk kint van a Marketen, és ameddig 4 csillag körül mozog, és nem érkeznek kommentek arról, hogy fagy, bugos, vagy rosszindulatú, addig ott lebeg a Marketben.

Mi a helyzet más platformokon? Ismeretek hiányában nem írnék átfogó elemzést. Egy elgondolkodtató részletet azonban megosztanék a Windows Phone vásárterével kapcsolatban: a 100$-os belépő 5 ingyenes alkalmazás terjesztésére jogosít. Egy, a Mcirosoft ellenőrzésén megbukó alkalmazás költsége 20$. Fejlesztőként azonosulni tudok a szemlélettel, és tudatos felhasználói oldalam sem ellenkezik azután, hogy böngésztem már az Android Marketet. Aki szemetel, fizesse meg. A minőségnek pedig ára van. Ha idáig eljutnak a fogyasztók, érdemes lesz Androidra fejleszteni.

A legutóbb publikált alkalmazásom béta tesztelése közben derült ki, hogy billentyűzet és billentyűzet közt van különbség. Nevezetesen hogy amíg a Vialin ROM, ami fölött fejlesztek, és az emulátor támogatják a 12 gombos numerikus bevitelt és az API által előírt IME_ACTION - öket, addig minderre a HTC Sense magasról tesz. Úgyhogy a tegnapi Pizza Calculator release elég csúnya véget ért.

Az API EditorInfo osztálya hét Action-t definiál. Ezek az akciók az Enter megnyomásával születnek, jellemzően minden akcióhoz tartozik egy felirat is, amely az Enter gombon jelenik meg, ha a fejlesztő a hagyományostól eltérő akciót adott meg. Ez a rendszer a szövegbevitel egyébként igen kellemetlen módját hivatott enyhíteni. Nézzünk néhány tipikus felhasználási módot!

Ha több mezőben szeretnénk egy soros szöveget bevitetni a felhasználóval, az IME_ACTION_NEXT a megfelelő eszköz. Ez az Entert egy Next gombbal helyettesíti, amivel a billentyűzet elrejtése vagy át-tapintás nélkül tudunk végiglépkedni a szövegmezőkön.

A pizzakalkulátorban egy mező editálásának eredményeképpen indul a számítás. Ezt fapadosan meg lehet oldani a mező után elhelyezett gombbal. De mennyivel kényelmesebb, ha a billentyűzet kínálja fel a Done funkciót! Ezt az IME_ACTION_DONE megadásával érhetjük el.

Ha a felületünk tartalmaz egy kereső-mezőt, és több más felületi elemet, akkor megtehetjük, hogy az IME_ACTION_SEARCH beállításábal jelezzük a felhasználónak, hogy az editálás befejeztével indul a keresés.

Természetesen ezekre az akciókra figyelni kell, nem automatikusak. Miután a layout XML-ben megadtuk a szövegdobozhoz elvárt beviteli akciót, egy OnEditorActionListener-t kell ráállítanunk a mezőre, hogy az eseményekre válaszolni tudjon az alkalmazás. Ha a felhasználó a vissza-gombbal tünteti el a billentyűzetet, akkor ilyen esemény nem generálódik. A szövegdoboz ott marad félig editálva.

Mindezek nem működnek maradéktalanul a 2.1-es HTC Sense billentyűzetével - Done-t kérve is az Enter gomb marad, annak teljes funkcionalitásával. Így kerülőutat kellett választanom, és egy OnKeyListener hozzáadásával az Enter billentyű lenyomását is figyelnem.

A történet tanulsága, hogy nem csak a képernyő-arányok változhatnak eszközről eszközre, hanem a ROM funkcionalitása is. Mivel a felhasználók általában nem rootolják a telefonjukat és nem töltenek fel "utángyártott" ROM-okat, ezért ha egy konkrét készülékre fejlesztünk, érdemes annak a gyári ROM-os változatával is ránézni legalább egyszer a felületre.

A 3D-s előadás egyik mellékterméke lett a Pizza Kalkulátor. Az alkalmazás segítséget nyújt azoknak, akik nem szeretik fejben kétjegyű számok négyzeteinek arányát hasonlítani négyjegyű számok arányaihoz.

Az alkalmazás különböző méretű pizzákra számol területet, szél/feltét terület-arányt, és egy referencia-ár megadásával megmondja, hogy a különböző méretű pizzák milyen ár alatt jelentenek jobb vételt.

Az alkalmazás - természetesen ingyenesen - elérhető a Marketről.

Elérkeztünk a sorozat harmadik fejezetéhez, melyet egy rövid szünet fog követni. A harmadik rész témája az animáció, rajzolás és Open GL lesz Androidos környezetben. Sokunknak régen volt már a számítógépes grafika, úgyhogy nem fogunk a terület mélységeibe ásni, akik eljönnek, megtanulhatják majd, hogyan kezdjenek neki a fejlesztésnek, hogyan kell inicializálni a nézetet, vezérelni a felhasználói input alapján a kirajzolást, hogyan lehet egyszerű idomokat rajzolni vagy valamelyik keretrendszer segítségével háromdimenziós modelleket betölteni.

A mintaalkalmazásról egyenlőre - az alacsony fokú készültség miatt - nem mondhatok semmit, de remélhetőleg semmivel sem lesz hasznosabb, mint az előző kettő.

A helyszín továbbra is az I épület IB210-es terme, és a csatolt labor, az időpont 10:30-tól kifulladásig.

Kis késéssel jelentkezünk, hogy mindenkinek tudtára adjuk az Android gyorstalpaló második alkalmának részleteit.

Mentségünkre szolgáljon, hogy igéretünkhöz híven az e heti alkalom is pénteken lesz, 10:30-tól a Műszaki Egyetem I épületének IB210-es termében és az IB214-es laborjában. Megelőzendő minden pletykát és félreértést, a harmadik alkalom január 21.-én, szintén 10:30-kor kezdődik majd, ugyanezen helyszínen.

A második alkalom témája az adatkezelés lesz. A lebonyolítás a szokásos, egy rövid 30-40 perces előadást két órás labor követ, ahol egy félkész projektet kell majd kiegészítenetek az adat-tároláshoz szükséges kóddal. Lesz benne SQLite adatbázis, file-kezelés és egy kis HTTP POST-olás is, emellett megtanulhatjátok, hogyan kell adapterekkel adatot biztosítani a felületi elemek számára.

Az előadást ezúttal Cserna Bence fogja tartani, aki a TransportR alkalmazás fejlesztése kapcsán megjárta az adatkezeléss legmélyebb bugyrait.

Jó hír azoknak, akik fontolgatják, hogy a tanszékünkön valamelyik Android-os témával szeretnének foglalkozni, hogy a regisztrációs hetet követően még egy alkalomsorozat keretei közt gyorstalpalhatnak majd ha most lemaradtak.