quand utiliser “willChangeValueForKey” et “didChangeValueForKey”?

J'ai vu ces lignes dans un projet de démo, mais je n'arrivais pas à comprendre pourquoi il l'a fait.

[self willChangeValueForKey:@"names"];
[self didChangeValueForKey:@"names"];

Il appelle didChangeValueForKey immédiatement après willChangeeValueForKey.
Sera-t-elle un sens?

En outre, quand doit-être le bon moment pour appeler ces deux méthodes?
Merci beaucoup!! 🙂

InformationsquelleAutor Frost | 2010-06-10
  1. 49

    C'est, en fait, un anti-modèle. Vous ne devez pas appeler -willChangeValueForKey: suivie par -didChangeValueForKey: sans intervenir réel changement de propriété. Dans certains cas, cela peut masquer KVO d'autres problèmes dans votre code et de la force des observateurs de mettre à jour leur état liés à la propriété en question. En fin de compte, cependant, vous (ou l'auteur de l'exemple que vous citez) devrait résoudre le reste du code, de sorte que cet anti-modèle est inutile.

    L'utilisation correcte de -will|didChangeValueForKey: est lorsque vous modifiez une propriété sans l'aide de KVC-conforme accesseurs/mutateurs tels que le KVO mécanisme ne serait pas remarqué le changement. Pour un exemple artificiel, envisager de modifier la sauvegarde de variable d'instance pour un attribut directement:

    @interface Foo
{
   int bar;
}
@end

@implementation Foo
- (void)someMethod
{
  bar = 10;
}
@end

    KVO observateurs qui s'étaient inscrits pour la notification des changements dans la bar bien ne pas recevoir de notification de la modification de bar dans -someMethod. Pour faire le KVO machines de travail, vous pouvez modifier -someMethod:

    - (void)someMethod
{
  [self willChangeValueForKey:@"bar"];
  bar = 10;
  [self didChangeValueForKey:@"bar"];
}

    Bien sûr, il serait préférable d'utiliser un @property de déclaration et d'utiliser KVC-conforme accesseurs/mutateurs (soit codées manuellement ou @synthesized), mais c'est un exemple artificiel.

    • Merci beaucoup!
    • J'ai couru à travers le même problème. Voici un peu plus sur le KVO d'Apple developer.apple.com/library/ios/#documentation/cocoa/conceptual/...
    • Pouvez-vous me dire exactement ce que KVO des problèmes ailleurs dans mon code serait masquée par appel willChangeValue immédiatement suivie par didChangeValue? Et quand vous parlez de forcer KVO observateurs de mettre à jour leur état, voulez-vous dire que KVO changement de notification sera émise lorsque la valeur n'a pas changé, si l'on suit cet anti-modèle?
    InformationsquelleAutor Barry Wark
  2. 11

    KVO fonctionneront correctement avec le custom ouvreurs de propriétés; cela a toujours été le cas pour NSObject les classes dérivées. Le moteur d'exécution de machines cherche une invocation de la méthode de définition, et appelle implicitement "willChangeValueForKey" avant l'exécution de l'incubateur, puis appelle implicitement "didChangeValueForKey" après le setter complète.

    Vous pouvez désactiver ce comportement automatique si vous souhaitez avoir plus de contrôle fin sur KVO notifications. Comme mentionné ci-dessus, readonly propriétés dont la valeur que vous changer en modifiant la sauvegarde de ivar, ou dont les valeurs sont obtenues par calcul, sont des lieux où vous utiliseriez le manuel des notifications (bien qu'il existe un mécanisme, keyPathsAffectingValueFor, où vous pouvez dire à l'exécution que la valeur d'un bien dépend de la variation d'une autre propriété, et il enverra la notification de modification selon le cas). Pour désactiver le comportement automatique sur la base de chaque propriété, vous les mettez dans une méthode de classe + (BOOL) automaticallyNotifiesObserversOf et retour PAS.

    J'ai souvent désactiver automatique KVO notifications, parce que j'ai trouvé que KVO notification est générée lors de l'appel d'un setter, même si la valeur de la propriété est réglée à la même valeur que sa valeur actuelle (par exemple, pas de changement). Je souhaite supprimer l'inutile de notification pour des raisons d'efficacité:

    + (BOOL)automaticallyNotifiesObserversOfMyProperty
{
  return NO;
}

- (void)setMyProperty:(NSInteger)myProperty
{
  if(_myProperty != myProperty)
  {
    [self willChangeValueForKey:@"myProperty"];
    _myProperty = myProperty;
    [self didChangeValueForKey:@"myProperty"];
  }
}

    Une bonne discussion peut être trouvé dans la NSKeyValueObserving.h-tête, que vous pouvez parcourir par CMD+clic sur les noms de méthode "willChangeValueForKey" et "didChangeValueForKey" dans XCode.

    • Voulez-vous dire +keyPathsForValuesAffecting<Key> au lieu de keyPathsAffectingValueFor ?
    InformationsquelleAutor Kevin Draz
  3. 1

    Ceux qui ont à faire avec commander manuellement la valeur de clé de l'observation. Normalement, le système prend soin d'elle, mais ils vous permettent un certain contrôle. Regardez cette documentation pour comprendre quand et comment les utiliser ici.

    InformationsquelleAutor regulus6633
  4. 1

    D'accord avec Barry. Je viens de rencontrer le même problème. Voici un cas de l'utilisation de ces deux méthodes.
    J'ai déclaré une propriété en lecture seule. Je ne peux donc pas utiliser la propriété de l'accesseur pour modifier la valeur. 

    @property (nonatomic, readonly) BOOL var;

    Lorsque je veux changer le "var", j'ai besoin d'appeler ces deux méthodes manuellement. Sinon, les observateurs ne seront pas averti.

    self willChangeValueForKey:@"var"];
var = YES;
[self didChangeValueForKey:@"var"];
    • var=OUI ne compile pas. Voulez-vous dire de soi.var=OUI (qui d'ailleurs ne se compilent pas avec readonly)? Si vous voulez dire _var=OUI, qui va compiler, mais puisque vous ne l'utilisez pas l'généré setter, je ne suis pas surpris va/didChange ne sont pas appelés. J'avais utilisation de l'auto.var = OUI sans readonly.
    • Oui. Je voulais dire _var=OUI. Mon cas est de savoir comment utiliser/didChange appel à informer manuellement.
    InformationsquelleAutor yibuyiqu
  5. 0
    • Si vous voulez faire des trucs juste avant la valeur est modifiée, l'utilisation willChangeValueForKey.
    • Si vous voulez faire des trucs juste après la valeur est modifiée, l'utilisation didChangeValueForKey.

    Edit: m'ignorer, a été la lecture trop rapide Barry est bon 🙂

    InformationsquelleAutor DenverCoder9
  6. 0

    Être très prudent lors de la substitution didChangeValueForKey:. La meilleure chose est de ne pas le faire du tout. Mais si vous le faites, assurez-vous que vous appelez super, sinon vous allez avoir une fuite de mémoire comme démontré ici: https://github.com/jfahrenkrug/KVOMemoryLeak

    InformationsquelleAutor Johannes Fahrenkrug
  7. 0

    si vous réécrivez la propriété des méthodes de lecture, merci de l'utiliser.

    @property (assign, nonatomic, getter=isLogined) BOOL logined;
    InformationsquelleAutor geekduan
  8. -2

    Ce détachement, en juillet 2013, et il semble ne plus être nécessaire d'appel/didChangeValueForKey. Il semble être pris en charge automatiquement, même si vous avez un custom setter.

    • va/didChangeValueForKey est encore nécessaire d'informer les observateurs lors de la modification d'une valeur sans à l'aide des organismes de normalisation.
    InformationsquelleAutor Amir Memon