Programování v Cocoa - Pár tipů a triků - MujMAC.cz - Apple, Mac OS X, Apple iPod

19. září 2006, 00.00 | Na rozloučenou s kontroléry si ukážeme několik šikovných triků a fint, jež umožňují obejít některé problémy a nedomyšlenosti v designu či implementaci kontrolérů.

Na rozloučenou s kontroléry si ukážeme několik šikovných triků a fint, jež umožňují obejít některé problémy a nedomyšlenosti v designu či implementaci kontrolérů. Samozřejmě, ideální by bylo, kdyby vše fungovalo bez nejmenších obtíží a zcela automaticky... ale zkrátka ubicumque dulce est, ibi et acidum invenies :)

Delegát browseru a vazby

První problém, na který se podíváme, nastane v případě, kdy chceme využít vedle vazeb také klasický mechanismus delegace (či datového zdroje): to se nám může mnohdy hodit, např. u browseru pro řízení toho, které objekty lze editovat; u tabulky či outline view třeba pro implementaci služby drag&drop.

Třídy grafického uživatelského rozhraní Cocoa, jež dokáží zobrazovat data získaná prostřednictvím vazeb, totiž samozřejmě nabízely dříve i starší, méně elegantní rozhraní pro získání dat: u třídy NSBrowser šlo o speciální služby delegáta, u tříd NSTableView a NSOutlineView pak o speciálního "delegáta", podléhajícího vlastnímu neformálnímu protokolu, který se nazývá datovým zdrojem. Ve všech případech pak byl princip týž: delegát nebo datový zdroj na vyžádání předal objektu grafického uživatelského rozhraní data k zobrazení.

Třídy NSBrowser, NSTableView a NSOutlineView pak hned při nastavení delegáta resp. datového zdroje ověřují, zda zadaný objekt splňuje podmínky patřičného neformálního protokolu (to není jen "přehnané defensivní programování", ale vedlejší efekt optimalizace) – a pokud tomu tak není, delegáta či datový zdroj odmítnou.

V tom je právě zakopaný pudlík: předáváme-li objektu grafického uživatelského rozhraní data prostřednictvím vazeb, služby pro předávání dat "postaru" prostřednictvím neformálního protokolu samozřejmě nepotřebujeme. Ale pokud je neimplementujeme, objekt grafického uživatelského rozhraní delegáta či datový zdroj odmítne.

Řešení je samozřejmě jednoduché, a naznačil jej již minulý odstavec – prostě implementujeme v delegátu či v datovém zdroji patřičné služby jako prázdné: to již nikterak nevadí, neboť objekty grafického uživatelského rozhraní je stejně nikdy volat nebudou, pokud jsou jim data předána prostřednictvím vazeb – kupříkladu pro browser by to tedy mohlo vypadat takto:

@implementation BrowserDelegate
...
// these methods are needed since we are a browser delegate;
// they are dummy though, for the browser is controlled through bindings
-(void)browser:(NSBrowser*)b willDisplayCell:(id)c atRow:(int)r column:(int)l {}
-(int)browser:(NSBrowser*)b numberOfRowsInColumn:(int)l {return 0;}
@end

Podobně implementujeme prázdné metody pro datový zdroj tabulky či outline view.

Změna hodnot, souvisejících se zvolenými objekty

Minulá obtíž byla jen technická a řešení bylo triviální; s touto je to malinko horší.

Představme si, že implementujeme vlastní podtřídu kontroléru – to je v reálných aplikacích zcela běžné, my jsme si jednoduchý příklad ukázali v nedávném dílu Mírná vylepšení v mezích zákona, kde jsme takto implementovali třídu Controller – a že v ní implementujeme nějaký nový atribut, jenž závisí na právě zvolených objektech. Třeba takto (ačkoli v takhle triviálním případě bychom se samozřejmě implementací vlastní metody neobtěžovali a použili bychom standardní službu @count):

-(unsigned)numberOfSelectedObjects {
  return [[self selectedObjects] count];
}

Je zřejmé, že kromě vlastní implementace nového atributu se musíme také korektně postarat o předávání informace o jeho změně: jinak by aplikace nefungovala korektně v případech, kdy bychom tento atribut použili ve vazbách – jeho hodnota by se napoprvé načetla korektně, avšak pak by se již neměnila, bez ohledu na seznam zvolených objektů.

Korektním řešením by samozřejmě mělo být prosté deklarování závislosti atributů, tak, jak jsme si to ukázali již v odstavci Odvozené atributy zhruba v polovině trochu staršího článku, v němž jsme si popisovali systém KVO:

+(void)initialize {
  [self setKeys:
    [NSArray arrayWithObject:@"selectedObjects"]
    triggerChangeNotificationsForDependentKey:
      @"numberOfSelectedObjects"];
}

Bohužel, to ale v praxi prostě a jednoduše nepomůže, a kontrolér se stále chová stejně, jako kdybychom implementovali pouze samotný accessor (nepodařilo se mi zjistit důvod, a na dotazy směrované programátorům Apple v diskusních fórech jsem nedostal odpověď; předpokládám, že příčinou budou optimalizace, jichž Apple používá pro zefektivnění práce s kontroléry).

Jestliže to však nefunguje, musíme si pomoci jinak. První, co nás napadne, asi bude explicitně posílat zprávy willChangeValueForKey:@"numberOfSelectedObjects" a didChangeValueForKey:@"numberOfSelectedObjects"; to je správné, ale jak zjistit vhodnou chvíli? Měli bychom se snad pokusit reimplementovat všechny metody, jež mění zvolené objekty? To by ale byla spousta práce, a nebylo by to moc spolehlivé...

Asi nejjednodušší a nejčistší je... prostě využít systému KVO. Může-li se kdokoli obrátit na náš kontrolér a vyžádat si posílání notifikací při změně některého z atributů, neexistuje samozřejmě žádný důvod, proč by kontrolér tyto notifikace nemohl posílat také sám sobě. Po přijetí notifikace pak již jen zavoláme patřičnou dvojici metod willChangeValueForKey:/didChangeValueForKey:.

Ukážeme si trošku jednodušší variantu, jež vychází z (obvykle splněného) předpokladu, že kontrolér není nikdy uvolněn a existuje až do chvíle ukončení aplikace (je zřejmé, že jinak bychom museli proměnnou first přemístit do properties, a přidat ještě uvolnění vazby do metody dealloc pokud by hodnota first byla NO):

-(void)observeValueForKeyPath:(NSString*)keyPath ofObject:object
  change:(NSDictionary*)change context:(void*)context {
  if ([keyPath isEqualToString:@"selectedObjects"]) {
    [self willChangeValueForKey:@"numberOfSelectedObjects"];
    [self didChangeValueForKey:@"numberOfSelectedObjects"];
  }
  [super observeValueForKeyPath:keyPath ofObject:object
    change:change context:context];
}
-(unsigned)numberOfSelectedObjects {
  static BOOL first=YES;
  if (first) // never released -> all right
    [self addObserver:self forKeyPath:@"selectedObjects"
      options:first=0 context:NULL];
  return [[self selectedObjects] count];
}