Programování pro iOS - 25. Řídicí objekty rámců - MujMAC.cz - Apple, Mac OS X, Apple iPod

19. ledna 2011, 00.00 | Jak jsme si slíbili ještě před vsunutím několika dílů, popisujících taje a zákoutí "multitaskingu", budeme se v našem seriálu teď nějakou chvilku věnovat řídicím objektům rámců (tedy práci s třídou UIViewController a jejími dědici).

S těmito objekty jsme se již zběžně setkali v minulých dílech; to proto, že sestavit v iOS rozumně funkční aplikaci, která by neobsahovala minimálně jednu instanci třídy UIViewController nebo nějaké její podtřídy, je takřka nemožné (docílit by toho asi šlo, ale dalo by to strašlivou práci, a je téměř jisté, že by se taková aplikace v některých situacích chovala nestandardně a divně).

Je tedy zřejmé, že v iOS hrají řídicí objekty rámců velmi podstatnou roli; proto se na ně dnes a v několika dalších dílech podíváme podrobněji.

Co to tedy vůbec je?

Připomeňme si znovu nejzákladnější prvky správné (nejen) objektové struktury návrhu aplikace, které říkáme "MVC" podle jejích základních prvků – "Model", "View" a "Controller":

• model reprezentuje vlastní data, nad nimiž aplikace pracuje; v iOSu obvykle jde o naše vlastní třídy (často založené na standardních kontejnerech NS(Mutable)Array a NS(Mutable)Dictionary), nebo o strukturu sestavenou nad službami knihovny Core Data;

• view jsou vlastní grafické prvky, jejichž prostřednictvím se data uživateli zobrazují a pomocí nichž uživatel vkládá příkazy; v iOSu jde o objektové stromy sestavené z rámců (instancí třídy UIView nebo některé z jejích podtříd). Ve valné většině aplikací si vystačíme se zcela standardními třídami; jen výjimečně implementujeme na úrovni view vlastní třídy;

• controller pak úrovně modelu a prvků GUI propojuje: právě na jeho úrovni implementujeme vlastní aplikační logiku.

Všechny tři vrstvy by správně měly být vzájemně nezávislé a s jasně definovaným rozhraním.

Třída UIViewController v iOS je právě základem, nad nímž sestavujeme objekty pro vrstvu controller: implementuje řadu standardních služeb a vzorů chování, o něž bychom se jinak museli starat explicitně. Typická aplikace v iOS ostatně neobsahuje téměř nic jiného; jak jsme viděli i na příkladech, jimiž jsme se dosud zabývali, obvykle v ní je pouze

(a) delegát aplikace: jeho hlavním úkolem je výchozí konfigurace pracovního okna, jež vypadá téměř vždy stejně – není zde nic jiného, než umístění rámce, patřícího hlavnímu řídicímu objektu, do hlavního okna, a jeho aktivace:

    [window addSubview:viewController.view];
    [window makeKeyAndVisible];

Hlavní řídicí objekt sám je ovšem podtřídou UIViewController, a atribut view je jednou z mnoha vlastností, jež od této třídy dědí. Kromě toho delegát aplikace může podle potřeby obsluhovat základní systémové události – s těmi jsme se celkem podrobně seznámili v minulých dílech, jde o implementaci zpráv typu applicationDidEnterBackground: nebo applicationWillTerminate:.

(b) objekty grafického uživatelského rozhraní – typicky právě jedna instance UIWindow a spousta instancí vhodných podtříd UIView. Ty jsou obvykle všechny uloženy v "nibech" (v projektu tedy ve zdrojových souborech .xib, jež se do NIBů přeloží při sestavování aplikace). Výjimečně zde může být naše vlastní podtřída UIView, jež pak má odpovídající zdrojový text v projektu – jak tomu bylo u našeho kreslení čar; v praxi tomu tak ale bývá poměrně málokdy.

(c) celý zbytek aplikace je nezřídka tvořen právě implementacemi řídicích objektů rámců.

Standardně – ne bez výjimek, ale je jich velmi málo, zvláště na iPhone – v operačním systému iOS platí to, že každá samostatná obrazovka má vlastní UIViewController. Ten řídí všechny rámce, jež danou obrazovku representují: obvykle je to jeden základní rámec (nezřídka přímo instance samotné třídy UIView), který pokrývá celou obrazovku; všechny ostatní rámce mu jsou podřízeny.

Základní služby řídicích objektů

Jak uvidíme později, řídicí objekty rámců nabízejí řadu služeb, týkajících se různých situací; nejzákladnější z nich je ale přepínání obrazovek: chceme-li jednu obrazovku – třeba základní pohled na aplikační údaje – nahradit jinou – dejme tomu informacemi o tvůrci aplikace –, standardní postup je říci aktuálnímu řídicímu objektu rámce: "Hej, zobraz teď místo sebe rámce jiného řídicího objektu!"

K tomu máme k dispozici několik standardních služeb, jež odpovídají nejběžnějším aplikačním strukturám, s nimiž se v systému iOS setkáváme:

• kdykoli lze stávající UIViewController (a tedy na obrazovce jeho rámce) překrýt modálně jiným. Ten se typicky buď "přisune zespod", nebo "přetočí zezadu" – to po stisknutí standardního tlačítka (i) v pravém dolním rohu u některých aplikací –, a spravuje obrazovku tak dlouho, dokud jej zase neodstraníme;

• řídicí objekty mohou stát v hierarchické struktuře podobné té, již známe z aplikace Mail (seznam schránek > schránka > konkrétní zpráva). Tomu říká Apple "navigační uživatelské rozhraní", a odpovídající UIViewController se o ně dokáže postarat téměř automaticky, včetně udržování odpovídajících informací s přechodem zpět ve standardní horní liště na obrazovce;

• řídicí objekty mohou být representovány ikonami, uloženými při dolním okraji obrazovky v "tab-baru", podobně, jako tomu je kupříkladu ve standardní aplikaci Clock. Opět zde máme k dispozici standardní UIViewController, jehož úkolem je zajistit přepínání mezi jednotlivými "obrazovkami" – z nichž každá je samozřejmě opět representována dalším UIViewControllerem (a jeho rámci).

Kromě toho UIViewControllery nabízejí řadu pomocných služeb pro správu paměti, pro podporu změn obsahu obrazovky při rotaci zařízení a podobně.

Aplikační design

Základní design aplikace v systému iOS tedy probíhá vždy (nebo téměř vždy, s výjimkou nepatrného množství velmi speciálních aplikací, jež můžeme na této úrovni klidně zanedbat) následujícím způsobem:

• nejprve si rozvrhneme jednotlivé obrazovky, jež bude aplikace uživatelům nabízet;

• promyslíme si také mechanismus, jímž se budou vzájemně přepínat: má jít o "tab-bar", "navigační uživatelské rozhraní", nebo odlišnou strukturu?

• podle toho pak rozvrhneme UIViewControllery: pro každou obrazovku připravíme jeden, který budeme implementovat sami (právě jako podtřídu UIViewController), a pro případné složené struktury typu "tab-bar" navíc využijeme jeden standardní řídicí objekt, připravený firmou Apple, který danou strukturu zastřeší a postará se o její funkčnost;

• teprve pak pro každý řídicí objekt sestavíme odpovídající "xib" s jeho rámci a implementujeme v něm vlastní funkčnost aplikace – tedy služby, odpovídající "stisknutí tohoto tlačítka" apod. Někdy to ani nemusí být zapotřebí: obzvláště u tabulek (UITableView) se mnohdy obejdeme zcela bez "xibu", protože tabulku lze dosti snadno a pohodlně vytvořit programově a nestojí za to ji načítat z objektové sítě.

Příště se už pustíme do skutečného programování a začneme se zabývat konkrétními službami, jež nám UIViewController nabízí.