Přehled tříd AppKitu - MujMAC.cz - Apple, Mac OS X, Apple iPod

20. září 2005, 00.00 | Po chvíli úvodních "tanečků" kolem paradigmatu MVC a ukázky programování s využitím systémů vysoké úrovně, jež Cocoa pro MVC nabízí – Core Data pro model, Interface Builder pro view a bindings pro kontrolér – se dnes konečně pustíme do vlastních tříd knihovny AppKit.

Po chvíli úvodních "tanečků" kolem paradigmatu MVC a ukázky programování s využitím systémů vysoké úrovně, jež Cocoa pro MVC nabízí – Core Data pro model, Interface Builder pro view a bindings pro kontrolér – se dnes konečně pustíme do vlastních tříd knihovny AppKit.

Ta je trochu složitější, než byl Foundation Kit: to je ovšem samozřejmé, neboť zatímco Foundation se vlastně stará jen o nejzákladnější služby pro "engine", AppKit musí pokrýt spoustu věcí, od grafických objektů (okno, tlačítko, nabídka) přes řízení běhu aplikace (událost, event loop), standardní datovou komunikaci mezi aplikacemi (Services, schránka), a předlouhou řadu dalších služeb, až po standardní služby pro práci s dokumenty (NSDocument, NSDocumentController...).

Nejprve si zběžně projdeme většinu tříd AppKitu a řekneme si, které patří do které skupiny a k čemu slouží; pak si budeme postupně ukazovat na konkrétních příkladech jejich použití. Pokusíme se také v mezích praktických možností rozumně střídat "klasické programování" – tedy psaní zdrojového kódu – s využíváním služeb vyšší úrovně (práce na úrovni Interface Builderu, případně některých inspektorů a pomocných panelů přímo v Xcode).

Na obrázku – máte-li nainstalované vývojářské prostředí, naleznete jej v plném rozlišení úvodním článku popisu AppKitu – vidíme přehled prvé části tříd AppKitu; proberme si ty nejdůležitější z nich v témže pořadí, v němž jsou na ilustraci uvedeny.

Controller Layer

Se standardními kontroléry, representovanými třídou NSController a jejími dědici, jsme se setkali zrovna minule v příkladu jednoduché aplikace. Kontroléry spolu s (na nich vlastně nezávislým, ale úzce s nimi spolupracujícím) systémem vazeb ("bindings") umožňují velmi pohodlnou implementaci prostřední úrovně modelu MVC, "controlleru" – u jednoduchých aplikací někdy aniž bychom museli napsat jediný řádek kódu v programovacím jazyce, v běžných případech samozřejmě "trochu" programovat musíme, ale i tehdy nám kontroléry a bindings práci velmi výrazně usnadňují.

Obecně kterákoli z podtříd NSController je kontrolérem, který dokáže spravovat model odpovídající určitým standardním pravidlům, a zprostředkuje pomocí systému bindings vazbu modelu na objekty grafického uživatelského rozhraní.

Přímo třída NSObjectController se využívá poměrně málokdy: jejím "modelem" je obecný objekt, a kontrolér pouze zpřístupní jeho atributy.

Naopak s třídou NSUserDefaultsController se setkáme takřka v libovolné aplikaci: modelem jí je (prostřednictvím standardní třídy NSUserDefaults, s níž jsme se seznámili již v rámci Foundation Kitu) databáze uživatelských nastavení. Instanci kontroléru prostě navážeme na takřka libovolný objekt grafického uživatelského rozhraní – a máme hotový panel předvoleb ☺

Zbylé dvě třídy slouží pro standardní datové struktury: NSArrayController dokáže pracovat s polem obecných objektů, umí objekty do něj vkládat i z něj odebírat, dokáže udržovat informaci o vybraném objektu (nebo o více vybraných objektech), umí pole třídit... a prostřednictvím vazeb umí objekty zobrazit, nejčastěji (ale ne nutně) v tabulce. To jsme si ostatně také v minulém příkladu ukázali.

Podobně NSTreeController spravuje hierarchický strom objektů – je tedy ideální pro struktury, podobné struktuře složek a souborů na disku. Nabízí opět řadu služeb pro správu svých objektů, a nejběžnějšími objekty "view" pro něj jsou browser a hierarchická tabulka ("outline view") – v podstatě oba známe z Finderu, browseru odpovídá zobrazení ve sloupcích, hierarchické tabulce v řádcích.

Cell a View

V pořadí shora dolů jsou nyní na řadě třídy, jejichž "rodičem" je třída NSCell; nejprve si ale musíme říci něco málo o objektech "view".

Je celkem zřejmé, že všechny objekty "view" – ať je to textové pole, tlačítko, obecná plocha do níž aplikace kreslí graf, renderování komposice Quartz Composeru, nebo prostě cokoli, co je vidět – mají společnou nadtřídu, NSView, jež nabízí všechny standardní služby, související se zobrazením: kreslení, transformace souřadnic, možnost skládat "views" do hierarchické struktury, a mnoho a mnoho dalších možností.

To je samozřejmě rozumný a správný design, ale... je v něm skryt drobný podraz: představme si třeba tabulku, jež má mnoho desítek políček – každé z políček vzhledem i funkcí dosti přesně odpovídá samostatnému textovému poli; je tedy rozumné pro tato políčka využít tutéž třídu, jež textové pole representuje – NSTextField. Jenže... ono to vlastně rozumné není, neboť NSTextField je dědicem NSView, a NSView obsahuje spoustu služeb a záležitostí, jež na úrovni políčka v tabulce rozhodně nepotřebujeme: k čemu transformace souřadnic nebo hierarchická struktura – o takové věci se stará tabulka jako celek, a jejím buňkám nepříslušejí!

Steve Jobs však do firmy NeXT získal ty nejlepší objektové designéry na světě (mimochodem, je to velmi dobře vidět srovnáte-li eleganci a flexibilitu knihoven Cocoa s tou hrůzou, již nabízí daleko mladší Java!), a ti našli šalamounské řešení: "vnitřek" objektů view je vždy samostatný objekt, který nepotřebuje plnou sílu celého view – dokáže jen nakreslit sám sebe, a také – je-li odpovídající view editorem – se stará o editační služby. Třída NSTextField je tedy view, obsahující instanci třídy NSTextFieldCell: právě ta representuje vlastní textové políčko. Podobná instance NSTextFieldCell representuje buňky tabulky; v tomto případě ovšem jejím nadřízeným view není NSTextField, nýbrž NSTableView; tytéž buňky slouží v browseru a podobně.

Nyní je tedy již zřejmé, jaké je postavení tříd NSCell: representují vlastní obsah těch views – obvykle se jedná o editory – jejichž funkčnost mohou smysluplně sdílet různé objekty.

Z konkrétních podtříd NSCell patří mezi nejdůležitější NSActionCell – ta je základem všech ovladačů, jež dokáží spolupracovat s ostatními objekty prostřednictvím paradigmatu akce/cíl (target/action), s nímž jsme se seznámili již dávno, na konci tohoto článku. NSImageCell representuje obrázek; NSTextFieldCell se všemi jejími podtřídami a NSBrowserCell slouží pro zobrazení (a editaci) textu. Ostatní třídy pak representují konkrétní ovladače.

Systémová hlášení

Velmi bohaté služby pro tvorbu a zobrazování nejrůznějších panelů, obsahujících hlášení, varování i chyby, nabízí třída NSAlert. Samozřejmě, že si její služby ukážeme podrobněji.

Responder příště...

S třídou NSResponder souvisí základní principy, jichž Cocoa využívá pro řízení aplikace a předávání událostí (např. stisknutí klávesy, přemístění myši a podobně) mezi jednotlivými objekty. To je poměrně komplikované; nadto má třída NSResponder řadu podtříd – necháme si to proto celé na příště.