Nem metrózunk iOS-en

Erősödő tendenciát mutat a Metro-felület majmolása, és egyre többen gondolják, hogy az iOS7 ebbe a minimalista irányba fog menni. Szerintem ez biztosan nem fog megtörténni. A “csempék” elsőre jópofák, újszerűnek tűnnek – főleg mivel eddig csak az iOS-t vagy annak koppintását láthattuk okostelefonokon. Viszont a Metro kb. annyira illene az iPhonehoz, mint a piros svájci sapka a zöld lódenkabáthoz.

Abban biztos vagyok, hogy Jonny Ive tovább javítja az amúgy is nagyszerű, jól kezelhető felületet, és egységessé teszi az Apple saját fejlesztésű app-jait (azaz búcsút inthetünk a levarrt szélű bőr felületeknek – amit valószínűleg nem sokan fognak visszasírni).

Viszont elsősorban funkcionalitásban bővül majd az iOS, és itt már komolyabb változásokra számítok. Kevesebb, mint egy hónap, és kiderül minden.

Addig is itt egy a témába vágó cikk: http://blog.mengto.com/simplifying-wrong-reasons/

Új App

Érkezik hamarosan a legújabb alkalmazásunk. Hiánypótló lesz, ennyit elárulhatok már most is. :)
Szabadság, Szerelem!

Shots

Gondold át!

Hajtasz a jobblétért (ez okés). Torkokat harapsz át, hogy érvényesülj (tudsz még tükörbe nézni?). Karriert (ettől a szótól valamiért írtózom) építesz. Aggódsz a nyugdíjadért (ha még magánnyugdíjpénztár tag vagy, nyugodtan nevezd magad lúzernek). Gyűjtesz a gyerekeidnek, hogy egyetemre járjanak (imádkozz, hogy ne drogokra költsék).

Aztán felszállsz egy rohadt repülőre, ami lezuhan valahol a Csendes-óceánba.

B+

Meghalt a király, éljen a király!

A régi oldal formailag és tartalmilag is elavult, úgyhogy ráfért némi ráncfelvarrás.
A régi tartalom átmentésre érdemes része fokozatosan megjelenik majd újra – a hozzászólások és fórumbejegyzések viszont nem.

Remélem, hogy az új, letisztultabb változat mindenki tetszését elnyeri.

Üdvözlettel,
Károly

Zombivadászat XCode4.x alatt

 

A zombikat XCode 4.x alatt a sémák menüben tudjuk engedélyezni (korábbi verzióknál fordítási kapcsoló volt).

Az engedélyezés után EXC_BAD_ACCESS helyett ehhez hasonló üzenettel szembesülhetünk:

“message sent to deallocated instance 0x7f33e60

Ha szerencsénk van, már ez az információ is elég a hiba megtalálásához.

 

 

Általában azonban nem így van. A végleges megoldást az Instruments nyújtja, amely rendelkezik egy úgynevezett “Zombies” sablonnal.

Segítségével a konkrét kódsorra találhatunk, ahol a többszörösen felszabadított objektumot példányosítjuk. Innen már rutinfeladat kijavítani a hibát.

6 ezredmásodperc – avagy mikor optimalizáljunk?

 

A téma egy érdekes eset kapcsán vetődött fel: időszűke miatt a performance tesztek futtatása némileg háttérbe szorult, de végül nem halogathattam tovább. Ekkor derült ki, hogy sajnos nem olyan rózsás a helyzet, mint amire számítottam. Egy átlagos képenyő megjelenítésére az indokoltnál majdhogynem fél másodperccel több időt töltött el az alkalmazás.

Fél másodperc késleltetés egy program futása során megbocsáthatatlan. Kevésnek tűnhet, de amikor sok fél másodperc összeadódik, akkor az már nagyon is érzékelhető. Csak, hogy érzékeltessem: hasonlítsuk össze egy Windows-os rendszer felállását egy Linux-szal vagy egy Mac OSX-el. Ugye? ;)

Visszatérve az eredeti problémára: mint némi nyomozás után kiderült, egy ártatlannak tűnő segédfüggvény volt a ludas. Bár nem végzett el semmilyen összetett feladatot, mégis ez a függvény járult hozzá a leginkább az említett fél másodperces késleltetéshez.
Maga a metódus 6 ms, azaz 6 ezredmásodperc alatt hajtódott végre, ami jelentéktelennek tűnhet. Azonban képernyőnként 50x (!) hívódott meg -  300 ms már a nem mindegy kategória bármely valamit is magára adó programozó számára.

Szerencsére a megoldás elég egyszerű volt: mindössze egy röpke ellenőrzést kellett elvégezni rögtön a metódus elején, hogy a bejövő érték valóban különbözik-e attól, amit be akar állítani; ha nem, akkor nem foglalkozunk vele. Ennyi.

Rutinos fejlesztőként is nehéz kiszúrni célzott mérések nélkül, hogy mi lassítja le a végrehajtást. Néha egy ártatlannak tűnő setter is “időrabló” lehet, különösen, ha feleslegesen kerül meghívásra.

[Obj-C] Delegate ellenőrzése vs respondsToSelector

Feleslegesnek tűnhet a második esetben a delegate érvényességének vizsgálata, hiszen a respondsToSelector nil-re úgyis false-t ad vissza. Azonban ez nem ilyen egyszerű: a respondsToSelector: végrehajtása során előbb meghívásra kerül az objc_msgSend metódus, amely az üzenetküldésért felelős; valami hasonló történik:

objc_msgSend( object, selector, ... )
{
    if( object == nil )
    {
        return;
    }
    else
    {
       // végrehajtás
       ...
    }
}

Tehát mindenképp megtörténik a delegate ellenőrzése, de előbb egy dinamikusan linkelt library metódus kerül meghívásra. Azzal, hogy előbb leellenőrizzük a delegate-et, ezt megspróroljuk => optimalizálás.