2012. augusztus 4., szombat

Leonar3Do tapasztalatok első kézből


Már több alkalommal is tollat, vagyis inkább billentyűzetet ragadtam a magyar fejlesztésű Leonar3Do-val kapcsolatosan. Emlékeztetőül itt lehet olvasni az előzményeket:
A mostani bejegyzés apropója az, hogy végre sikerült beszerezni egy Leoar3Do-t és végre valódi tapasztalatok alapján mondhatok véleményt erről az igazán ígéretes magyar fejlesztésről. Az igazság persze az, hogy lassan már egy éve készül ez a bejegyzés és már többször is aktualizálni kellet, de ez most nem lényeges, vágjunk is bele.

 Mi az a Leó egyáltalán?

A Leonar3Do interaktív asztali VR (virtuális valóság) eszköz legfontosabb hardverelemei: egy hat szabadságfokú, térbeli beviteli eszköz (madár), egy 3D szemüveg és a monitor tetejére elhelyezhető szenzorok. A hat szabadságfok a gyakorlatban azt jelenti, hogy a madárral nem csupán megfogni tudom a virtuális tárgyakat és arrább helyezni, hanem el is tudom forgatni őket, sőt a két műveletet együtt, egyszerre is elvégezhetem.

A Leonar3Do rendszer bemutatása.

A speciális 3D szemüveg fejpozíció-követéssel lehetővé teszi, hogy a monitor síkjában megjelenő sztereo képet térbeli valóságként érzékeljük. A szenzorok folyamatosan nyomon követik mind a madár, mind a szemüveg pozícióját, a központi egységen keresztül információkkal látják el a számítógépre feltelepített Leonar3Do rendszerszoftvert. Az alkalmazások a feldolgozott adatoknak megfelelően állítják elő és kezelik a létrehozott virtuális valóságot, s jelenítik meg a térben.

A csomagolás

Az első dolog, amiről illik írni az a csomagolás. Nos, ezzel kapcsolatban azt kell mondanom, hogy majdnem tökéletes. Az anyagokkal és a kivitelezéssel nincsen semmi probléma. Mégis van egy kis bájos „amatörizmus” ami az egész dizájnt és a csomagolást áthatja. A doboz kinyitása után van mit nézegetni. A háromszintes doboz sok apró kütyüt, kábelt és számos apróságot rejt, ami tökéletesen megteremeti a „kaptam valamit a pénzemért” érzést.  És ez jó!

A Leonar3Do csomag tartalma.

A kitűző és a mérőszalag pedig nagyon szép gesztus a fejlesztőktől. Sajnos nekem a „szőrös” műanyag annyira nem jön be, valamint a kicsomagolás után a visszacsomagolás már nem is olyan egyértelmű. Én a mai napig pl. nem bírom rendesen visszarakni a madarat a helyére. Érdemes lenne talán a jövőben a dizájnt átgondolni és inkább az nVidia féle egyszerűséget és eleganciát megragadni.  Ez azért fontos, mert a Leo doboza mindig kéz közelben lesz, mivel a sok apróságot néha el kell tudni pakolni.  Összességében egy erős 8 ponttal  tudom értékelni a külcsínt.

A telepítés első órája

Amint kicsomagoltuk az eszközöket célszerű a kézikönyv alapján ellenőrizni, hogy minden apróság a helyén van-e. Ha igen, akkor jöhet az üzembe helyezés elég macerás folyamata. Itt a gyenge idegzetű emberek hamar feladják, hiszen egy asztali PC kábeldzsungeljában kell utat vágnunk és újabb indákkal növelni a kábelerdőt. Nem lesz egyszerű feladat. A hardveres setup után jöhet a szoftveres, ami már könnyebb feladat, igaz a rendszer kalibrálása még mindig tartogat feladatokat a számunkra. Az egész folyamatról egy kitűnő videó, itt tekinthető meg:

A telepítés menete, érdemes megnézni.

Visszatérve még pár gondolat erejéig az alkatrészekhez. A műanyag kütyük jó minőségűek, jó a tapintásuk, szépek az illesztések, jól illeszkednek az egyes részek egymáshoz. Igényes munkáról árulkodnak. Talán a szemüveg lett kicsit „gyengécske” érzésre, az ember mindig attól fél, hogy valami történni fog vele! Persze, nem fog semmi, mert jó anyagból van az is. Ami nekem negatívum volt az első pillanattól kezdve, hogy a mozgásérzékelő szenzorokat és a szenzorelosztott kétoldalú ragasztócsíkkal kell rögzíteni a monitoron. Értem én, hogy rengeteg fajta monitor van, amihez tudni kell rögzíteni ezeket a cuccokat, de akkor is kicsit lehangoló, hogy ragasztani kell. Hogy van-e jobb ötletem? Nincs. És ha jobban belegondolok, ezzel simán együtt lehet élni, de azért dolgozni kéne ezen még fiuk! Egy apró tanács, ha van rá módunk, modern szögletes dizájnú monitor használjunk, mivel a legömbölyített modellek esetén nehézkes stabilan rögzíteni a szenzorokat. A PC-t egyébként úgy célszerű elhelyezni, hogy az ablaknak háttal vagy attól távol, a szoba másik sarkában legyen. Ez azért fontos, mert a Leo szenzorjai nem működnek megfelelően, ha szemből vagy oldalról erős napfény éri őket, valamint az olyan lámpákra is érzékeny, amik meleg szint tartalmaznak. Ilyenkor érdemes elforgatni a monitort vagy a szenzorokat egy kicsit lejjebb forgatni (vagy leárnyékolni) és újrakalibrálni a rendszert. Ha nincs lehetőség a gépet arrébb rakni, akkor be kell sötétíteni a szobát, igaz ez mindig ajánlott, mivel a képminőség - ha lehet ilyet mondani - ilyenkor a legjobb itt is.  Sajnos egyenlőre nagyon sok komponensből áll a rendszer és így kicsit nehézkes a beüzemelés. Sokat dobna a kényelmen, ha a szemüveget és a madarat wireless rendszerre lehetne cserélni. Összességében az anyagválasztásra és a kivitelezésre egy erős 7 pontot tudok adni, de még sok fejlesztési lehetőség maradt.

Kezdeti szoftveres problémák

Amikor először a kezem közé kaparintottam ezt a magyar virtuális csodát, akkor még a telepítő CD verziószáma v1.04 volt. Nagy lendülettel toltam fel azt Windows 7-es (64bit) rendszeremre, majd az első gépindítás után akkora rendszerösszeomlásom volt, hogy én még olyat nem láttam. Áhhhh… A gond nem volt kicsit. Na, mindegy, újraindítás és másodjára már sikeresen elindult a rendszer. A szenzorok kalibrációja is tökéletesen megtörtént, de egyetlen egy alkalmazásban sem állt össze a 3Ds kép annak ellenére, hogy a tesztképernyőn a sztereóhatás működött. Sem a madár, sem a szemüveg nem ment, ha a sztereó módba átváltottam. Visszalépve a hagyományos nézetbe, pedig minden nagyszerűen működött (csak ugye minek?). Ez egy komoly kezdeti bug volt, amit már a telepítő CD v1.05 változata is sikeresen orvosolt. A rendszerösszeomlást pedig 64 bites Windowson a Leo USB vezérlője okozta, ezért az USB kábelt ki kellet húzni gépindításkor. Igaz, nálam használat közben is többször összezuhant a rendszer (fatal error). Ezt a hibát driverfrissítéssel meg lehetett oldani, így akinek még mindig problémája van 64 bites rendszeren (és maradt még bátorsága is) az azonnal frissítsen. Persze senki ne gondolja, hogy ezek a hibák minden konfiguráció esetén előjönnek. Volt nálam olyan gép, ahol mindenből semmit sem tapasztaltam. Itt ki kell emelnem, hogy Leonar3Do csapata mindig igyekezett megoldani ezeket a problémákat és Fazekas Ádám úr is sokat segített a kezdeti nehézségek legyőzésében. Összességében meg vagyok elégedve a támogatással, nyugi nem vagyunk egyedül, ha bármi gondunk van, merjünk írni ezeknek a fiuknak, mert vissza fognak válaszolni és segítenek!

Amikor leesik az ember álla…

Miután átverekedtük magunkat a hardveres és szoftveres setupon és kalibráltuk a rendszert, jöhet a várva várt VR élmény. És ez micsoda élmény! Az ember csak mosolyogni tud magában, amikor először kapcsolatba lép egy virtuális gömbbel a LeoWorld alkalmazásban. Ez az élmény az, ami minden nehézséget megér! Amikor a monitorunk előtt 40-50 cm-re lebegnek a virtuális tárgyak, ogrék, tündék, és poligon cicababák az igen meggyőző tud ám lenni! Ne próbáld elképzelni, mert nem fog menni. Ez a Leo hatás, ami nem jön át, míg ki nem próbálod.

Egy lehetséges felhasználás.

Szoftveresen a következő alkalmazásokat kapjuk mega DVD-n:
  • LeoWorld: modellező és animációkészítő szoftver. Térben rajzolhatunk, gyurmázhatunk, műalkotásokat hozhatunk létre, valós idejű poligonoptimalizáció teszi lehetővé, hogy könnyedén és intuitívan alakítsunk ki bármilyen formát. Ezeken felül még ott van az ügyességi és más játékok barkácsolásának házilag adott lehetősége is. Jelenleg a program a 2.0-ás verziónál tart. Az új verzió tartalmaz már object snap funkciót, de még mindig messze van attól, hogy igazi CAD alkalmazásként tekintsünk rá. Fontos lenne még a pontos méret bevitel is. Pedig nem győzöm hangsúlyozni, hogy csak a Google, akarom mondani Trimble SketchUp-ot kellene másolni! Az alkalmazás támogatja a szabványos három-dimenziós fájlformátumokat (.obj,. stl, .3ds), így kompatibilis bármely 3D-s CAD szoftverrel. Fontos azonban tudnunk, hogy a Leo gyurmázó motorja csak tömör testekkel boldogul, így ha a beolvasott modell felület, akkor tulajdonképpen semmi értelmeset sem tudunk vele kezdeni. Erre azért jó odafigyelni. Egyébként ez a legkomolyabb program, ami létezik a rendszerhez és igen jó alkalmazásnak találom. De még messze nem egy killer app.
  • LeoBrush: a monitor itt egy festővászon (2D) szerepét tölti be, amelyhez a madarat festékszóró-pisztolyként (3D) használhatjuk. A Windows Paint VR változata. Hát nem tudom mire jó, de örülünk neki.
  • LeoGomoku: térbeli amőba, ötödölő. A számítástechnika hőskorában volt menő ez a játék, bár Palik és Héder újból kedvet hozhatna hozzá.
  • LeoBang: virtuális fallabda, az egyetlen szórakoztató játék a rendszeren.
  • LeoCapture: az egyik leglátványosabb plusz a LeoCapture névre hallgató program, amely egy egyszerű USB-kamera segítségével megörökíthetővé teszi 3DVR-es kalandozásunkat. Csak sajnos olyan bűn ronda a program felülete, hogy én még olyat nem láttam! Mi ez kérem? Vicc?! Sajnos nem. De tegyük magunkat ezen túl, mert tényleg hasznos alkalmazás.

A LeoCapture működésének bemutatása.

A sort itt be is lehet fejezni, mert egyelőre a Leo platform alkalmazásboltja ennyiből áll. Hát nem sok, ezt én is tudom. Elvileg a fejlesztők a nyílt SDK kidobásával várják a virtuális honfoglalókat, fejlesztő csapatokat. Csak nekem úgy tűnik, hogy nemigen jönnek ezek, pedig már Bill Gates is megmondta „Content Is King”. Az szép és jó, hogy az alap appokat a Leo csapata gyártja le, de a platform sohasem lesz sikeres független fejlesztők nélkül. Ugyanis a bizalmat csak az ilyen független fejlesztők tudják megalapozni. Pedig a Leo platformra nem olyan nagy kunszt fejleszteni, az SDK és az OpenGL API ismeret után már csak egy jó ötlet kell. Nem is értem, hogy miért nem fejlesztenek rá az egyetemisták szórakoztató játékokat, alkalmazásokat. Csak nekem van 2-3 jó játékötletem, már csak idő kellene hozzá. De ez már más téma. Összességében a szoftveres támogatás kielégítőnek mondható, így a 10-ből 5 pontot azért adok rá, de ezen még sokat kell dolgozni.

Mennyire pontos a rendszer?

A térbeli kijelölés pontossága személyes tapasztalatom szerint a legjobb esetben 5 mm, de inkább 10 mm a reális. Hogy mennyi? Igen, kb. 1 cm pontosan lehet vele a térben dolgozni. Először is a madár csőre is kb. 5 mm széles, ezért ennél pontosabban nem lehet vele kijelölni. A virtuális valóságban a madár csőrénél lebeg a térbeli kurzorunk, vagyis inkább bogyónk. Ha a szenzorok kalibrálása tökéletes, akkor pontosan a madár csőrénél van, de mint tudjuk, tökéletes kalibráció nincs. Ezért egy picit mindig el fog térni tőle, így 5-8 mm az a pontosság, amivel számolhatunk. Másodsorban a kezünk a levegőben van, így a kézremegés és az alátámasztás hiánya miatt is sokkal pontatlanabbul tudunk csak dolgozni. De nem kell megijedni, ugyanis a virtuális világban csak rajtunk áll, hogy a fizikai világban 1 cm egy mikrométer vagy 1 km-nek feleljen meg. Minden a szoftveren múlik. Véleményem szerint elvileg alkalmas mérnöki munkára a Leonar3Do, csak megfelelő program kell hozzá és megint az alkalmazások kérdésénél vagyunk.

Mennyibe is fáj nekünk ez?

Kérem szépen a komplett Leonar3Do rendszer ára csupán bruttó 250 000 Ft. Hát ennyiért már egy középkategóriás noteszgépet is behúzhatunk, így nem mondható olcsónak, de még éppen határeset. Csakhogy, ez a múlt. Ma már jelenleg két csomagban vásárolható meg:
  • 304 800 Ft (27% áfával) - oktatási licensz.
  • 508 000 Ft (27% áfával) - magán felhasználói licensz.
Hát kérem, itt bukik meg a 3D for All szlogen, de csúnyán. Ez azért sok. Mivel Leonar3Do rajongó vagyok nagyot csalódtam, amikor ezeket az árakat megláttam. Gondolom a befektető is beleszól az árképzésbe, de ez akkor is durva. Lehetséges, hogy az orvosoknak mindent ellehet adni, de így az oktatásból tuti kiesett a cucc. Sok egyetem sem lesz képes megvenni, nemhogy gimnázium vagy általános iskola. És itt van a magyarázat arra is, hogy miért nincsenek rá kreatív egyetemisták által készített alkalmazások. Ördögi kör ez...
Akkor most vegyem, vagy ne vegyem? Otthoni felhasználásra semmiképp sem ajánlom jó szívvel ilyen áron, de egyetemeknek, tervező irodáknak és független fejlesztőknek érdemes elgondolkodni rajta. A Leonar3Do egy fantasztikus fejlesztés, de ne felejtsük el, hogy megvásárlása nem garancia semmire sem, rajtunk múlik meddig jutunk el saját ötletünket megvalósításában. Izgalmas feladat, szóval hajrá!

2012. július 1., vasárnap

Grazie Capitano!


Alessandro Del Piero nyílt levelet intézett szeretett csapata hűséges szurkolóihoz, annak apropóján, hogy szerződése ma járt le a Juventusszal. Úgy tűnik bekövetkezett az, amire sokan nem vártunk, el sem tudtuk volna képzelni: egy korszak véget ért.

A kapitány.

"Itt a vége, a szerződésem a Juventusszal ma lejár.
Ugyan nem újdonság, de tudva, hogy most már "hivatalos", még mindig hatással van rám. Nem tölt el szomorúsággal, nincs bennem megbánás vagy nosztalgia.
Többé már nem. Azért nem, mert volt időm visszaemlékezni mi is történt velem az utolsó Bianconeris szezonomban, visszamenni és újra átélni a legnagyszerűbb álmot, amit kívánhattam.
Minden emléket, örömöt, diadalt és - hogy őszinte legyek - néhány keserűséget is a közelmúltból... Ma ezek az emlékképek villannak fel a szemem előtt és egy bizonyos ponton összemosódnak az utolsó torinói meccsem ölelésévé.
Ez az a kép, ami magában foglal mindent, egy olyan pillanat ez, amit mindig magamnál akarok tartani és ami május 13. óta a szívemben él. Semmi sem törölheti ki onnan.
Nemrég, még a nyaralás előtt kiürítettem a szerkényemet Vinovoban és kifelé menet megálltam ott, ahol hosszú hónapokon keresztül vártatok rám egy fénykép, egy autogram vagy csak egy "szia" reményében... hóban, jégen, esőben, égető napsütésben. De most én vagyok az, aki tisztelgek és köszönetet mondok nektek, ahogyan Ti is tettétek azt velem.
A játékosok mennek, de a Juventus örök. A csapattársaim maradnak, akiknek a legjobbakat kívánom és akiket mindig biztatni fogok.
Mindenekelőtt ami marad, azok Ti vagytok, a rajongók, akik a Juventust jelentik. Az a mez, amit imádtam és mindig is imádni fogok, amit vágytam és tiszteltem, szünet nélkül. Örülök, hogy utánam mások is viselhetik ezt a mezt és annak is, hogy minden 10-es szám felett mindig is az én nevem volt látható, amióta csak neveket kezdtek nyomtatni a Bianconeri mezekre.
Örülök majd, bárkié is legyen jövő évben a mezem és örülök, hogy bárhol - Olaszországban és szerte a világon - valaki arról álmodik, hogy viselje. Büszke lennék, ha valaki követné az utamat, ahogy én is arról álmodtam, hogy ezt teszem más bajnokok, példaképekkel, legendákkal.
Holnaptól nem vagyok többé Juventus-játékos, de örökké egy leszek közületek. Most egy új kaland kezdődik és ugyanolyan feltüzelt vagyok, minde 19 nyárral ezelőtt voltam.

Arrivederci. Köszönök mindent!

Alessandro."

2012. június 2., szombat

ASP.NET MVC tananyag


Nem is olyan rég elhatároztam, hogy kicsit kikupálom magam ASP.NET MVC-ből, meg munkához is kellene, így elkezdtem kutakodni a neten egy jó kis leírás után. Pár perc guglizás után futottam bele Reiter István szakmai blogjába, ahol magyar nyelvre lefordítva letölthető Jon Galloway ASP.NET MVC MusicStore Tutorial című írása. Háááát… sok mindenre számítottam, de erre nem. Egy nagyszerű anyag, nagyszerű fordítása. Ezer köszönet érte, ritka ez a hozzáállás kis hazánkban. A tananyag innen tölthető le és mindenkinek csak ajánlani tudom:


Tartalmazza a teljes forráskódot, az eredeti angol változatot és nagyjából mindent, amire szükség lehet.
  1. Az MvcMusicStore codeplex oldala:
    http://mvcmusicstore.codeplex.com
  2. Online változat az ASP.NET oldalon (angol):
    http://www.asp.net/mvc/tutorials/mvc-music-store
Köszönjük István!

Májusban megérkezett a SharpDX v2.1


Mostanában nem sok időm volt foglalkozni a számítógépes grafikával, de remélhetőleg később újra tudok rá szakítani egy kis időt. Addig is egy fontos hír a menedzselt DirectX világból. Nem is olyan régen írtam már pár gondolatot a SharpDX-ről, mint egy új és ígéretes menedzselt DirectX könyvtárról. A projekt azóta is folyamatosan fejlődik és mára már saját weboldalt is kapott:


A SharpDX egy nyílt forráskódú függvénykönyvtár ami .NET rendszer alatt teszi elérhetővé a teljes DirectX API programozását hasonlóan a SlimDX-hez.  A projekt érdekességes, hogy a Windows 8-ban debütáló Direct3D11.1 is elérhető a segítségével. A SharpDX-et illik komolyan venni mivel olyan projektek használják mint a MonoGame az ANX.Framework és a Delta Engine. Ez utóbbira alapul a SoulCraft játék amely Android-on Tegra 3-as táblagép tulajoknak okoz örömteli perceket.


Sajnos egyenlőre nem volt időm még komolyabb demót összehoznom, de amint sikerül megosztom a blogon. Addig is a SharpDX legutolsó 2.1-es verziója innen tölthető le. További részletek pedig itt olvashatóak.

2012. május 13., vasárnap

Asus Transformer Prime, az enyém vagy!


Amióta az Apple megmutatta a világnak, hogy hogyan kell táblagépet készíteni az iPad személyében, azóta érzek komoly birtoklási vágyat egy ilyen kütyü iránt. Ez az érzés immár két éve van velem és egyre inkább csak erősödik. Vagyis, csak erősödött, mivel már két hete boldog tulajdonosa vagyok egy Asus Transformer Prime készüléknek. Hogy milyen érzés? Egész kellemes.
Hosszú türelmi időnek vetettem végett, mivel úgy éreztem lassan minden komolyabb piaci szereplő megtanul táblagépet készíteni, és így már érdemes nekem is beszerezni egyet. Alapvetően az Android OS rendkívül szimpatikus a számomra és a Windows-os ökoszisztémámba is leginkább ez a rendszer illeszthető be (bocs Apple), így egyértelműen csak a droidos tabletek kínálatából szemezgettem. Első körben még csak 50-60 ezer forintos árcédulákat nézegettem, de igen hamar rájöttem, hogy nagy csalódás lenne ez a kategória a számomra, így hát gondoltam egy nagyot és berendeltem a Prime-t. A kütyüről sokat nem írnék, hiszen minden komolyabb portál foglalkozott vele:
  1. Asus Transformer Prime - méregdrága autobot
  2. ASUS Transformer Prime TF201 táblagép teszt
  3. Kipróbáltuk: ASUS Eee Pad Transformer Prime
  4. Asus Transformer Prime, az erőmű (frissítve ICS)
Röviden: "A fémes készülékházzal az ultra vékony és könnyű Transformer Prime új mércét állít a tabletek dizájnában. 8,3 mm vékony és 586 gramm, ezzel a Transformer Prime újra definiálja a mobil élet szabályait, így rendkívül könnyen használható és szállítható útközben".

Asus Transformer Prime
Számomra a dokkolós kialakítás volt az ami első látásra szerelem a Prime esetében, és azt gondolom enélkül felesleges is megvásárolni ezt a modellt. Persze azért akadnak gondok is, nincs 3G és gyenge a WiFi és GPS vétel. Erről is egészen sok írás született, egy példa: Asus Transformer Prime - gyengébb GPS jelszint.
A gondok ellenére akkor miért választottam a Prime-ot? Elsősorban azért mert mindezek ellenére még mindig az egyik legprofibb és legjobb minőséget nyújtó androidos tablet, másrészt az Asus Transformer Pad Infinity még nem kapható nálunk és már nem bírtam tovább várni :) Kicsit komolyabbra fordítva a szót, számomra a 3G nem volt fontos és azt hiszem nem véletlen, hogy az Asus is kihagyta ennél a modellnél. Egyszerűen nem az a típusú eszköz, amit az ember állandóan magánál tart. A GPS probléma valós, bár számomra megint csak nem volt túl fontos ez az opció, igaz mára már külön külső GPS antennát ad a probléma orvosolására az Asus:
Érdemes beregisztrálni az Asus-nál és igényelni a GPS Extension Kit-et, mivel nekem 7-8 napon belül megküldték Csehországból. Természetesen ingyen. Szóval most egy nagy piros pont az Asus-nak. A WiFi vétel valóban gyengébb, de nekem még problémám nem adódott belőle. Bár alacsony jelszintnél, nem lát, nem hal, nem beszél (ilyen nekem még nem volt). Igaz, ilyenkor az ember tud dobni a telefonjáról egy WiFi hotspot-ot és megint minden kerek. A dokkoló is elég jó, bár a tapipad nem notebook szint, de nem is vártam tőle. Szóval összességében teljesen elégedett vagyok az eszközzel. Csak hát az ára...az ára is teljesen rendben van, én a mobilx webáruházból rendeltem meg 170 ezerért. Meglepetésemre ICS-vel érkezett annak ellenére, hogy az adatlapján még Honeycomb szerepelt. Talán kicsit sokba kerül, de tulajdonképpen egy ultrakönnyű apró gépet kapunk a pénzünkért, ami reményeim szerint teljes mértékben képes lesz kiváltani a noteszgépemet, de majd erről később írok. Azoknak akiknek fontos a 3G a következő modelleket mindenképpen tapizzák meg:
  1. Asus Transformer Pad TF300T és TF300TG - variációk egy témára 
  2. Mobilarena TV: Kezünkben az Asus Transformer Pad TF300
  3. Mobilarena TV: Asus Transformer Pad Infinity bemutató
  4. ASUS PadFone - matrjoska baba
Zárásként csak azt mondhatom, hogy a rossz hírek ellenére én csak ajánlani tudom a Prime-ot, egy igazán érdekes és sokoldalú táblagép. DE, ha nem vagy bütykölős típusú, nem tudod mi az az Android, és nem akarsz fájlokat másolni, vagy nem is tudod mi az a fájl, akkor mindenképpen iPad 2 vegyél mert  100-120 ezres árával a legjobb ár/érték arányú masina és még ráadásul nagyon menő is!

2012. május 11., péntek

Szinte titokban jelent meg a Silverlight 5.1


[prog.hu] A Microsoft a hét közepén szinte titokban, külön sajtóközlemény nélkül, mindössze a program kiadási jegyzeteiben jelölve léptette tovább a Silverlight verziószámát egy újonnan kiadott frissítés keretében. A néhány évvel ezelőtt még a jövő technológiájaként hirdetett, mára azonban a HTML5-tel szemben egyértelműen háborút vesztett platform új, 5.1-es verziója mindössze egy hibajavító kiadás, ami gyakorlatilag semmilyen funkcionális fejlesztést nem tartalmaz.
A fél évvel az utolsó verzió megjelenését követően kiadásra került frissítésben egy kritikus besorolású biztonsági rés mellett majd' egy tucatnyi apróbb hiba javítása is megtalálható. Így például korrigálásra került több a DRM- és licenckezeléssel kapcsolatos hiba, valamint néhány végzetes összeomlást okozó bug, és egy a betűtípusok kezeléséből eredő probléma is. A most megjelent ugyanakkor vélhetően nem az utolsó frissítés lesz a Silverlight-hoz, hiszen utóbbi támogatását a jelenlegi ütemterv szerint Redmond még közel egy évtizedig: 2021 végéig fogja biztosítani.

2012. április 8., vasárnap

Windows Phone XNA tutorial

Nemrégiben Windows Phone XNA tanulmányi hét volt a devportal.hu oldalon. Az elkészült tananyag játékos formában vezeti be az érdeklődőket a XNA alapú Windows Phone fejlesztés csodálatos világába. A 10x30 perces videókat Fár Attila Gergőnek köszönhetjük, és ismét elmondható, hogy kiváló anyagot rakott össze. Mindenkinek csak ajánlani tudom, a képzés videói itt érhetőek el:
  1. WP XNA Játékos készítése és bemenetkezelés.
  2. WP XNA Karakter-animáció készítése.
  3. WP XNA Mozgó háttér készítése.
  4. WP XNA Ütközések kezelése és célpontok készítése.
  5. WP XNA Részecskék készítése, lövedékek.
  6. WP XNA Robbanások szimulálása és hangok hozzáadása.
  7. WP XNA Szövegek megjelenítése.
  8. WP XNA Egyszerű mesterséges intelligencia.
  9. WP XNA Egyszerű fizikai szimuláció.
  10. WP XNA Portolás PC-re.
Csak emlékeztetőül, letölthető a Windows Phone fejlesztés lépésről lépésre című könyv is, a tartalomjegyzék fő pontjai a következőek:
  1. Bevezetés a „Windows Phone” platform-ba (videó)
  2. Felhasználói élmény tervezése Windows Phone-on
  3. Alkalmazásfejlesztés Windows Phone-on (videó)
  4. Haladó alkalmazásfejlesztés Windows Phone (videó)
  5. Az alkalmazás életciklusa (videó)
  6. Alapvető telefonos funkciók használata (videó)
  7. További telefonos funkciók használata (videó)
  8. Adatkezelés (videó)
  9. Kommunikáció szerverrel (videó)
  10. Lapkák és értesítések (videó)
  11. Játékok a Mango világában (videó)
  12. Marketplace (videó)
  13. Teljesítmény (videó)
A könyv elektronikus verziója innen tölthető le: https://devportal.hu/fajlok/wp7konyv
A végére pedig egy igazi kuriózum Turóczy Attila tollából, 50 Windows Phone feature egy doksiban. A nagy Windows phone 7 kódgyűjtemény! Egy nagyszerű anyag, pár gondolat a bevezetőből:

"...a könyv megírásának az alapötlete az volt, hogy érthető, a Windows Phone 7 fejlesztésében tapasztalatlan szakemberek számára is átlátható útmutatókat készítsünk, melyek segítenek eligazodni ezen új terület fejlesztésében. Pont ezért a Windows Phone 7 fejlesztésének lényegesebb területeit kiemelve, a legtöbb funkcióhoz találunk benne rövid, maximum 1-2 oldalas leírásokat, melyek lépésről lépésre vezetnek végig egy-egy alkalmazás megírásában, és a kódok is szerepelnek minden lépésnél."

Kiváló munka, sok ilyet szeretnénk még. A könyv innen tölthető le.
Azt hiszem, most nem mondhatjuk, hogy nincs miből készülni. És az is jól látszik, hogy ha gyorsan kell a fejlesztőket "kikupálni" akkor egyértelműen szűkséges a magyar nyelvű oktatóanyag, hiába na, a programozók lusták, nyelvtudás ide vagy oda.

2012. április 7., szombat

Egy kiváló magyar Silverlight blog


Azoknak akik még kimerik ejteni a szájukon a Silverlight szót, és netalántán még mindig érdeklődnek a technológia iránt, azok számára ajánlom Csala Péter blogját, ahol rengeteg hasznos anyag található meg a Silverlightal kapcsolatosan. Az egyik kedvenc anyagom a blogról:
  1. Egy komplexebb Silverlight-os alkalmazás lefejlesztése videó sorozat – I/IV. rész
  2. Egy komplexebb Silverlight-os alkalmazás lefejlesztése videó sorozat – II/IV. rész
  3. Egy komplexebb Silverlight-os alkalmazás lefejlesztése videó sorozat – III/IV. rész
  4. Egy komplexebb Silverlight-os alkalmazás lefejlesztése videó sorozat – IV/IV. rész
  5. Egy komplexebb Silverlight-os alkalmazás lefejlesztése videó sorozat – V/IV. rész
És a könyv, amit az első 24 órában több mint 4000-en töltöttek le:


Sajnos a blog jelenleg leállt, a Silverlight 5-rő semmi sincs fent, kár érte. Persze ma már tudjuk, hogy a Silverlight jövője nem fényes, de attól még mindig egy igen produktív eszköz a Mac OS X támogatás miatt! Ez nem elhanyagolható előnye még mindig a technológiának. Szóval aki WPF-ben jártas, ne hagyja ki csak azért mert nem ez a jövő...

2012. február 26., vasárnap

Android alapok (1)


Senki nem születik úgy, hogy mindent tud, így ez az írás azokon az alapvető fogalmakon kíván végigmenni amelyek megismerése nélkül nehezen képzelhető el az Android fejlesztés. Én magam sem vagyok Android Guru, sőt! Mégis úgy gondolom, hogy hasznos lehet másokkal is megosztanom mindazt a tudást amit innen-onnan már összeszedtem. Ha Te Android Guru vagy akkor inkább ezt a részt hagyd ki, vagy írj jobbat... :)

Az Android platform szerkezete

Távolról tekintve a platform felépítése egyszerű és világos. A vörös színnel jelölt rész a Linux kernel, amely tartalmazza: a hardver által kezelendő eszközök meghajtó programjait. Ezeket azon cégek készítik el, amelyek az Android platformot saját készülékükön használni kívánják, hiszen a gyártónál jobban más nem ismerheti a mobil eszközbe integrált perifériákat. A kernel adja a memória kezelését, a folyamatok ütemezését és az alacsony fogyasztást elősegítő teljesítmény-kezelést is. Főként C és Assembly nyelven íródott.
Az Android platform szerkezete.
A Linux kernelen futnak a zöld részben található programkönyvtárak/szolgáltatások, mint például: libc, SSL, SQLite, stb … ezek C/C++ nyelven vannak megvalósítva. Ezekre épül a Dalvik virtuális gép, amely nem kompatibilis a Sun virtuális gépével, teljesen más az utasítás készlete, és más bináris programot futtat. A Java programok egy ún. Dalvik Executable formátumba fordítódnak, amelynek kiterjesztése .dex. Ennek a mérete kisebb mint a forrásul szolgáló .class állományok mérete, mert a több Java fájlban megtalálható konstansokat csak egyszer fordítja bele a Dalvik fordító. 
A kék színnel jelölt részekben már csak Java forrást találunk (Application Framework). Java forrást a virtuális gép futtat, ez adja az Android lényegét. Ez maga az Android OS. Ez biztosítja a különféle funkciók megvalósítását: ablakkezelő, erőforrás kezelő, stb. A virtuális gép akár teljesen elrejti a Linux által használt fájlrendszert, és csak az Android Runtime által biztosított fájlrendszert láthatjuk. Majd legfelül helyezkednek el a felhasználó számára látható programok: home screen, böngésző, telefon alkalmazás, névjegyalbum, minden ami a telefonra feltelepítve érkezik vagy mi töltünk le a Market-ből.

Felügyelt kód

Az Android platformon alkalmazások fejlesztéséhez általánosan a Java nyelvet használhatjuk (SDK - Standard Development Kit), azonban alacsonyabb szintű funkciók eléréséhez lehetőségünk van natív kódot is készíteni (NDK - Native Development Kit). A natív kód hívásához használhatjuk a JNI-t (Java Native Interface), azonban a rendszer támogatja az osztott könyvtárak (shared libraries) használatát is. A fejlesztés megkönnyítésére lehetőségünk van arra, hogy egy projekten belül elhelyezzük a Java és C++ kódrészeket. A továbbiakban a natív irányt nem emeljük ki, hiszen érvényesek rá a Standard C++ szabályok.
Az Android alkalmazások az ún. „Dalvik” virtuális gépen futnak, mely tulajdonképpen egy átdolgozott, optimalizált Java virtuális gép. A virtuális gép előnye, hogy biztonságossá teszi az alkalmazások futtatását mivel egy alkalmazás összeomlása nem tudja tönkretenni az egész rendszert. Az Android a Java 5 szintaxissal kompatibilis, így használhatunk magasabb szintű nyelvi elemeket is, ellentétben például a Java ME-vel, ahol csak a 3-as nyelvi eszköztár támogatott. A Java nyelv és a Java alkalmazások felügyeltek, így a memóriakezelésért a futtatókörnyezet és a virtuális gép felelős. A memória felszabadításért a GC (Garbage Collector) felelős, azonban ez nem jelenti azt, hogy felelőtlenül bánhatunk az objektumok létrehozásával. Törekedni kell azok folyamatos felszabadítására, hiszen a GC csak a már nem hivatkozott és nem használt objektumok memóriaterületét tudja felszabadítani.

Android alkalmazás felépítése

Egy Android alkalmazás egy vagy több alkalmazás komponensből épül fel:
  • Activity (a program egy "ablaka")
  • Service (háttérben futó szolgáltatás)
  • Content Provider (adatok kezelése)
  • Broadcast Receiver (rendszerszintű eseményekre reagál)
Minden komponensnek különböző szerepe van az alkalmazáson belül. Bármelyik komponens önállóan aktiválódhat. Akár egy másik alkalmazás is aktiválhatja az egyes komponenseket.

Android alkalmazás komponensek.
Activity: egy-egy Activity leszármazott egy-egy képernyő a mobil eszköz kijelzőjén. Egyszerre mindig csak egy Activity látható, de egy alkalmazáshoz több képernyőkép tartozhat, amelyeket futás közben - események hatására - szabadon cserélhetünk. Minden programnak kell legyen egy belépési pontja, amely az az Activity leszármazott, amelyet először mutat meg a felhasználónak. Minden Activity az android.app.Activity osztályból származik le.

Service: sok alkalmazás igényli, hogy bezárt ablakkal is képes legyen futni a háttérben, ezt szolgáltatásként megteheti, egyszerűen kell egy Service osztályból leszármazott példány, így marad a programunknak olyan része, amely a felfüggesztett Activity esetén is fut (gondoljunk például egy média lejátszóra). Minden szolgáltatást addig futtat a platform, amíg azok be nem fejeződnek, s a futó alkalmazások képesek hozzákapcsolódni a szolgáltatásokhoz, így képesek vagyunk vezérelni a háttérben futó szolgáltatást. Az android.app.Service osztályból kell öröklődnie.

Content Provider: általában minden alkalmazás tárol adatokat két futás között, hiszen ha felfüggesztés helyett bezárnánk az alkalmazást, akkor elvesznének az addig összegyűjtött adatok. A Content provider (tartalom szolgáltató) komponens feladata egy megosztott adatforrás kezelése. A platformon lehetőségünk van állományokba vagy SQLite adatbázisba menteni adatokat, és ezt segíti a Content Provider, illetve lehetővé teszi, hogy két alkalmazás adatokat cseréljen egymással. A Content provider-en keresztül más alkalmazások hozzáférhetnek az adatokhoz, vagy akár módosíthatják is azokat pl.: CallLog alkalmazás, ami egy Content provider-t biztosít, és így elérhető a tartalom. Az android.content.ContentProvider osztályból származik le és kötelezően felül kell definiálni a szükséges API hívásokat.

Broadcast Receiver: a Broadcast receiver komponens a rendszer szintű eseményekre (broadcast) reagál. Például: kikapcsolt a képernyő, alacsony az akkumulátor töltöttsége, elkészült egy fotó, bejövő hívás, stb. Az alkalmazás is indíthat saját „broadcast”-ot, például ha jelezni akarja, hogy valamilyen művelettel végzett (pl. letöltődött a torrent). Nem rendelkeznek saját felülettel, inkább valamilyen figyelmeztetést írnak ki például a status bar-ra, vagy elindítanak egy másik komponenst (jeleznek például egy service-nek). Az android.content.BroadcastReceiver osztályból származik le; az esemény egy Intent (lásd. később) formájában érhető el.

Komponensek indíthatósága

Az Android rendszer sajátossága, hogy egy alkalmazás el tudja indítani egy másik alkalmazás komponensét is, mellyel magas fokú rugalmasságot tud biztosítani a fejlesztők számára. Vegyünk egy példát. Egy fénykép készítéséhez nem kell új Activity-t készíteni, hanem elegendő a kamera alkalmazás kép készítő Activity-jét meghívni. Hívás után a képet megkapja a hívó alkalmazás és a felhasználónak úgy tűnik, mintha a kamera funkció az alkalmazás része lenne. Hoppá!
Amikor a rendszer egy új komponenst indít, először megnézi, hogy fut-e a komponenset tartalmazó alkalmazás Process-e, ha nem, akkor elindítja. Ezt követően példányosítja a szükséges osztályokat. Például az előző kamera esetén, az egész kamera alkalmazást fel kell éleszteni, ha még nem futott. Androidban tehát egy alkalmazásnak több belépési pontja lehet (nincs egy egyszerű main() függvény).
Egy komponens indításához a rendszer felé egy üzenetet/szándékot (Intent) kell intéznünk, melynek hatására végrehajtódik a kérés. A kérésre válasz is érkezhet, mely eljut az indító félhez. Na de mi is ez az Intent? Egy Intent feladata a külső események kezelése. Minden alkalmazás fel tud iratkozni egy-egy - akár a platform által nyújtott, akár magunk által definiált - külső eseményre, mint a bejövő hívás vagy egy időpont bekövetkezte. Le kell származtatnunk egy saját példányt a BroadcastReceiver osztályból, és meg kell mondanunk, hogy milyen eseményre figyeljen. Ezt megtehetjük az AndroidManifest.xml állományban, vagy akár a program futása közben is. Ha az alkalmazásunk nem fut, a figyelt események bekövetkeztekor a platform gondoskodik az elindításról.

Egy androidos projekt felépítése

Egy Android projekt nagyjából úgy épül fel, mint egy átlagos Java projekt, a Java osztályok a megszokott java kiterjesztésű fájlokban vannak, a megszokott csomagstruktúrában, s a megszokott módon kell fordítani ezeket a forrásfájlokat.
Az Android projekt létrehozása után a forráskód az src könyvtárban, míg a felhasználói felület leírására szolgáló XML állományok a res könyvtárban találhatók. Az erőforrás állományokat egy R állomány köti össze a forráskóddal, így könnyedén elérhetjük Java oldalról az XML-ben definiált felületi elemeket. Az Android projekt fordításának eredménye egy APK állomány, melyet közvetlenül telepíthetünk mobil eszközre.
Szerencsére az Android fejlesztés esetén a forráskód és a felhasználói felület különválik, a felhasználói felület definiálására XML állományokat használhatunk (AXML - Android XML ;-] ), így lehetőségünk van a felület deklaratív módon való megadására. Ez jó hír, főleg annak aki már kiképezte magát WPF-ből. Ez azonban nem teszi kizárttá, hogy forráskód szintjén is létrehozzuk, elérjük és manipuláljuk a felhasználói felületet. Ökölszabályként elfogadott, hogy a felhasználói felület minél inkább különöljön el a forráskódtól (ÁMEN!). A projektleíró állomány szintén XML formátumban érhető el (Android Manifest).

Manifest állomány

A manifest állomány az alkalmazás (lelke) leírója, definiálja az alkalmazás komponenseit. Az állománynak deklarálnia kell a következőket:
  1. Alkalmazás komponensek listája.
  2. Szükséges minimális Android verzió.
  3. Szükséges hardware konfiguráció.
Komponens indítás előtt a rendszer a manifest állományt ellenőrzi, hogy definiálva van-e benne a kért komponens. Ezen felül további feladatokat is ellát pl. mik az alkalmazás futtatásának minimális követelményei. A manifest állományban meg kell adni továbbá a támogatni kívánt Android verziót, mely felfele kompatibilis az újabb verziókkal, régebbi verzióra azonban már nem telepíthető. Meg kell adni az engedélyeket, amelyekre az alkalmazásnak szüksége van (pl. Internet elérés, névjegyzék elérés, stb.) Az alkalmazás telepítésekor ellenőrzi a rendszer ezen követelmények meglétét. A legfontosabb manifest attribútumok és tag-ek:
  • android:icon az alkalmazás ikonja
  • android:name az activity teljes neve package-al együtt
  • android:label a készülék felületén, a felhasználók által látható név
    A manifest-ben nem szereplő Activity-k, Service-k és Content provider-ek nem láthatók a rendszer számára. Ezzel szemben Broadcast receiver-ek dinamikusan is ki/be regisztrálhatóak kódból (registerReceiver()).

    A bűvös R.java állomány

    Amikor először kezdünk fejleszteni Android platformra a legfurcsább állomány a forrásban az R.java lesz. Én legalábbis csak pislogtam amikor először megpillantottam. A nevét a RESOURCE szóból kapta. Ez a ronda állomány a felelős azért, hogy az erőforrásokat kódból is elérjük. Az erőforrások elérhetőségét a rendszer automatikusan frissíti és karbantartja, így csak azt jegyezzük meg, hogy ezt az állományt kézzel nem piszkáljuk. Ezt a Java fájlt használhatjuk arra, hogy az ikonokat, képeket, elrendezéseket vagy szövegeket nem a programba írunk közvetlenül, hanem felhasználjuk az R osztályt, amely mutat az adott erőforrásra. Gondoljunk csak az Xml-ben leírt UI-ra, itt tudunk pl. az ott leírt gombra hivatkozni az id segítségével. A gyakorlatban minden világos lesz.

    A fordítás menete

    1. A fejlesztő elkészíti a Java forráskódot, valamint az XML alapú felhasználói felületleírást a szükséges erőforrás állományokkal.
    2. A fejlesztőkörnyezet az erőforrás állományokból folyamatosan naprakészen tartja az „R.java” erőforrás fájlt a fejlesztéshez és a fordításhoz.
    3. A fejlesztő a Manifest állományban beállítja az alkalmazás hozzáférési jogosultságait (pl. Internet elérés, szenzorok használata, stb.).
    4. A fordító a forráskódból, az erőforrásokból és a külső könyvtárakból előállítja a Dalvik virtuális gép gépi kódját.
    5. A gépi kódból és az erőforrásokból előáll a nem aláírt APK állomány.
    6. Végül a rendszer végrehajtja az aláírást és előáll a készülékekre telepíthető aláírt APK.
    A fordítás menete.
    A teljes folyamat a fejlesztői gépen megy végbe, a készülékekre már csak bináris állomány jut el. Szemben a Silverlight világgal ahol a fordításnak csak egy része megy végbe a fejlesztők gépén, a második lépcsőfok a felhasználó gépén történik. Ez a folyamat garantálja számunkra, hogy a végén a gépi kód teljes mértékben az adott processzora legyen optimalizálva. Az .apk-n belüli tartalom tekinthető egy alkalmazásnak, amely Android készülékekre telepíthető.

    És itt a vége...

    Itt és most véget vetünk ennek a bejegyzésnek. Még sok minden van amiről érdemes lenne írni de majd később. Remélem ez a rövid és sok szempontból nem alapos bevezető hozzájárul ahhoz, hogy a kezdő fejlesztők is magabiztosan tegyék meg az első lépéseket az Android varászlatos világában. A bejegyzés megírásához felhasználtam mindent amit értem, így egy jó kis turmix lett belőle. Alapvetően Dr. Ekler Péter előadásfóliáiból, valamint az AndroidWiki és Java Fórum cikkeiből ollóztam. Remélem nem lesz harag belőle. Ha szakmailag valami hibás akkor a kedves olvasókat kérem, hogy ne tartsák magukba kritikájukat. Kommentálni nem szégyen.

    2012. február 15., szerda

    Android Application Development - 200 Videos


    Bakter hívta fel a figyelmemet erre a szuper videógyűjteményre, a videók angol nyelvűek, de nagyon jók és hasznosak. Eredeti forrás: link.
    Köszönöm Bakter :)

    2012. február 12., vasárnap

    Android startlap kezdő fejlesztőknek


    Már régóta foglalkoztat a gondolat, hogy jó lenne megismerkedni az Android platformmal, mivel az egyetlen olyan mobil OS ami képes lehet a néhai Windows Mobile helyettesítésére. Lehetséges fájlokat másolni rá, van rendesen programozható Bluetooth stb. Ja, és igen, olcsó :) Ezek a dolgok sajnos a többi platformon nem olyan triviálisak. Szóval itt van ez a kedves zöld robot, jó lenne kezdeni vele valamit. Amikor egy új technológiával elkezdek foglalkozni mindig az édes anyanyelven keresek róla infókat először mivel számomra ez a leggyorsabb út a megértéshez. Csak az alapok után olvasok friss ropogós szakkönyvet. Ezt a bejegyzést is azért írtam, hogy az általam összegyűjtött legfontosabb weblapokat foglalja össze kezdő androidos fejlesztőknek. Akkor jöjjenek is a javaslatok a hazai kínálatból.
    Az androiddal kapcsolatos alapoldalak:
    1. http://androidwiki.hu
    2. http://developer.android.com
    3. http://source.android.com
    Az egyik leghatékonyabb tanulási módszer az online oktatás amelyben úttörő szerepet vállal hazánkban az ItFactory lelkes csapata. Szerencsére volt Androidos képzésük is melynek nyílt napját a YouTube-ra feltöltötték:

    IT Factory nyílt nap: Android.

    A videót mindenképp érdemes megtekinteni, hiszen ahhoz, hogy képbe kerüljünk, éppen elegendő a másfél óra. A rendszer telepítését itt olvashatjuk: Telepítendő környezet Android programozási tanfolyamhoz. Sajnos a tananyagot utólag nem lehet megvásárolni, pedig kiváló alapot adna a gyors kezdéshez. Persze, ha esetleg valakinek megvan az anyag az e-mailen bátran keressen csak meg :)
    A legkorrektebb magyar nyelvű Android tutoriál a Java Fórumon olvasható:
    Sajnálatos, hogy a cikksorozat abbamaradt. További írások olvashatóak a Hungarian Android Developers oldalán:
    Meg kell még említenünk Arqual blogjában indult android alkalmazásfejlesztés sorozatot is:
    1. Előszó
    2. SDK telepítés
    3. Eclipse telepítése
    4. Hello Arqual!
    Nagyon jó diasor található még Sicz-Mesziár János személyes weboldalán is. A tananyagot az  Óbudai Egyetem Neumann János Informatikai Karán oktatják. Kicsit lehetnének részletesebbek a bemutatók, de így is hasznos olvasmány:
    OE-NIK Android alkalmazásfejlesztési anyagok továbbiakban itt: http://nik.uni-obuda.hu/malk/

     Egyenlőre ennyit sikerült feltúrnom, de, ha valaki tud még magyar nyelvű anyagról azt kérem ossza meg velem és frissítem ezt a bejegyzést. Persze egy profi jegyzet sem jönne rosszul.

    Feliratkozás: Bejegyzések ( Atom )