0

I'm currently re-writing a form controller for iOS. It's a custom object that is bound to a model, and handles editing form fields, jumping to the prev/next field, handling custom keyboards, validating data...

The first version was based on a plist for storing the form values, the form controller held all the data itself. Now I want to dissociate the storage (model) from the form controller, thus I've settled with using KVO.

For simplicity's sake, let's assume I've got a form designed to edit a time span for an absence. So it's got two fields: leaveDate and returnDate.

My model is as follows:

@interface Absence
    @property (strong, nonatomic) NSDate *leaveDate;
    @property (strong, nonatomic) NSDate *returnDate;
    @property (readonly, nonatomic) BOOL isValid;
@end

My form controller has a property model which points to this object.

When the user taps on the "leave date" text field in my XIB, the form controller hands in and presents a date picker based on the current value of my model’s leaveDate. When the user picks some other date, the form controller updates its model by using setValue:forKey:.

The isValid property is declared as being impacted by leaveDate and returnDate (using +keyPathsForValuesAffectingIsValid), and the form controller has registered for watching a change in this property, to enable/disable the submit button on the fly.

Up to this point, everything works like a charm. Now, for the twisted part:

I want my form controller to be able to handle changes in the model while it's open. Example: I've got a rule in the model that says "an absence must least at last 3 days". When the users changes the leave date, the return date is automatically adjusted if the total duration does not exceed 3 days.

So my form controller must also register for listening to changes in all properties. The problem is that it both changes the properties, and listens to changes.

That way, when the user changes leaveTime, the form controller uses setValue:forKey: to update the model, but instantly receives a KVO notification for this very change it has just made. This is unnecessary and potentially harmful (I just made the change myself, I don't need to be told I've just done it).

The only way around I found till now is un-registering just before setting the new value, then re-registering right after, like this:

[self.model removeObserver:self forKeyPath:self.currentField.key];
[self.model setValue:newValue forKey:self.currentField.key];
[self.model addObserver:self forKeyPath:self.currentField.key options:NSKeyValueObservingOptionNew context:nil];

It's working, but it's ugly, and performance-wise I doubt it's great.

Does somebody have an explanation as to how to do it better?

TL;DR

ControllerA is a registered KVO observer of Model.

ControllerB updates Model ==> ControllerA receives a KVO notification. That's fine.

ControllerA updates Model ==> ControllerA receives a KVO notification. I don't want this one.

Cyrille
  • 25,014
  • 12
  • 67
  • 90
  • What is dangerous exactly about hearing a KVO notification for a change you just made? I think that option is less 'uneccesary and potentially harmful' than removing and then re-adding yourself as a KVO observer. – occulus Feb 14 '13 at 16:02
  • I don't want to execute `textField.text = @"something";` when the last thing I did before updating the model was `textField.text = @"something";`. Imagine it's a more costly UI update (redraw of a big control, image processing...) that happens frequently (discrete control such as a slider). – Cyrille Feb 14 '13 at 16:03
  • If you can be sure that receiving notifications is in effect an idempotent operation, receiving the same notification multiple times shouldn't matter. – occulus Feb 14 '13 at 16:03
  • 2
    In some cases it's an option to rely on the KVO notification to do the actual updating of your UI even though you know 'ahead of time' it needs updating. Don't actually update your own UI when you're aware it's going to happen; just update model and wait for the KVO notification to cause the UI to update. – occulus Feb 14 '13 at 16:05
  • That's what I just discussed with my colleagues here. It's the other option, even though its behaviour is still not clear for me in the case of, say, text fields. – Cyrille Feb 14 '13 at 16:07
  • Ok. I would say that until you find a case where efficiency is really important and matters, updating the same simple UI control twice really isn't worth sweating about too much. – occulus Feb 14 '13 at 16:13

1 Answers1

2

You seem concerned about performance. I wouldn't be. Drawing is coalesced by the main run loop, so setting textField.text = @"foo"; should NOT be causing drawing, image processing, etc. to happen in-line. Typically, a setter like that will set its value and then call [self setNeedsDisplay] which just sets a flag (very cheap), and then later, at the end of the run loop, the drawing system will trigger a single redraw. You could set textField.text a thousand times, and there should still only be one draw operation.

As commenters have suggested, you should make it so your controllers are tolerant of multiple updates. If you're doing a bunch of work in-line with a setter, don't. Setters should be "dumb." They should set the value, and set a flag if necessary (like setNeedsDisplay). In situations like this, you should avoid doing "real work" in a setter.

As another commenter suggested, you could also just not bother updating the UI in-line, and let KVO ripple out the change to all the observers, including the controller that caused the change.

Really, any of these approaches would work, but I suspect that your performance concerns are unfounded. If there is a performance problem, the problem isn't that there are multiple updates, but that you're doing real work during each update, when you should be setting a flag and doing the work later.

ipmcc
  • 29,581
  • 5
  • 84
  • 147