V minulΘm dφlu naÜeho volnΘho serißlu jsme si ukßzali trochu rozsßhlejÜφ p°φklad, jak pomocφ standardnφ programßtorskΘ aplikace InterfaceBuilder sestavit u₧ivatelskΘ rozhranφ aplikace. P°itom jsme samoz°ejm∞ "implicitn∞" pou₧φvali °adu standardnφch t°φd, reprezentujφcφch prvky grafickΘho u₧ivatelskΘho rozhranφ: okna, menu, tlaΦφtka...
Dnes a v n∞kolika nßsledujφcφch pokraΦovßnφch se na tyto t°φdy, je₧ jsou sdru₧eny ve spoleΦnΘ knihovn∞ jmΘnem AppKit, podφvßme trochu blφ₧e a ukß₧eme si, jak se s nimi pracuje: nauΦφme se nap°. pracovat se schrßnkou, zobrazovat tabulky a seznßmφme se s podporou drag&drop. Nebojte se ale ₧ßdn²ch velk²ch a slo₧it²ch program∙; jak je v Cocoa zvykem, tohle vÜechno je a bude na pßr °ßdk∙...
P°ehled
Pro zaΦßtek je vhodnΘ se jen velmi rychle, letem sv∞tem, seznßmit s v∞tÜinou t°φd AppKitu - jen orientaΦn∞, abychom m∞li p°edstavu, co zde v∙bec je k dispozici a jak se to jmenuje. VÜechny t°φdy, kterΘ tvo°φ programßtorskΘ rozhranφ AppKitu, vidφme na obrßzku. AΦkoli jich nenφ tak mßlo jako ve Foundation Kitu, po°ßd jde o velmi p°φjemn∞ p°ehledn² systΘm - aplikaΦnφ knihovny, kterΘ nabφzejφ alespo≥ vzdßlen∞ podobnΘ slu₧by jako AppKit a kterΘ jsou zalo₧eny na C++, typicky obsahujφ stovky a stovky t°φd; zde jich mßme pouze n∞co mßlo p°es stovku pro pokrytφ celΘ komplexnφ sady slu₧eb od "zobrazenφ okna na obrazovceÄ a₧ po "p°evod obrßzku z TIFF na JPEGÄ nebo "zkopφrovßnφ souboru z jednoho disku na druh² s vyu₧itφm slu₧eb a rozhranφ standardnφho sprßvce soubor∙Ä. AppKit samoz°ejm∞ zahrnuje i slu₧by pro prßci se zvuky, s videozßznamy nebo s t°φrozm∞rnou grafikou OpenGL... My si ani zdaleka nebudeme popisovat vÜechny t°φdy AppKitu. Ukß₧eme si jen ty nejd∙le₧it∞jÜφ a nejzajφmav∞jÜφ jako ilustraci toho, jak se v objektov∞ orientovanΘm prost°edφ s grafick²m u₧ivatelsk²m rozhranφm pracuje pohodln∞. V dneÜnφm p°ehledu se nebudeme zmi≥ovat o t°φdßch, jejich₧ jmΘno jasn∞ napovφdß, jak² je jejich smysl: ₧e t°eba NSWindow reprezentuje okno nebo NSFont pφsmo, je asi ka₧dΘmu jasnΘ; p°φpadnΘ podrobn∞jÜφ ·daje o d∙le₧it∞jÜφch t°φdßch si ukß₧eme pozd∞ji v samostatn²ch dφlech.
Zßkladnφ grafika
Skupina t°φd oznaΦenß Graphics nabφzφ slu₧by pro kreslenφ na obrazovku. NSImage je nap°φklad libovoln² obrßzek, p°iΦem₧ NSImageRep (...representation) odpovφdß jednΘ z jeho reprezentacφ. Jeden a tent²₧ obrßzek m∙₧e b²t t°eba reprezentovßn vektorov∞ jako EPS a zßrove≥ jako n∞kolik bitov²ch map TIFF v r∙zn²ch rozliÜenφch. Za b∞hu pak aplikace programov∞ nebo automaticky vybere tu nejvhodn∞jÜφ reprezentaci. Zajφmav∞jÜφ jsou t°φdy NSBezierPath a NSAffineTransform. Mφsto mnoha proprietßrnφch grafick²ch slu₧eb, s jak²mi se setkßvßme ve starÜφch grafick²ch systΘmech, nabφzφ Cocoa plnohodnotn² grafick² systΘm postscriptovΘho typu - jakoukoli vektorovou grafiku snadno a pohodln∞ vyjßd°φme jako °adu BΘzierov²ch k°ivek s vyu₧itφm zcela obecn²ch maticov²ch transformacφ. Do tΘto skupiny pat°φ i prßce s videem nebo t°φrozm∞rn²mi objekty (OpenGL).
Co je to View
Zatφmco slu₧by, o nich₧ jsme se bavili v minulΘm odstavci, se starajφ o vlastnφ zobrazenφ dat, t°φda NSView a °ada jejφch podt°φd reprezentujφ konkrΘtnφ mφsto na obrazovce (nebo lΘpe v okn∞), kde se data zobrazφ, a zp∙sob jejich zobrazenφ. NSView dokß₧e zajistit zßkladnφ transformace. Samoz°ejm∞ se starß o o°ezßvßnφ, dokß₧e sv∙j obsah vytisknout (a jeÜt∞ v OpenStepu jej tato t°φda um∞la i odfaxovat, co₧ se spoleΦnost Apple z naprosto nepochopitelnΘho d∙vodu rozhodla zruÜit) a podobn∞. Dφky spoluprßci objekt∙ t°φdy NSView je nap°φklad mo₧nΘ doslova "naprogramovat scrollovßnφ bez programovßnφÄ - p°ipravφme-li jakΘkoli vlastnφ View ( jeho₧ obsah kreslφme pomocφ libovoln²ch slu₧eb z minulΘho odstavce), staΦφ jej prost∞ uzav°φt do NSScrollView a u₧ nemusφme d∞lat v∙bec nic jinΘho. Obsah naÜeho "obrßzkuÄ bude automaticky zobrazen v okΘnku s posuvnφky, kterΘ budou korektn∞ fungovat... Za samostatnou zmφnku stojφ takΘ t°φda NSCell a t°φdy od nφ odvozenΘ: View je nesmφrn∞ v²konnΘ a flexibilnφ, ovÜem ka₧dß legrace n∞co stojφ, a proto je takΘ pom∞rn∞ "t∞₧kΘÄ - zabere hodn∞ pam∞ti. Z toho d∙vodu je velmi ÜikovnΘ, jestli₧e u slo₧en²ch objekt∙, jako je t°eba tabulka, pou₧ijeme jen jedinΘ View pro cel² objekt, zatφmco pro zobrazenφ jednotliv²ch prvk∙ poslou₧φ jen jinß, daleko "lehΦφÄ t°φda, je₧ bude pro zobrazovßnφ vyu₧φvat veÜker² komfort nad°φzenΘho View a sama bude obsahovat jen nepatrn∞ vφce ne₧ nap°φklad textov² °et∞zec, kter² se mß zobrazit na danΘm °ßdku v danΘm sloupci.
Sprßva udßlostφ
V aplikaΦnφm programovßnφ °φkßme "udßlostÄ tomu, na co aplikace n∞jak reaguje: stisknutφ klßvesy, pohyb myÜφ, ale i t°eba p°φchod n∞jak²ch dat na sΘriovΘ rozhranφ. TradiΦn∞ programßtor musel jako jßdro aplikace p°ipravit cyklus, kter² pomocφ slu₧eb operaΦnφho systΘmu zjiÜ¥oval, je-li k dispozici n∞jakß udßlost, kterß pat°φ danΘ aplikaci, a podle toho se choval - asi n∞jak takto:
for (;;) { // event-driven programovßnφ v tradiΦnφm prost°edφ
struct Event evt;
if (get_next_event(&evt))
if (evt.type==EvtKeyboard) {
....
} else if (evt.type==EvtMouse) {
....
V₧dy Ülo o pom∞rn∞ nepohodlnou a nep°φjemnou prßci, ve kterΘ se snadno ud∞lala °ada t∞₧ko odhaliteln²ch chyb. V Cocoa je tomu zcela jinak: tento cyklus sice samoz°ejm∞ existuje, ale je skryt ve standardnφch knihovnßch a programßtor se jφm v∙bec nemusφ zab²vat. Udßlosti se automaticky p°evßd∞jφ na standardnφ zprßvy Objective C; ty jsou odesφlßny objekt∙m t°φdy NSResponder. Chceme-li tedy nap°φklad reagovat na stisknutφ klßvesy, nemusφme se v∙bec nijak zab²vat udßlostmi a jejich sprßvou - jen ve vhodnΘ instanci t°φdy NSResponder (nejspφÜ, ale ne nutn∞, v n∞jakΘm NSView, proto₧e obvykle chceme zadan² text zßrove≥ zobrazovat) implementujeme metodu -keyDown:. Pozornφ Φtenß°i si mo₧nß pamatujφ na akce InterfaceBuilderu: ano, jde vlastn∞ p°esn∞ o tent²₧ mechanismus: ovÜem₧e je vhodnΘ - a dφky objektovΘmu systΘmu takΘ snadno mo₧nΘ - pou₧φt stejn² mechanismus pro "chceme reagovat na stisknutφ tlaΦφtka myÜφ" a "chceme reagovat na stisknutφ klßvesy".
