Registering change observer without calling block with initial value

[JamesBucanek]

I have a use pattern where I need to observe changes in a property and trigger special housekeeping and UI related code (like animations).

I do not, however, want to perform these actions for the initial value. As designed, Block-KVO always calls the observation code block with the initial value. I'd like the option of suppressing that behavior.

To that end, I forked the project and added a parallel set of registration methods that take a new observeInitialValue:(BOOL) parameter. So for every method like this

- (void)observeProperty:(NSString *)keyPath withBlock:(MTKBlockChange)observationBlock;

there is now a sister method named

- (void)observeProperty:(NSString *)keyPath observingInitialValue:(BOOL)initial withBlock:(MTKBlockChange)observationBlock;

The implementation is trivial. Each original registration method had the new parameter added. The implementation of the original method is now a single call to its new sister method, passing YES for the observingInitialValue: parameter:

- (void)observeProperty:(NSString *)keyPath withBlock:(MTKBlockChange)observationBlock {
	[self observeProperty:keyPath observingInitialValue:YES withBlock:observationBlock];
}

- (void)observeProperty:(NSString *)keyPath observingInitialValue:(BOOL)initial withBlock:(MTKBlockChange)observationBlock {
    ...
}

The initial call to the change block was removed from -addSettingObservationBlock: and is now the responsibility of the sender—which I think is cleaner architecturally. The initial call is now performed, or skipped, as requested in -observeObject:property:observingInitialValue:withBlock: and -observeRelationship:observingInitialValue:changeBlock:insertionBlock:removalBlock:replacementBlock:.

If this seems like a welcome addition to the project, let me know and I'll make a pull request. If not, just close the issue.

[Tricertops]

I’m not a fan of adding new optional arguments to methods. I think it woulf be nicer if the observation block had an extra BOOL isInitial argument, so you can do early return based on that.

I remember having a dedicated BOOL isSettingUp in my ViewController, which was set to YES while setting up observations you describe. Then all observation blocks checked this property and returned early, if it was YES.

Another option in limited cases is checking if oldValue is nil. The initial callback is invoked using block(self.target, nil, initialValue); with explicit nil being passed. If your property cannot have nil, it’s clear that when oldValue is nil, it’s the initial observation.

[JamesBucanek]

(1) I agree, somewhat. I also don't like overly verbose APIs, but having a complex method and a set of convenience methods that handle the typical cases is a common API pattern:

-[NSString compare:]
-[NSString compare:options:]
-[NSString compare:options:range:]
-[NSString compare:options:range:locale:]

It also maintains backwards compatibility with existing code.

(2) I don't at all like the idea of adding an additional parameter to the callback block. It shifts the burden of a one-time setup decision from the registration call to code that has to be added, and executed, in every block.

(3) Changing the callback block parameters would break all code written to-date.

(4) It doesn't address the case where skipping the initial value is needed to avoid obtaining the initial value during setup. Say the property is synthetically generated, or is lazily initialized, and we want to avoid getter side effects during registration.

Having said that, I realize that my implementation is a little short sighted. A more "future proof" solution would be to replace the observingInitialValue: parameter with an options: parameter, and define a bit-wise set of option constants.

- (void)observeProperty:(NSString *)keyPath withBlock:(MTKBlockChange)observationBlock;
- (void)observeProperty:(NSString *)keyPath options:(MTKObserveOptions)options withBlock:(MTKBlockChange)observationBlock;

A 0 or kMTKObserveDefaultOptions value for options: would emulate the existing behavior.

[JamesBucanek]

I just implemented the options: version and it looks a lot better—almost professional. :)