Přehled tříd AppKitu 6: dokumentový systém - MujMAC.cz - Apple, Mac OS X, Apple iPod

29. listopadu 2005, 00.00 | V přehledném popisu tříd objektového frameworku AppKit se již blížíme ke konci – v podstatě se dá říci, že právě v dnešním dílu probereme poslední z opravdu důležitých a významných skupin tříd; pak již zbudou jen drobnosti a pomocné služební třídy, s nimiž se v praxi pracuje poměrně zřídkakdy.

V přehledném popisu tříd objektového frameworku AppKit se již blížíme ke konci – v podstatě se dá říci, že právě v dnešním dílu probereme poslední z opravdu důležitých a významných skupin tříd; pak již zbudou jen drobnosti a pomocné služební třídy, s nimiž se v praxi pracuje poměrně zřídkakdy.

Zopakujme znovu obrázek, který nabízí přehled druhého bloku tříd AppKitu – prvně jsme se s ním setkali minule, kdy jsme se zabývali grafickými třídami z jeho horní části:

Je vidět, že při standardním postupu shora dolů je nyní na řadě dokumentová architektura AppKitu, jež je založena na třídách NSDocumentController, NSDocument (a několika dalších, jež s nimi spolupracují – dokumentová architektura je do systému velmi dobře integrována, takže v současnosti je paradoxně asi snazší psát aplikace, jež pracují s dokumenty – byť to znamená poměrně rozsáhlou funkčnost, zahrnující např. i grag&drop a podobně –, než aplikace, jež využívají odlišné paradigma).

Jako vždy, i nyní si samozřejmě ti, kdo mají v počítači instalováno vývojové prostředí Xcode a programátorskou dokumentaci, mohou najít obrázek v plném rozlišení v rámci úvodního článku popisu AppKitu.

Co to vůbec je "dokument"?

V kontextu aplikačního programování v Mac OS X má pojem "dokument" poměrně přesný smysl: jedná se o samostatný blok dat, representující nějakou logickou jednotku: textový dokument, tabulku (nebo skupinu tabulek) spreadsheetu, presentaci v Keynote, obrázek v Photoshopu, videoprojekt ve Final Cutu, webová stránka... Dokument může být uložen v souboru (nebo ve skupině souborů – obvykle se tvářící jako pseudosobor, "package"), nebo může být načten do paměti a aplikace s ním může pracovat.

Někdy mohou být "dokumenty" i velmi komplikované – jakkoli kupříkladu vývojové prostředí Xcode nelze označit za zcela typický případ dokumentové aplikace, přesto její projekty – byť i každý z nich obsahuje řadu dalších souborů – jsou jednoznačně dokumenty.

Naopak typické aplikace, které s dokumenty nepracují, patří ty, které v podstatě nemají žádná data ke zpracování – Calculator či hry – nebo ty, jež nabízejí pouze přístup k nějaké formě centrální databáze: AddressBook, iCal, Finder (pro něj je "databází" obsah disku).

Typicky – byť nikoli bez výjimek – je obsah dokumentu vždy zobrazen v jednom okně; titulkem tohoto okna je název souboru, z nějž byl dokument načten, a zavřením okna se zavře i celý dokument. Vedle toho můžeme mít řadu pomocných panelů, jež nad dokumentem nabízejí doplňkové služby (vyhledávání, inspektory pro nastavování atributů). Pro práci s dokumentem jako celkem existuje zcela standardizovaný mechanismus: příkazy z nabídky "File" týmž způsobem dokumenty vytvářejí, načítají ze souborů, nebo zase jejich obsah do souborů ukládají.

V podstatě vše, o čem jsme se zmínili v předcházejících odstavcích, dostaneme s dokumentovou architekturou Cocoa "zadarmo"; musíme jen implementovat funkčnost skutečného obsahu dokumentu, a převody (obvykle, byť ne nutně) objektové podoby, již dokument má v operační paměti, z a do serializované podoby, vhodné pro uložení v souboru (využijeme-li subsystém Core Data, není zapotřebí ani to – připomeňme si ukázkovou aplikaci, "napsanou" jen v Interface Builderu bez nutnosti psát jediný řádek kódu v Objective C ☺; tehdy jsme se dokumentové architektuře vyhnuli jen proto, abychom si nemuseli vysvětlovat další věci, ale aplikace by s ní paradoxně byla jednodušší – nepotřebovali bychom tolik generovaného kódu).

Popis typů a možností dokumentů

V klasických prostředích bývají typy a možnosti dokumentů, se kterými ta která aplikace pracuje, určeny programově jako důsledek konkrétní implementace – tak třeba je-li služba "Open" implementována jako otevření panelu pro *.RTF, aplikace zjevně bude pracovat s formátovanými texty.

Ne tak v Cocoa: kód, který se stará o otevírání souborů (a řadu dalších podobných služeb) je ukryt hluboko ve standardních knihovnách – kdesi uvnitř implementace třídy NSDocumentController – a my se k němu vůbec ani nepřiblížíme. Namísto toho jsou všechny důležité informace, tedy kromě jiného

• počet různých typů dokumentů, s nimiž aplikace dokáže pracovat;
• identifikace konkrétního typu dokumentu (tedy právě to, že jde o "text" který má "příponu RTF");
• možnosti, jež aplikace nad konkrétním typem dokumentu uživateli dává (import, export, editace...).

uloženy v obecném tvaru v souboru "Info.plist" jako textová data ve formátu XML. Můžeme je tam upravovat přímo, ale Xcode obsahuje dosti pohodlný editor, jehož prostřednictvím můžeme k těmto údajům přistupovat na vyšší úrovni – stačí otevřít inspektor targetu.

Jen pro doplnění: samozřejmě, že pokud potřebujeme sestoupit na nízkou úroveň a nahradit popis v konfiguračním souboru programovou implementací – třeba proto, že se seznam dokumentů, s nimiž aplikace dokáže pracovat, může dynamicky měnit – je v Cocoa možné i to; v praxi to však nastává velmi málokdy.

Konkrétní třídy

Centrální postavení má v dokumentové architektuře Cocoa třída NSDocumentController: ta úzce spolupracuje s třídou NSApplication (jež, jak už víme, representuje aplikaci jako celek), a o práci s dokumenty se stará – obvykle aniž bychom o tom vůbec potřebovali vědět ☺

Po spuštění aplikace třída NSDocumentController především načte obsah souboru "Info.plist" a podle něj se ve spolupráci s třídou NSApplication postará o všechny potřebné služby: pokusíme-li se např. na ikonu aplikace myší odvézt dokument, třída NSDocumentController automaticky ověří, zda jde o typ, jenž tato aplikace umí otevřít, a pokud ano, přijme jej. Vybereme-li z nabídky příkaz "Open", třída NSDocumentController automaticky spustí Open panel pro všechny přípustné typy... a tak dále.

Teprve ve chvíli, kdy je nový dokument vytvořen – ať již příkazem "New", nebo pro načtení obsahu ze souboru po drag&dropu či příkazu "Open" – nastane čas pro druhou hlavní třídu, NSDocument.

Pro každý typ dokumentu, s nímž naše aplikace pracuje, vytvoříme samostatnou podtřídu třídy NSDocument. Ta bude sloužit jako kontrolér dokumentu (pamatujete si ještě na strukturu MVC?), a v ní implementujeme kompletní služby a funkčnost, jež s prací s dokumentem souvisejí – minimum jsou dvě metody pro vytvoření dokumentu z objektu třídy NSData, a naopak pro uložení dokumentu do nového datového objektu. Ve třídě NSDocument je hotova předlouhá řada standardních dokumentových služeb – namátkou můžeme jmenovat údržbu nabídky "Recent Files", práci s undo/redo, ukládání nebo správu jména souboru v titulku okna – a my ji tak zdědíme a nemusíme se o ni nikterak starat.

O vše ostatní se postará třída NSDocumentController: otevře požadovaný soubor, načte jeho obsah do objektu NSData, vytvoří automaticky instanci vhodné podtřídy NSDocument podle typu načteného dokumentu, a objekt NSData mu předá.

Třída NSFileWrapper nabízí alternativní přístup s bohatšími možnostmi: chceme-li dokumenty ukládat kupříkladu do složek, prostý objekt NSData nepostačí; pak můžeme na jeho místě použít NSFileWrapper, který dokáže representovat libovolný soubor nebo skupinu souborů.

Konečně pak třída NSPersistentDocument pak již je pouze konkrétní podtřídou NSDocumentu, jež je uzpůsobena pro práci s modelem založeným na architektuře Core Data.