A framework számos osztályt ad felhasználásra készen, melyek valamiféle érték tárolására hivatottak (value classes). Ezek az osztályok leginkább elemi típusokat tárolnak ám nem elemi adatként hanem objektumként. Ez igen sok esetben hasznos, sőt nemegyszer nélkülözhetetlen (struktúra mint argumentum).
Ebben a cikkben ezekről az alaptípusokról esik szó.
A property kezeléssel foglalkozó korábbi cikkben egy igen fontos dologról még nem tettünk említést. Ez egész pontosan a Key-Value Coding és Key-Value Observing.
Ezen módszerek lehetőséget adnak arra, hogy futásidőben összállított kifejezések segítségével specifikáljunk property eléréseket és így olvassunk ki vagy írjunk be értékeket a property-kbe. Mindezek mellett élhetünk a lehetőséggel, hogy felíratkozunk bármely objektumpéldányunk valamely property-jének változásaira, melyről értesítést kapunk.
Más keretrendszerekkel szemben az iOS-ről nem derül ki első ránézésre, hogy miként támogatja az aszinkron feladat végrehajtást. Amint nekiállunk és elkezdjük tanulmányozni a különféle lehetőségeket, csakhamar feltűnik, hogy mindez azért van így, mert alapértelmezett módon aszinkron valamennyi tevékenység (illetve majdnem valamennyi).
De miért fontos mindez nekünk? Röviden összefoglalva azért mert ennek tudatában megfelelő módon fenn tudjuk tartani a telefonra jellemző reszponzivítást alkalmazásainkban. Soha nem fordul elő, hogy a telefon nem reagál majd valamely felhasználó által kezdeményezett interakcióra.
Ez a cikksorozat abban ad segítséget, hogy ezt a fajta gondolkodást minél jobban érvényre tudjuk juttatni majdani alkalmazásainkban.
Korábban a gyorstalpaló cikksorozatban már kétszer is említésre került a property-k témaköre, ám teljes mélységében egyszer sem sikerült eddig végignézni. Ebben a cikkben igyekszem mindenre kiterjedően elmagyarázni a property-k használatát, a deklarációnál alkalmazott valamennyi paraméter jelentését.
Elkészült a wireframe változat, teljes funkcionalitással ámde mégis csupaszon, minden grafika nélkül. Nem mondom, izgalmas munka volt a semmiből idáig eljutni, de talán az sem lesz unalmas ,hogy valami megfelelőnek nevezhető “ruhába” öltöztessük a gyereket. 
Ebben a cikkben röviden végignézzük, milyen funkcionalitáshoz kell kitalálni az öltözéket és ha kis szerencsém van, akkor lesz aki szívesen ötletel majd velem az egyes funkciókhoz megfelelő grafikai megoldást találni.
No, akkor ideje elgondolkodni azon, hogy ezt a végtelenül egyszerű flatCube-ot milyen apróságokkal lehetne feldobni. Mit lehetne kitalálni a megjelenésen kívül, ami vonzóvá teheti a mi kis idióta tanulópéldánkat.
Nos talán nem rossz ötlet, ha kihívás elé állítjuk a felhasználót. Folyamatosan megmutatjuk neki, hogy az adott állapotból a végállapotba hány lépéssel lehet eljutni. Had gondolkozzon… 
További lehetőség, hogy a solver által előállított lépéslistát felhasználva segítséget tudunk adni, a teljesen reményvesztett felhasználóknak.
Az igazi ötlet, mely a cím mögött bújik meg, arról már többször és többen beszélgettünk: Hogyan is tudunk csatlakozni mobiltelefon segítségével egy web service-hez?!
Előbb-utóbb eljutunk 1-1 olyan feladathoz, mely egy webservice segítségével szolgáltat számunkra adatot/eredményt és azt kell valahogy megjelenítenünk/feldolgoznunk a telefonunkon, melyen egy előre megírt natív appot futtatunk.
Continue reading
Lassan elértük a célt, itt a flatCube komponens, amely a projekt végcélja volt. Kezdetben azt gondoltuk, hogy ez egy kicsi és egyszerű feladat, de végül mégsem úgy lett. Végül kiderült, hogy sokan sokkal egyszerűbbnek gondoltuk a feladatot.
A lényeg mindenesetre, hogy elkészültünk, így már csak a grafikai dizájn van hátra, illetve ki kell találni valami keretet, hogy a komponens hasznos része legyen egy kis programnak amelyben számos kocka kirakható. Nézzük miből és hogyan állt össze a flatCube komponens.
A komponens elkészítéséhez már minden technikai kérdést tisztáztunk a korábban publikált POC-okban. Mégis érdemes néhány szóban végigszaladni azokon a buktatókon, amelyekbe a komponens készítése közben beleütközhetünk.
Ebben a cikkben lesz ugyan néhány iOS specifikus gondolat, de többnyire a megoldásban alkalmazott szerkezeti elemek tárgyaljuk a következő pontokban:
- Felépítés
- Megjelenítés
- Mozgatás
A négyzet rajzolásával, mozgatásával foglalkozó bejegyzést azzal kezdtem, hogy valóban MVP szerinti fejlesztést hajtunk végre. A kommentekből és az azok nyomán kialakult vitából látható, hogy nem teljesen sikerült megfelelnem az említett minta által támasztott követelményeknek.
Néhány javítást eszközöltem tehát!
A zárt platformnak megvannak a maga igencsak nem elhanyagolható előnyei. Amikor először ültem neki megvizsgálni, hogy mit is jelent az írjunk univerzális alkalmazást – azaz készítsünk olyan app-ot, amely akár iPhone-ra, akár iPad-re telepíthatő és alkalmazkodva az adott megjelenítő méreteihez tökéletesen működik -hát valahogy mára számítottam.
Egy másik érdekes kérdés, hogy mi történik amikor egy iPhone-ra megírt alkalmazást egy 3GS-en (320×480), illetve 4/4S-en (640×960) hajtunk végre.
Ebben a cikkben a következőkről olvashatunk:
Hogy tartsuk a POC-ok sorát, lássuk hogyan lehet WP7 esetében mozgásra bírni egy-egy tetszőleges UIElement-et a kijelzőn. Alapvetően két irányba indulhatunk el:
Egy kissé talán megtévesztő a cím, de lássuk miről is van szó valójában, mi vezetett el idáig!
A Microsoft 2010 októberében útjára indította az akkor még eléggé 1.0ás WP7-es készülékeit. Nem kellett sok ahhoz, hogy néhány lelkes “amatőr” (több ezren estek neki világszerte, a hírek szerint) elkészítse hozzá, az iPhone-on már jól ismert “Jailbreak” megoldást. Többen elértek kisebb-nagyobb sikert, de végül a ChewronWP7 unlock tool lett a befutó, ami gyorsan kezdett terjedni.
Continue reading
Na akkor ideje már a sok kutatás után végre valamire használni azt a rengeteg tudást amit eddig összeszedtünk. Akár neki lehetne ugrani a FlatCube legfőbb komponensét kidolgozni, de bemelegítésként talán megteszi egy részlet is belőle. Készítsük el a kocka egy sorát. Gondolkozzunk el a mozgatás és az animáció felhasználásának lehetőségein, próbáljuk meg kitalálni a platformra leginkább illeszkedő felhasználási módot.
Ez a cikk alapvetően tervezési megfontolásokat tartalmaz, a kódolásról nem túl sok szó esik majd benne, hiszen már mindent kipróbáltunk a POC-okban. Az első részben egyfajta platform független tervet tartalmaz, melynek megvalósítása valamennyi platformon alapot képezhet majd.
A platfromonként előírt vagy javasolt tervezési minták mellett, a unit testing is fontos szerepet játszik a mind tökéletesebb minőség elérésében. Az XCode 4.2 verzió sokat fejlődött ezen a téren, de azt hiszem még mindig van egy-két homályos pont ami talán nem egyértelmű. Ezek kezelésében próbál segíteni ez a cikk, de ha ez lesz az első unit test amit megpróbálsz összehozni, akkor különösen sok használható információt találsz majd benne.
A cikkben a következők szerepelnek az egyes oldalakon:
Talán a második legelemibb része a FlatCube programnak a négyzetek megjelenítése, illetve érintéssel történő mozgatása. Bővítsük ki a korábban megírt POC-ot ezzel a két képességgel!
