Click here for more information

KVO

The full name of KVO is key-value Observing. It can be used to monitor changes in the attribute values of an object

Use KVO

Overview KVO KeyValueObserving is an event notification mechanism provided by Apple. Allows an object to listen for changes to specific properties of another object and to receive an event when the change occurs. Because of the way KVO is implemented, this applies to properties, and objects that inherit from NSObject generally support KVO by default.

Both KVO and NSNotificationCenter are implementations of the observer pattern in iOS. The difference is that KVO is one-to-one, not one-to-many, relative to the relationship between the observed and the observer. KVO is non-invasive to the object being listened to and can be listened on without modifying its internal code.

Simple to use registered observers Method of use: addObserver: forKeyPath: options: context parameters:

  1. Observer: An object that listens for property changes. The object must implement observeValueForKeyPath: ofObject: change: context: method.
  2. KeyPath: the name of the property to be observed. Be consistent with the name of the property declaration.
  3. Options: Configures the KVO mechanism and changes the timing and content of the KVO notification
  4. Context: An object of any type passed in, which can be received in the “receive message callback” code. This is a method of passing values in KVO.

By default, only new values are accepted

NSKeyValueObservingOptionNew: receiving method used in the change after the parameters are introduced to change the new value, the key is: NSKeyValueChangeNewKey; NSKeyValueObservingOptionOld: receiving method used in change parameter to change the old value before, key is: NSKeyValueChangeOldKey; NSKeyValueObservingOptionInitial: after registration immediately call receiving method, if the configuration NSKeyValueObservingOptionNew, content contains the new value change parameters, the key is: NSKeyValueChangeNewKey; NSKeyValueObservingOptionPrior: if add this parameter, the receive method will call respectively before and after the change, a total of two times, before the change notification of change parameter contains notificationIsPrior = 1.

By default, the framework will automatically notify the registered observer when the value of the property changes after the observer implements the corresponding method registration

Remove it when you don’t need to listen

Remove the listener in a timely manner. Otherwise, after the listener is released, the listener will crash. The addObserver method should correspond to the removeObserver method one by one. Do not add listeners repeatedly and do not attempt to remove unadded listeners. When the property of the monitored object changes, the listening method will be called several times. Trying to delete a listener that has not been added causes a crash

KVO essence inquiry

First, the question

Let’s first explore creating two instance objects

Then do KVO for Person1

The test results are as follows

We only see changes in Person1 and Person2, but only in Person1

Can be listened to, and their assignment statements are the same, so we’ll check the instance object

Put a breakpoint on the instance object and print the two classes using the console

Person1.isa = NSKVONotifying_YJXPerson; self.person2.isa = YJXPerson; We find that both classes change after KVO listening

Nature of the inquiry

This happens because iOS TunTime dynamically generates a new class as shown below before listening is used

After listening to the

Elegantly-named setName method is invoked the internal Foundation _NSSetObjectValueAndNotify function, inside the _NSSetObjectValueAndNotify

1 will first call willChangeValueForKey 2, then assign the name attribute 3, and finally call didChangeValueForKey 4, and finally call the observer’s observeValueForKeyPath To tell the listener that the property value has changed.

The dealloc and class methods are overwritten in order to do some KVO to free up memory and hide the existence of the outside world for the NSKVONotifying_Person subclass

This is why we call [p1 class] and [p2 class] and the result is the Person class, which makes us think that the Person class has not changed

KVC principle

setvalue :forkey :

valueForkey :

Ask like iOS small partner attention! Like words to a like it! Thank you very much! Thank you very much! Thank you very much! — — — — — — — —

Click on the:For more information

Included: Links to original articles