HTML

HTML

A BME Távközlési és Médiainformatikai Tanszék hallgatói és oktatói blogja az Android platformról.

Facebook

Friss topikok

  • édesebb élet: www.gsmbutik.hu/sony-xperia-xz2-tukrozodes-es-uva-uvb-mentes-uvegfolia-tempered-glass (2018.05.18. 01:30) Kutatók éjszakája - 2014
  • lajthabalazs: Nem admoboztam azóta. Hétfőn lesz egy elóadás az Ericssonos Android klubbon, ahol lesz szó a témár... (2011.12.03. 07:09) Reklám-tapasztalatok
  • A Tata: szeretnék érdeklődni, hogy nem diák is jelentkezhet-e ilyen tanfolyamra; akár programozói előképze... (2011.02.03. 16:51) Újévi gyorstalpaló 2. - Adatok
  • lajthabalazs: 80 requestnél jött egy reklám, aztán semmi. Most 120 requestem volt, és két telefonon is 3G-n is ... (2011.02.02. 20:52) Don't download!
  • EvilHedgehog: Tanulságos. Ezért nem raktam én sem főzött ROM-ot a Galaxy S-re pedig csábító volt... (2011.01.29. 10:29) Softkeyboard

Linkblog

Elérhetőek a Mob Dev Day anyagai

2010.12.21. 07:42 lajthabalazs

Felkerültek a PC World videotárába a Mob Dev Day-en elhangzott előadásokon készült felvételek.

laptop-lopásról elhíresült konferencia programja megtalálható itt érhető el, ez alapján lehet keresgélni a videotárban az anyagokat.

Szólj hozzá!

Címkék: mobile developers day 2010

Újévi gyorstalpaló

2010.12.20. 14:23 lajthabalazs

A labor sikerén felbuzdulva több Android-os rendezvény közül az első egy gyorstalpaló sorozat lesz, ahol az alkalmazás-fejlesztéshez általában szükséges technológiai elemeket, módszereket és buktatókat mutatjuk be.

A sorozat első alkalma január 7-én pénteken, 10:30-kor kezdődik az IB210-ben. Elsősorban azoknak szól, akik még sohasem fejlesztettek Android-ra, de már egy vagy több programozási nyelvben, platformban mélyebb ismeretekre tettek szert - nem hátrány, ha az egyik a Java, J2EE.

Az alkalmak anyaga utólag megtalálható lesz majd e blogon, videókra azonban senki se számítson. Az alkalmak egy 60 - 90 perces előadásból és az azt követő 2-3 órás gyakorlatból fognak állni. Utóbbit a tanszéki laborban ejtjük meg, ahol a rendelkezésre álló gépek száma fogja a létszámkorlátot adni. Ez a határ bővíthető, ha valaki saját géppel érkezik. Saját gép használata esetén a telepítsétek a környezetet valamikor az ünnepek közt (részletes útmutató az Android fejlesztői oldalon).

Az első alkalom anyaga nem fog túlmutatni a korábban leadott mérésen, ezért akik azt a mérést elvégezték, azok a második alkalomnál csatlakozzanak. Megpróbálunk még két alkalomnak helyet találni a vizsgaidőszakban, melyek az adatbázis-, file- és hálózatkezelésről, valamint a felhasználói felületről, valamint a 2D-s és 3D-s grafikai megjelenítéséről szólnak majd. Reméljük, hogy ez a három alkalmas csomag hatékonyan fogja felkészíteni a résztvevőket arra, hogy saját ötleteiket, elképzeléseiket Androidos környezetben valósíthassák meg.

A rendezvény célja, hogy ne csak az Androiddal, hanem a tanszékkel is ismerkedjetek, ezért jelentkezni kizárólag tanszéki doktoranduszoknál és tanáraitoknál lehet, körülbelül 35-en férünk el, prioritást élveznek a korán jelentkezők, azok, akik addigra végeztek minden vizsgájukkal, valamint akik jelest kaptak az alábbi tárgyak valamelyikéből: Analízis, BSZ, THSZ, Adatbázisok, Grafika. Szakirányú diploma, tudományos fokozat előny.

Szólj hozzá!

Első mérés

2010.11.23. 12:44 lajthabalazs

A tegnapi napon visszavonhatatlanul bekerült az Android az oktatásba. Büszkén jelenthetem, hogy túl vagyunk az első mérésen, melyet még két, szebb és jobb ismétlés fog követni, holnap és a jövő héten.

A segédlet csak három nappal - pontosan 60 órával - a mérés időpontja előtt készült el, és hárman írtuk, ezért kicsit darabos lett. Még nem mertem újraolvasni, de erőt veszek magamon és a hétfői és szerdai tapasztalatok alapján jövő hétfőre elkészítem a második, javított kiadás.

A mérés anyaga az alapoktól indulva jutott el a View-kig, és egy kis Android-os finomság, a SharedPreferences kezelése is belefért a négy órába. Több beszélgetést folytattunk Bencével, aminek az lett az eredménye, hogy nem adtam ki az elkészült projekt forráskódját a diákoknak. Emellett a mérési útmutatót szándékosan hiányosra írtam, hogy a mérés némely pontján a diákok rákényszerüljenek az Android dokumentáció böngészésére. Ezért aggódtam kicsit, hogy a diákok - akikről azt híresztelik, hogy nem képesek önálló munkavégzésre, elakadnak - és a mérés átmegy egy táblánál vezetett méréssé.

meres

Kellemesen csalódtam. Annak ellenére, hogy az "Ugye mindenki tud Java-ban programozni?" kérdésre adott morajlásból inkább a "Nem."-et, mint a "Talán."-t hallottam ki, a diákok feltalálták magukat. Az első óra végén amiatt kezdtem aggódni, hogy mi van ha túl korán végeznek. Szerencsére ez nem érintett sokakat, és akik hamarabb fejezték be azok találtak maguknak plusz-feladatot.

Hallgatói visszajelzésből csak egy érkezett, mikor a mérés végén megkérdeztem, hogy mit csináljunk jobban a következő mérési alkalomra: "Ne ezen a mérésen változtassatok, inkább a többi mérés is legyen ilyen."

Mindent összevetve ha Androidot programozni nem is tanultak meg a diákok, látták a fejlesztőkörnyezetet, ismerkedhettek a dokumentációval és belekóstolhattak a platformba: megkapták az alapokat, és meggyőztek arról, hogy képesek lesznek önálló munkát végezni. A diákok mellett az Android is bizonyított: jól tanulható környezet, ami alkalmas lesz arra, hogy a különböző háttérrel érkező diákok rajta keresztül ismerkedhessenek meg a mobil infokommunikációs szoftverekkel és szolgáltatásokkal. 

4 komment

Címkék: oktatás tutorial android

Mobilpiknik - másnap

2010.11.11. 15:11 lajthabalazs

Nagy reményekkel vágtam neki az esős őszi estének. A belvárosi forgalom mellett is jóval kezdés előtt érkeztem a Godot Kávéházba. Az underground hangulatot az eső mellett az útlezárások és felbontások is fokozták. A kávéházba belépve már konferenciásabb volt a hangulat, csinos házigazdasszony, kitűző, projektor, széksorok.

Húsz perccel a kezdés előtt kezdtek szálingózni az emberek, az ülőhelyek szép csendben, az állóhelyek már hangos neszezéssel fogytak el. Bence rövid felezetőjét követően némi audio-video bűvészkedés után kezdetét is vette az első előadás.  Az előadó az első generációs guruk minden jegyét magán viselte. Túl néhány piaci lufin, élő szemtanujaként platformok születésének és halálának, visszafogottan de magabiztosan mutatta be új drágaságát, a Windows 7 Mobile-t. Szép. Gyors. És nem mellesleg van rajta Live és Zune. Tényleg meggyőző volt, a felület letisztultsága, a többször hangoztatott beépített betűtípusok formája és arányai olyanok voltak, mint amilyennek egy Apple terméket képzel az ember, ha csak olvas róla. Az átvezető animációk inovatívak - kicsit a Prezi.com-ot idézik - és Androidos szemmel nézve meglepően gyorsak, folyékonyak. Kicsit lelombozott, hogy Silverlight, de ez már egyéni izlés kérdése.

A második előadás - GUI fejlesztés Android alá - kis csalódást okozott. Győrffy Péter nem sokat nézhetett ki a közönségből, az alapoktól indult, és így nem is építkezhetett túl magasra, a szűkre szabott, 5 perces keretben.

Orosz Bálint előadása mindenért kárpótolt. Egyrészt annyi hangzót zsúfolt az 5 percébe, amennyivel más tizet is kitölt, másrészt szarvánál ragadta a témát. Saját tapasztalatok, általános irányelvek, mind-mind a GUI tervezéshez kapcsolódóan, amint azt elvártuk. Lehetett volna egy kicsit több usability, de ennyi időbe még Bálint sem tudott mindent belezsúfolni.

Kicsit más szemszögből közelítette a területet előadásában Szépvölgyi Tamás, aki a Sanomát - így kicsit a megrendelői oldalt - képviselte a rendezvényen. Fájó pontja volt az előadásnak, amikor levezette, hogy ma magyar piacra nem szabad mobil-alkalmazást fejleszteni. Csak abban reménykedem, hogy előbb nő meg a piac, mint hogy lefedjék a jelenlegi szereplők, és marad még rés az utánpótlásnak.

Szintén érdekes volt Szabó Gergely előadása, aki egy sokak által hanyagolt terület szépségeit és kihívásait mutatta be. Miközben mások úgy gondolják, hogy a Mobilfejlesztési Bölcsek Köve titániumból készült, Gergely megmutatta, hogy a HTML segítségével alacsony költségvetésből is el lehet érni az összes népszerű mobil - és asztali - platformot. A böngészőben futtatott webes alkalmazás sok előnye közül talán kevés hangsúlyt kapott a karbantarthatóság, pedig ez az egyetlen megközelítés, amellyel Market nélkül lehet akár teljesen kicserélni a mit sem sejtő felhasználó alkalmazását.

Az előadások közt 5-5 perc jutott kérdésekre is, amik záporoztak is az előadókra. Akik nem tudták mikrofonba folytani kommunikáció-igényüket, azok az előadások vége felé már hlakan morajlottak, így szinte észrevétlenül csúszott át a konferencia piknikbe. Ekkor már nem volt olyan előnyös az esemény elején megszerzett előkelő helyen az első sorok egyikében. A társaság jó volt, de a szendvicsek a másik oldalról indultak, és alig jutottak át a komoly szűrésen.

Innentől - vélhetően fél nyolc - 11-ig észrevétlenül suhant az idő. A jelenlevők száma 90-ről kezelhetőre, majd kezelhetőről ritkásra zsugorodott. Végül ott találtam magam a gödör alján a szervezőkkel. Ők örömükben még mélyebre itták magukat, maró cigarettafüstben kellemes beszélgetéssel telt a rákövetkező két óra, majd mindenki a saját lábán távozott.

Jó piknik volt, sok érdekes embert, és egyszersmint ipari szereplőt ismertem meg. A nevek nem maradtak meg, úgyhogy névjegykártya-töredékekből kell majd az eseményeket visszaállítanom, de már készül erre is egy alkalmazás. Remélem lesz következő piknik is, és közben sikerül majd visszacsábítani az egyetemre néhány inspiráló startuppert, hogy az ő példájuk és tapasztalataik irányt mutassanak az ifjúságnak.

A képek Udvardy Dávid keze munkái.

Szólj hozzá!

Címkék: mobilpiknik

Hétfő reggeli testmozgás

2010.11.08. 17:39 lajthabalazs

Németh Krisztián jóvoltából hétfőn a Távközlő Hálózatok előadás szünetében lehetőség adódott egy kis DroidFocira. Sajnos képek nem készültek, mert a játék hevében teljesen megfeledkeztem róla. 5-5 (vagy 6-6?) ellen folyt a küzdelem a nagy kivetítőn, mely az előadás folytatása miatt a 11. percben, 16-9-es eredménnyel zárult, gratulálok a győzteseknek. A korábbi bugoknak nyoma sem volt.

Szólj hozzá!

Címkék: droidfoci távközlő hálózatok

Okostelefon pályázat a T-Mobile szervezésében

2010.11.08. 12:49 Prekopcsák Zoltán

A T-Mobile idén is meghirdette okostelefon pályázatát, amelynek kiemelt célja, hogy a műszaki, gazdasági és képzőművész hallgatókat összehozza egy mobil fejlesztés erejéig. Az alkalmazás bármely platformon készülhet, így Androidon is. Szerdáig lehet regisztrálni a honlapon, november 20-ig kell megalkotni a csapatokat, és február 9-ig kell leadni az alkalmazást. A fődíj nem kevesebb, mint másfél millió forint. További részletek a pályázat weboldalán.

Szólj hozzá!

Címkék: pályázat t mobile

Android a célkeresztben

2010.11.06. 14:36 lajthabalazs

Valami baj van a mai ifjúsággal. Android, US military kutatás, sniper, és így voltunk hatan Lédeczi Ákos előadásán. Pedig nem csak az I épületben volt kifüggesztve több helyütt, de az Edudroid Twitter-oldalra is felírtam. Milyen jobb dolga lehet az embernek pénteken délután kettőkor?!

Azoknak, akik nem voltak ott, jöjjön egy összefoglaló, remélem, a slide-okat is meg tudom majd szerezni. Lédeczki Ákos a Vanderbilt University vezető kutatója. Csoportja több éve foglalkozik mesterlövész eláhrítással, ők dolgozták ki és alkották meg a világ első elosztott vezetéknélküli hálózaton alapuló mesterlövész-meghatározó rendszert.

Az előadás - a 20 éves amerikai tartózkodás ellenére is magyaros - angol nyelven folyt le. A professzor a csoport eddigi munkáját mutatta be, videókkal illusztrálva. A videók az éles tesztelést  mutatták be, egy - még a hidegháború alatt - Amerikában felépített német kisváros utcáin. Meglehetősen látványos volt, ahogyan a város - rendelkezésre álló - három dimenziós modelljén a lövést követően másodperceken belül megjelent a lövész 1m-re pontos pozíciója. Ehhez 60 szétszórt szenzorra volt szükség. Ugyanilyen pontosságú eredményt produkált a rendszer több lövész esetén, és nem kis megdöbbenésemre akkor sem tévesztett, mikor egy géppuskasorozat közben adott le egy mesterlövész négy lövést. A probléma matematikája meglepően egyszerű volt, legalábbis az a része, amit a közönséggel megosztottak. Minden szenzor négy, mikroszekundumonként mintavételezett mikrofonnal volt felvértezve. A rendszer a torkolat-tüzet vette alapul és számolta ki, hogy milyen távol van a lövész, és milyen irányban. Minden egyes szenzor elég pontosan tudta becsülni azt hogy hol a lövész. És itt jön a csavar. Mert ameddig nyílt terepen egy szenzor is megmondja a lövés pontos helyét, addig városi környezetben a visszhangok miatt a szenzor által pontosan becsült pozíció lehet, hogy az eredeti pozíció többszörösen tükrözése. Viszont a szétszórt szenzorok közül azok, amelyek a lövést is hallották és nem csak a visszhangot, a lövés idejéről és helyéről is konzisztensen nyilatkoznak, míg akik a visszhangot észlelték, jellemzően különböző tükröződéseket kaptak, és így a téves meghatározások időben és térben is szétszóródnak, ezáltal egy csúszóablakkal és némi heurisztikával könnyen kiválasztható az egy legvalószínűbb lőállás. A szuperszónikus lövedék keltette lökéshullám formájából és sebességéből a rendszer még a lövedék kaliberére és a pontos fegyverre is jó becslést adott, egyben a lövés irányát, célpontját is meg tudta határozni.

 De hol jön az egészbe az Android? Az előzőekben leírt teszteket 60 elszórt szenzorral folytatták le. De az arcvonal mozog, és a katonáknak van jobb dolga is, mint fölszedni és újratelepíteni a szenzorokat, közben ellenőrizni, cserélni az elemet. Ezért az új kutatási irány a katonákon elhelyezett szenzorok felé mutat. Mivel a katonák nagyon fürgék, főleg ha tűz alá kerülnek, ezért ez sok új kihívást hozott a telepített rendszerhez képest. A katona orientációja annyira pontatlanul határozható csak meg, hogy értelmét vesztette a négy mikrofon, és így sisakonként egyetlen egy mikrofonnal kell dolgoznia a kutatóknak. Ennek ellenére látványos eredményeket értek el. Már a szigetelőszalaggal tompított telefonba épített 40kHz-en mintavételezhető mikrofonokból is elegendő egy ahhoz, hogy megmondja, hogy milyen messziről érkezett a lövés, és a lövedék milyen messze haladt el a mérőponttól (feltételezve, hogy a fegyver nem lehet más, csak AK47-es, ami a mostani háborúkban csak kis elhanyagolás). Néhány ilyen mérés, és a mérőállomások relatív pozíciója elegendő a lövész pontos meghatározásához.

Mivel a katonák a telefont nem tartják a sisakjukon, és nem szívesen ragasztják le szigszallaggal - valamint a 40kHz-es mintavételezés nem enged sok üzemidőt, ezért dedikált mikrofont és jelfeldolgozót kapnak, mely az Android telefon perifériájaként szolgáltat adatot a telefonnak és a hálózatnak. Implementációs részletekbe nem mentünk bele, a klienst sem mutatták be, pedig érdekes ergonómiai kérdés, hogy éles harci helyzetben, kesztyűben, psukát tartva, tűző napfény mellett hogyan is kezel a katona egy érintőkijelzős okostelefont, de a az előadás nagyon érdekes volt.

Ja, és az MSC-s diákok sajnálhatják, hogy érdeklődésük nem terjed ki az ilyen előadásokra, ugyanis a professzor éppen diákokat keresett egyékbént szinte kizárólag magyar nyelvű csapatába. Talán legközelebb.

2 komment

MobilPiknik - egy új kezdeményezés

2010.11.05. 23:20 Prekopcsák Zoltán

A Kitchen Budapest, a Prezi, a Stylewalker Promotion és a Colabs szervezésében rendszeres találkozó indul MobilPiknik néven, amely a magyar mobilfejlesztőket és dizájnereket hivatott havonta összegyűjteni egy limonádé mellé, hogy élőben is megvitathassák fejlesztési ötleteiket és problémáikat.

A találkozó nem kötelezi el magát egyik platform mellett sem, így az iPhone és a Windows Phone 7 mellett természetesen az Androidról is hallhattok előadásokat, utána pedig a kötetlen beszélgetésé a főszerep. A jövő szerdai első találkozó kapcsán hirtelen felpörgött a MobilPiknik Facebook oldala és 24 órán belül megtelt az 50 fős limit, de a szervezők egy nagyobb helyszín szervezésén ügyködnek, úgyhogy érdemes feljelentkezni a várólistára.

Szólj hozzá!

Címkék: windows iphone android mobilpiknik

Shared libraries - az Androidos JAR

2010.10.31. 21:56 lajthabalazs

Újrahasznosítható XML erőforrásokat szerettem volna készíteni. Szinte biztos voltam a kudarcban, de azért megpróbáltam, hátha Google gondolt az ilyesmire. Csináltam egy projektet, beleraktam egy layout-ot, és exportáltam JAR-ként, pont, ahogyan JAVA projektemmel tettem volna. Amikor a JAR-t importáltam, rögtön jött a hiba: konfliktus a nevekben, mivel az erőforrások nincsenek package-ekbe rendezve. Átnevezés, második kör. Ekkor legalább már fordult, de amikor a hivatkozott csomag R osztályán keresztül megcímeztem az erőforrásomat, természetesen a fogadó projektem első layout-ját kaptam vissza, mivel a cím integer volt, és a projekt fordulásakor mind két R osztályban ugyanbban a szekvenciában osztották.

Ugyanez történt, amikor a projektet hivatkoztam a Build Path-ban. Eddig rendjén is van minden, erre számítottam. De akkor hogyan lehet mégis újrahasznosítani az XML-eket? Az mégsem járja, hogy egyenként importáljam minden projektbe. A megoldás a Library project, egy elég nyakatekert eszköz pontosan az én problémám megoldására. Ha valamilyen erőforrást több projektben szeretnénk használni, akkor ki kell szerveznünk egy könyvtár-projektbe. Ez a könyvtár-projekt adható aztán hozzá a projektekhez.

A könyvtár projekt egy öszvér megoldás, amit az Android projekt struktúrája hívott életre. Ha az Android SDK szépen osztályokká fordítaná az XML erőforrásokat, ahogyan azt a .NET (ASP) és a J2EE (JSP) is teszi, akkor JAR-ként terjeszthetőek lennének. Így meg kell elégednünk a Library projects-el.

Mik a Library projects hátrányai? Legelőször is nem bináris, és nem kompakt. Ha valakinek oda szeretnénk adni, akkor azt open source tehetjük, és még csomagolnunk is kell. Másodszor egy projekt vagy könyvtár vagy futtatható. Ha egy projektet könyvtárként szeretnénk megosztani, akkor ki kell szerveznünk a megosztásra szánt erőforrásokat, forrás-file-okat egy külön projektbe, és azt könyvtárosíthatjuk. Annak ellenére, hogy ily módon előkészítjük a megosztásra szánt erőforrásokat, a fogadó alkalmazásban továbbra is fel kell tüntetni a manifest-file-ban, hogy pontosan mit is veszünk át - ha Activity-t is szeretnénk használni. Mivel az erőforrások továbbra sincsenek "csomagolva", ezért előfordulhatnak névbeli ütközések. Ilyenkor a host-alkalmazás élvez magasabb prioritást, a használt könyvtárak közt sorrend állítható fel. Az XML file-ok - még ha értelme is volna, és a felhasználó is szeretné - sem kerülnek összefűzésre, a magasabb prioritású file eltakarja az alacsonyabbat (Ehhez Google annyit fűz hozzá, hogy "To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the project (or is unique across all projects).", köszönjük). Végül pedig az utolsó hátrány: bár JAR-okat hivatkozhatnak, a könyvtáraink nem hivatkozhatnak más könyvtárakat, tehát ha van egy könyvtár-csomagunk, amit szeretünk használni, akkor a tartalmukat vagy egyesíteni kell, vagy minden egyes újabb projekthez egyenként hozzáadni az elemeket.

Mire jók ezek után a shared librariek? Nagyon szorosan összefüggő projektek redundáns elemeinek kezelésére. A Google is említ egy példát: adott alkalmazás ingyenes és fizetős változatának fejlesztése. Egy blogban a szerző a kétnyelvű alkalmazását kezelte így. Egy alkalmazás Skin-elésére is megfelelő lehet. Mire nem jó a shared library? Én nem ajánlanám univerzális komponensek, egyedi nézetek megvalósítására, nehezen terjeszthető, nehezen dokumentálható. Ezeket próbáljuk meg tisztán JAVA-ban elkészíteni. Az Activity-k újrahasznosítása pedig magasabb szinten megoldott, ha egy alap-funkciót Activity vagy Service valósít meg, akkor azt külön Appliation-ként terjesszük, és futási időben hasznosítsuk újra.

Szólj hozzá!

Címkék: package jar shared libraries

Játék a nézetekkel

2010.10.30. 09:16 lajthabalazs

A DroidFociban bevett szokás volt a kliens nézetét cserélgetni. Ez akkor vált kellemetlenné, amikor a nézetben összetett viselkedést implementáltunk - lásd a korábbi bejegyzést. Mit szabad és mit nem szabad megtenni a nézetekkel? Mikor és hogyan lehet egy Activity-hez több nézetet rendelni, mikor használjunk inkább új Activity-t, és mihez elég egy egyszerű dialógus? Hogyan valósítsunk meg egy beállítás-szerkesztő felületet? Ezekre a kérdésekre kerestem a választ. Engedjétek meg, hogy megosszam az eredményeimet!

Az View setContentView metódussal való cseréje nem ajánlott. A hagyományos MVC szemléletnek teljesen megfelelő gyakorlatot, mely szerint a modell fölött lecseréljük a nézetet, ha az szolgálja céljainkat, úgy tűnik ebben a formában nem támogatja az Android. Több fórumon számoltak be kellemetlen mellékhatásokról a módszer alkalmazásakor. Ha különböző nézetek tartoznak az Activity-hez, akkor a FrameLayout-ot alkalmazhatjuk több nézet megjelenítésére ugyanazon területen. (Ezt ilusztrálja a mellékelt kép, a három gomb egy FrameLayout-on foglal helyet).

Az Android framework több alosztályát kínálja a FrameLayout-nak, ezek a TabHost, a ViewSwitcher és a ViewFlipper. A TabHost-ot be sem kell mutatnom, ez a JTabbedPane Androidos megfelelője. Érdekesebb azonban a másik kettő, hiszen ilyennel nem találkoztunk a J2SE-ben (bár a FrameLayout tagadhatatlan hasonlóságot mutat a JLayeredPane-nel). A ViewSwitcher két nézet közti, a Flipper tetszőleges számú nézet közti váltást tesz lehetővé futási időben rejtve el a nem használt nézeteket. A háttérbe kerülő View-kat GONE állapotba küldi, így azok akkor sem látszanak, ha nagyobbak a "fölöttük" lévő View-knál. Az előtérbe került View értelemszerűen VISIBLE állapotba kerül. Ha a nézetek ekvivalensek, és csak a megjelenítést szolgálják, akkor ez a megfelelő eszköz a nézetek cseréjére. A komponens által elfoglalt hely a választásunk szerint lehet mindig a megjelenített nézetnek megfelelő, ennek előnye, hogy a felületünkön nem jelennek meg üres foltok, de figyelembe veheti az éppen nem látható nézetek méretét is, ekkor nem esik szét a kicentizett felület, ha azt a legnagyobb komponenshez szabtuk. Ezt a FrameLayout setMeasureAllChildren() függvényén keresztül szabhatjuk meg.

Ez a megoldás alkalmas tehát mondjuk arra, hogy egy felhasználói profilnál váltsunk a képes vagy tömör megjelenítés közt, vagy mondjuk egy térképes vagy szöveges útbaiazítás közt. Nem tehetünk akkor sem mást, ha két külömböző elrendezés közt szeretnénk váltani, például egy játékban van egy védekező meg egy támadó felhasználói felület, melyeken keresztül ugyanazok a funkciók érhetőek el, csak más elrendezésben. Ezért nem megfelelő eszköz egy beállítás-ablak elkészítésére, nem illik ez a funkció a ViewFlipper szellemiségébe.

Mit tud ehhez képest a Dialog, ami meglepő módon nem is a View leszármazottja? Ha nem tekintjük szolgáltatásnak azt, hogy a dialógus körül átsejlik a mögöttes alkalmazás, akkor mindent, amit meg lehet dialógussal oldani, megoldhatunk ViewFlipper-rel. De a Dialog sok mindenre kényelmesebb. Természetesebb a használata, hiszen egy újabb rétegként kerül az alkalmazás fölé, így a vissza nyíl használata magától értetődik. Minden dialógusnál eldönthetjük, hogy újrahasznosítjuk, vagy friss példányt kérünk belőle, azzal, hogy töröljük a removeDialog() metódussal. A dialógus alkalmas lehet egy beállítás-ablak létrehozására, hiszen tetszőleges elrendezést adhatunk neki, kaphat saját opció menüt (ezzel érdemes is élni, főleg, ha az opciómenüből érhető el a beállítás dialógus, ha működési zavart nem is okoz, de bután néz ki).

Mikor érdemes ezek után mégis Activity-t hozni létre néhány beállítás szerkesztése végett? Amikor a beállítások szerkesztése módosítja az alkalmazás állapotát. Egy szívemhez közel álló példán keresztül szeretném elmagyarázni, mire is gondolok: a DroidFociban a beállítások piszkálása közben könnyedén lőhetünk akár öngólt is, hiszen elég kicsit megdönteni a telefont, és már neki is iramodik a játékos a saját kapu felé. A beállítások szerkesztéséhez tehát le kell állítani a klienst. Ezért a beállítások szerkesztése a játék állapotát befolyásolja, nem történhet a mögöttes Activity futásával párhuzamosan. Ezért érdemes saját Activity-t készíteni a beállításoknak. Ezzel elkerüljük redundáns kódrészletek írását: a jázékparamétereket az alkalmazás onResume metódusában töltjük be a SharedProperties-ből. A játékot az onPaused metódusban állítjuk le. Így akár kiléptünk a kettő közt, akár megnyitottuk a beállításokat, ugyanazt a viselkedést kapjuk egyetlen hozzáadott kódsor nélkül, míg ennek elérése Dialog-gal több eseménykezelő implementálását igényelte volna.

Szólj hozzá!

Címkék: android activity settings dialog framelayout

Itt a Halloween, jönnek az élőhalott Appok

2010.10.29. 21:47 lajthabalazs

Néha még a legjobb hibakezelés sem akadályozza meg, hogy kilépjünk a biztonságos állapotok teréből. A Droidfoci demón sok kellemetlenséget okozott, hogy egyes játékosokat mintha gonosz szellem szállta volna meg. Az izgalom hevében sokáig észre sem vettük, csak olyan volt, mintha laggolna a hálózat. Aztán egy nyugodtabb pillanatban sikerült izolálni a hibát.

A jelenséget röviden így lehetne leírni: a pályán két játékos áll, 1-es és 2-es. Az 1-es játékos saját karakterét irányítja. 2-es játékos saját karakterét és 1-es karakterét is irányítja. Amikor erre rádöbbentünk, azonnal kizártuk a szerver oldali hibát: az egyik játékos két játékos nevében is küldött csomagokat.

Hogy fordulhat ez elő, hiszen az alkalmazás csak egy példányban fut?! Először azt hittem, hogy azért, mert két forrásból került fel az alkalmazás, a Market-ről, és a debug linken keresztül. De ma este sikerült újra előidéznem a hibajelenséget, egyetlen kliens-példánnyal. A játékhoz csatlakozás után le kell állítani a WiFi hálózatot, majd lecsatlakozni, visszaállítani a hálózatot, és csatlakozni. A mikéntet megoldva koncentrálhattam a hogyanra. Mi történhetett az alkalmazásban, ami lehetővé tette, hogy két csomagküldő Activity fusson. Vagyis igazából tetszőleges, mivel a fenti procedúrát ismételve sikerült egy harmadik, majd egy negyedik árnyékjátékost is létrehoznom.

A socketet az onCreate() metódusban nyitottam. Tehát ennek kellett többször meghívódnia, ez alátámasztja, hogy adott aktivity-nek több példányban kellett jelen lennie. A közismert életciklus diagram alapján az onCreate csak akkor hívódik meg, ha az Activity előzőleg teljesen meghalt. Akkor viszont hogy küldözgethet a régi Activity csomagokat? Miután egy Settings/Applications/Running Applications/DroidFoci/Force Stop -pal véget vetettem a nemkívánatos viselkedének, nekiálltam kiegészíteni a kódomat, hátha megtudok valamit e misztikus hibáról. Triviális hely volt vizsgálataim kiindulópontjául az onDestroy() függvényt választani. Ami a logbejegyzéseim tanusága szerint szépen le is futott. Ennek ellenére vígan működött a DatagramSocket-em, amire egyedül a halott Activity-ben volt referencia.

No de az Activity tartalmazott egy belső osztályt! Ez az osztály regisztrálta be magát a szenzorhoz, és mint nem statikus osztály, titkon referenciát hordozot az őt tartalmazó Activity példányra. Ezért bár lefut az onDestroy, mégsem szabadul fel az Activity, és így megmaradhatott meg a Socket is.

A következő kérdés, hogy akkor miért működött egyáltalán jól az alkalmazás, ha a bezárni vélt Activity tovább folytatja a futást? Hát nem működött jól. A tanszéki tesztek során a szerver még nem használta újra az azonosítókat, így ha valaki kilépett, a háttérben hiába folytatódott az üzenetküldés, a szerver eldobta azokat, mert nem tartozott az azonosítóhoz játékos, így a csomagok észrevétlenek maradtak. Amikor az új kód a játékosok számát használta a játékos azonosítására, akkor kezdtem a számokat újrahasznosítani, hogy a demo-n ne jelenjenek meg 3 órányi futás után háromjegyű számok a játékosokon. Viszont ezt otthon csak egyedül teszteltem. Utána pedig a demo alatt nem léptünk ki a telefonokkal, jártak kézről kézre. Egészen addig, amíg a router fel nem adta. Ekkor kezdődtek a bajok, megszakadt a kapcsolat, jöttek a hibák, és kiléptünk, visszaléptünk. Néhány készülék zsebbe került a még futó szenzor-vizsgálóval. Aztán amikor kiosztották az azonosítóját, a játékos mindig leesett (értsd a pálya egyik oldalvonalán pattogott). Mivel lefele esett, azt hittük, szerverhiba, rosszul értelmezett csomag, nullával osztás, vagy valami hasonló, gyógyítás közben a zsebből valakinek odaadtuk a telefont, aki vagy játszott, vagy megölte az alkalmazást és újraindította, és a probléma megszűnt.

De mi a megoldás? Az onDestroy-ban nekünk kell bezárni a Socket-et, amit nyitottunk, igazából erre való a "Destruktor" - ami ha destruktor lenne, akkor nem is merült volna fel a hiba, vagyis nem így. Persze ezzel sem oldódik meg egészen a probléma, hiszen a szenzor-eseményre továbbra is reagál majd a View, csak nem tudja elküldeni a csomagot. Igazából ez még gonoszabb hibát eredményez, hiszen nem is látjuk, hogy halmozódnak az eseménykezelők, így sikerül memory leak-et csinálni az arra egyébként alkalmatlan Java nyelven. A View-t nem kényszeríthetjük a leiratkozásra kívülről, hiszen az objektum-orientáltságnak köszönhetően nincs ráhatásunk az objektum belső működésére.

Egyetlen lehetőségünk, hogy bízunk abban, hogy a View írója gondoskodik az eseménykezelők leregisztrálásáról. De mikor is? A View-nak nincs onDestroy függvénye. Ahhoz, hogy konzisztensek maradjunk tehát nem a konstruktorban kell jelentkeznünk eseménykezelésre, hanem az onAttachedToWindow() metódusban. És a metódus párjában, az onDetachedFromWindow()-ban kell leiratkoznunk. De elegánsabb, ha ezek után a szenzorkezelést az Activity-re bízzuk.

A fentiekből okulva holnap ki is javítom azt a fránya Ronaldo-t.

Szólj hozzá!

Címkék: eseménykezelés android activity életciklus ondetroy datagramsocket onattachedtowindow

Pivot mód

2010.10.24. 10:17 lajthabalazs

Amikor még a 4:3 és 5:4-es képernyők uralták a piacot, senkinek sem jutott eszébe elforgatni a monitorát. Ám ahogy divatba jött a széles vászon, megjelent a pivot mód is a módosabbak asztalán.

A pivot-álvány, amiért asztali monitorok esetében szemérmetlen felárat kértek, az Android telefonoknál szükségtelen, így minden felhasználó szabad választhat, hogy széles (landscape) vagy magas (portrait) betekintést szeretne-e a telefon nyújtotta virtuális világba.

Az efféle szabadság azonban sok fejtörést okozhat a fejlesztőnek, akinek gondos felülettervét romba dönti a telefon döntése. Külön kellemetlenség, ha a gyorsulásszenzorokra építjük alkalmazásunkat, mert így kvázi rávesszük a felhasználót a forgatásra.

Azoknak a fejlesztőknek, akik nem akarják interfészüket fektetett és álló képarányokhoz is optimalizálni nyújt segítő kezet az Activity.setRequestedOrientation. A metódus használatával eldönthetjük, hogyan viselkedjen a felhasználói felület a telefon forgatásakor. Több konstans közül melyeket az ActivityInfo-n keresztül érhetünk el, a leghasznosabb az álló vagy fekvő, és a behind - ami az Activity mögött futó alkalmazáshoz igazítja a megjelenítést. A dokumentáció felhívja a figyelmet arra, hogy az Activity újraindulhat a metódus hívásakor, de mivel tipikusan az onCreate-ben fogjuk hívni, ezért ez minket nem érint - eltekintve attól, hogy ha az Activity nézetének cseréjével forgatjuk vagy rögzítjük az irányultságot.

2 komment

Oktatási segédanyag

2010.10.23. 13:38 lajthabalazs

Felbuzdulva a Droidfoci pozitív fogadtatásán, felmerült az ötlet, hogy építsük be az egyébként is tervezett Android mérésbe. Ezt több szempontból is jó ötletnek tartom. Egyrészt látványos: a hello world tutorialokhoz képest sokkal szórakoztatóbb. Másrészt amellett, hogy viszonylag kevés kóddal látványos eredmény érhető el, viszonylag sok részét megmozgatja az API-nak: szenzorok, menü, layout, kontrol, érintésérzékelés és rajzolás. Ha hozzávesszük azt is, amit a diákok a már elkészült kód tanulmányozásából felszedhetnek: külső alkalmazás indítása, preferenciák mentése, hálózat-kezelés, minden tudása meglesz a diáknak, hogy - ha mást nem is,- játékokat írjon. Végül az sem egy utolsó dolog, ha végre elkészül egy igazán ergonómikus kliens a játékhoz.

Szóval ma délelőtt nekiáltam modularizálni a már így is kissé átdolgozott klienst, mert mit is csinálnék szombat reggel 8-tól, amikor már túl vagyok a reggeli sajtószemlén - nem átvitt, hanem a szó szoros értelmében. Minden haladt szépen rendeltetésének megfelelően, egészen addig, amíg el nem kezdett aggasztani, hogy honnan fogom majd tudni, hogy mit írt a diák. Nem lenne elegáns azt mondani a laboron, hogy "Hozz létre egy Activity-t, tedd bele a Manifest-be, keresd meg ezt és ezt a helyet a kapott kódban, és itt meg itt meg itt írd bele az osztály nevét, az osztálya elérhetőségét, és utána, ha nem gépelted el, ki is próbálhatod". Azt szerettem volna mondani a diákoknak, hogy "Hozz létre egy Activity-t, tedd bele a Manifest-be, és már ki is próbálhatod."  Ugye rövidebb :)

Azt, hogy mindezt hogyan lehet XML parser vagy Reflection nélkül, kizárólag az Android API-ra támaszkodva megvalósítani, az alábbi linken osztottam meg az angol ajkú közönséggel. Röviden elöljáróban annyit, hogy a PackageManager sokban segít.

Szólj hozzá!

Címkék: android reflection manifest packagemanager packageinfo dinamikus activity

TransportR - az új tömegközlekedési alkalmazás

2010.10.18. 17:09 Robert Szabo

Tömegközlekedsz? Unod, hogy nem tudod, mi mikor és merre jár! Gyere építsünk együtt egy közösségi tömegközlekedési alkalmazást!

A projekt a Budapesti Műszaki Egyetem Távközlési és Médiainformatikai Tanszékén jött létre 2010 januárban, Parnaki Zsolt Gergő ötlete alapján. A tervezést és a prototípus megvalósítását Cserna Bence, Paksy Patrik és Parnaki Zsolt Gergő végezte, Dr. Szabó Róbert vezetésével és Cserna Máté közreműködésével.

A tömegközlekedési információs rendszer célja egy olyan platform létrehozása, amelyen keresztül a közösségi közlekedés menetrendekkel, útvonalakkal és naprakész információkkal élhetővé és élvezhetővé lehet tenni. A tömegközlekedést ezért közösségi alapokon támogatjuk, ahol szabadon formálódó felhasználói csoportok karban tarthatják az érdeklődési körükbe eső járatokat, legyenek azok a föld bármely pontján.
A megvalósítást érdekében egy web alapú közösségi felületet hoztunk létre, ahol az egyes járatokra vonatkozó információk kereshetőek és szerkeszthetők: http://lbss.tmit.bme.hu/transportr/web/.

A kliens oldalon Android, Windows Mobile és Windows Phone platformokra készül alkalmazás, amely helyfüggően, kedvenc járatokra vagy általános áttekintési lehetőséget biztosítva tájékoztatja az utazót az általa megkívánt információkról. A naprakészséget hely és kontextus függő közösségi üzenetküldéssel fogjuk bővíteni.

Szólj hozzá!

süti beállítások módosítása