A Memory Management és a @property-k szép official Apple kiáltványa ilyen.
A delegation-t is covereltük valamelyest, de talán nem kapott kellő hangsúlyt, holott a legtöbb kommunikáció ezeken keresztül történik a UIKit alapú App-okban. Egy pár official bekezdés róla itt, hátha valamit alakít a képen.
Ez meg egy saját - magát a delegation fogalmat némileg indokolatlanul túlmisztifikáló - post, akkor íródott, amikor ezt má’ na’on meg akartam érteni.
Két aprónak tűnő dolog kapcsolódhat ide, az egyik, hogy amikor az ember delegate method-okat ír, akkor a metódus nevében általában szerepel valami, ami a küldő osztályra utal. Az image picker delegate method-jai imagePickerDidSomething: szerűek, egy scroll view delegate method pl. a scrollViewDidEndDragging:.
Szóval ha az ember egy saját protokoll-t fogalmaz (a protokollok miért/hogyannya a linkelt post-ban ottvan szépen), akkor hasonlóan célszerű eljárni (pl. egy moquuStripLoaded:, vagy valami. Hogy az implementáló osztály kódjának olvasásakor sejthető legyen, hogy ki hívja meg azt az adott method-ot.
Azé’ mondom csak, mer’ a UIKit-tel való munka nagy részre gyakorlatilag ilyen delegate method-ok implementálásából tevődik össze.
A másik dolog csak egy egyszerű elnevezés, az (assign) fajta referenciákat, tehát a sima pointer assignment-et egyre több helyen olvasom weak reference-nek. A (retain)-elt reference-t meg strong reference-nek.
A másik, ami eszembejutott, hogy miután a következő alkalmaknak amúgyis a UIKit osztályok használatáról, stack-eléséről volna célszerű szólniuk, szerintem a workshop keretein belül kezdjük el összerakni a crowdspottr-t, de legalábbis a nézeteit (a backend kommunikáció, request/response dolgok tök ráérnek). Az úgyis egy exhaustingly UIKit App lesz, ráadásul gyakorlatilag minden lényeges UIKit osztály (UIViewController, UINavigationController, UITabBarController, UITableViewController) szerepelni fog benne, illetve mindegyiket jócskán customizáljuk, ahogyan a screen-eken láttam.
Pontosabban majd úgyis elkezdem összerakni, aztán szánjunk már rá 10-15 percet alkalmanként, hogy megnézzük hogyan alakul (ezzel nekem is sokat segítünk).
Update: alvállalkozó csinálja az App-ot majd, de ettől még a nézetstruktúráját mindenképp érdemes összeszerelnünk.
A hétfői class interface-je, meg eleve’ maga a project window.
Hint-ek a hétfői session-höz
Tökjó volt, úgyértem ez így tök jó, hogy ilyen interaktívan nyomtuk, nem csak mantráztam órákat amíg ti ásítoztatok (persze valahány százalékban elkerülhetetnen).
Az assignment kicsit explicitebben:
Egy ViewController based App template-ben az alap UIViewController subclass-ben kéne akkor 3 IBOutlet. Egy UISlider, egy UILabel, meg egy UIView (vagy UIImageView valami képpel, ez up to you). A slider -1.0 és 1.0 között ha elforgatja a UIView-t -180 tól 180-ig, akkor már csak a Label-re kell rákötni az érték kiiratását.
Néhány hint szerintem sokat segít: Minden UIView osztálynak van egy transform nevű property-je, ami egy CGAffineTransform-ot vár. Ha erre rá quick helpeltek, akkor onnan már csak egy lépés (az M_PI macro itt jöhet képbe).
Aztán volt szó a multi/optional argument-es method-okról, az ide vonatkozó Apple documentation nemtudom hol van, ittvan egy stackoverflow válasz. Ez szerintem akkor kell, ha mások által extensively használt class-okat csinálunk (pl. Framework development). “Saját felhasználásra” szánt class-eknél szerintem ritkán kerül ilyesmi elő.
Az NSString formázásról itt.
Ennyi, szerintem @property-ket most ne csináljunk, simán ivar-okkal (instance variable) megvagyunk.
A PDF-ek ebből - CS193P - az előadásból vannak, az első három lecture-ből (az a srác tartja, aki csinálja a UIKit-et, érdemes megnézni - iTunes U - az első hármat). Nem dumáltunk át mindent, de bennevan minden, amiről szó volt.
