Sledování změn objektů - MujMAC.cz - Apple, Mac OS X, Apple iPod

16. února 2006, 00.00 | Druhý mechanismus, na nějž se musíme podívat, je sledování změn objektů, Key/Value Observing, KVO. Jeho úkolem je právě rozesílat podle potřeby všem prvkům GUI (či jiným objektům), jež jsou navázány na týž atribut modelu, upozornění, že došlo ke změně tohoto atributu – takže objekty mohou na změnu ihned reagovat zobrazením nové hodnoty.

V několika předcházejících článcích jsme se blíž seznámili s mechanismem KVC – Key/Value Coding, který umožňuje přístup k atributům objektů na základě jejich symbolických jmen ("keys"), zadávaných v programátorském rozhraní jako obyčejné textové objekty. Řekli jsme si také, že jakkoli systém KVC samozřejmě můžeme volně použít kdykoli a kdekoli se nám hodí, jeho primárním a hlavním účelem je podpora obecné vazby mezi modelem a "view" (tedy grafickým uživatelským rozhraním) aplikace: právě díky systému KVC můžeme "předepsat", že nějaké textové pole representuje třeba hodnotu "autor.name", a knihovní kód se pak automaticky postará o to, že pole je vyplněno správnou hodnotou (získanou pomocí služby valueForKey:@"name"), a že při vložení nové hodnoty do textového pole se naopak (pomocí služby setValue:@"Pepa" forKey:@"name") model odpovídajícím způsobem změní.

Máme tedy problémy grafického uživatelského rozhraní definitivně s krku? Ale kdež: "zapomněli" jsme zatím na problém se synchronizací více různých objektů GUI, jež se odkazují na týž atribut modelu. Představme si třeba situaci, kdy je jméno autora nejen zobrazeno (a editováno) prostřednictvím textového pole, ale zároveň se pro lepší přehlednost zobrazuje v titulku odpovídajícího okna:

Pak samozřejmě můžeme snadno změnit jméno autora v textovém poli, a okno by mohlo změněnou hodnotu získat pomocí metody valueForKey:, jenže... jak se okno "dozví", že tak má učinit?

Key/Value Observing

Zde nastupuje druhý mechanismus, na nějž se musíme podívat: sledování změn objektů, Key/Value Observing, KVO. Jeho úkolem je právě rozesílat podle potřeby všem prvkům GUI (či jiným objektům), jež jsou navázány na týž atribut modelu, upozornění, že došlo ke změně tohoto atributu – takže objekty mohou na změnu ihned reagovat zobrazením nové hodnoty. Samozřejmě, že stejně jako KVC, i systém KVO je založen na symbolických jménech atributů ("keys"):

• při inicializaci se objekt GUI u modelu zaregistruje jako příjemce upozornění; k tomu slouží speciální metoda addObserver:forKeyPath:options:context:, jíž "rozumí" každý dědic třídy NSObject. Příjemcem této zprávy samozřejmě je model (tedy týž objekt, jemuž bychom mohli poslat zprávu valueForKey: nebo valueForKeyPath:, pokud bychom chtěli prostě zjistit aktuální hodnotu odpovídajícího atributu) a jejím argumentem je "key" nebo "key path" – týž textový objekt, který by mohl být argumentem zpráv valueForKey(Path):;
• kdykoli se hodnota patřičného atributu v modelu změní, systém automaticky (nevyžádáme-li si, aby tomu bylo jinak) všem zaregistrovaným zájemcům rozešle zprávu observeValueForKeyPath:ofObject:change:context:, jejímž prostřednictvím jim dá najevo, že ke změně došlo;
• pokud objekt GUI již nechce nadále přijímat upozornění na změny (třeba proto, že je deaktivován, nebo že má být záhy zrušen), může samozřejmě svou registraci také zrušit pomocí zprávy removeObserver:forKeyPath: (jež je opět implementována na úrovni třídy NSObject).

Zjednodušeně řečeno, implementace objektu GUI tak může být následující:

• při inicializaci zjistí modelový objekt, na nějž je navázán, a název ("key path") jeho atributu (obojí programátor obvykle určí pomocí grafických prostředků v aplikaci Interface Builder);
• ihned zobrazí jeho aktuální hodnotu, již získá pomocí zprávy valueForKeyPath: odeslané modelu, jejímž argumentem je název atributu;
• zároveň se u modelu zaregistruje jako příjemce informací o změně pomocí zprávy addObserver:forKeyPath:options:context:, jejímž argumentem je opět název atributu;
• při případné změně obsahu (jde-li o editovatelný objekt GUI, např. textové pole nebo třeba checkbox) prostě a jednoduše pošle modelu novou hodnotu pomocí zprávy setValue:forKeyPath: (opět užívajíc téhož jména atributu);
• konečně pak po přijetí zprávy observeValueForKeyPath:ofObject:change:context: ihned zobrazí novou hodnotu (mohla by ji získat opět pomocí zprávy valueForKeyPath:, ale jak uvidíme, nová hodnota bývá obvykle přímo součástí informace o změně);
• před případným zrušením objekt odstraní svou registraci pomocí zprávy removeObserver:forKeyPath:.

Vidíme tedy, že mechanismus je velmi podobný již známému mechanismu notifikací; skutečně jde o koncepčně podobnou službu. Asi nejvýznamnější rozdíly zde spočívají v tom, že v mechanismu KVO neexistuje žádné centrum (objekty si tedy vzájemně posílají informace o změnách přímo), a v tom, že informace o změnách nejsou odesílány programově, ale automaticky kdykoli dojde k odpovídající změně (třetím rozdílem pak je to, že informace o změně nemůže být – jako tomu je u notifikací – representována libovolnou zprávou, ale že příjemce musí implementovat standardní metodu observeValueForKeyPath:ofObject:change:context:).

Automatické a programové odesílání

Ve skutečnosti jsme v předcházejícím odstavci neuvedli celou pravdu: ano, v mechanismu KVO jsou skutečně standardně informace o změnách odesílány automaticky kdykoli dojde k odpovídající změně; programátor však má možnost pro dosažení vyšší efektivity automatické odesílání zpráv vypnout, a nahradit je odesíláním programovým.

Na konkrétní detaily tohoto postupu – stejně jako na další možnosti, jež systém KVO nabízí – se však již ale podíváme příště.