Question

I have a project using CoreData. I use Mogenerator to generate the subclasses.

When I set the value of a property, this value isn't actually assigned. Each subsequent time I try to set the value, the previous value I set it to was not assigned.

This worked fine as my underlying data framework was Mantle, but since moving to CoreData, this stopped working. I rely on KVO to keep some UIView objects up-to-date with the model.

Again, the ivars of a CoreData NSManagedObject subclass do not seem to take the values I assign them.

Consider the following interface:

@interface Light : _Light{}

/**
 Light / Color Properties
 */
@property (nonatomic, assign) CGFloat brightness; // 0...1
@property (nonatomic, assign) CGFloat hue;  // 0...1
@property (nonatomic, assign) CGFloat saturation;  // 0...1
@property (nonatomic, assign, getter = isEnabled) BOOL enabled;

@property (nonatomic, readonly) UIColor *color;  // derived from the above 

- (void)setHue:(CGFloat)hue saturation:(CGFloat)saturation;  // it often makes sense to set these together to generate fewer KVO on the color property.
@end

and the following .m file:

@interface Light ()
{    
    CGFloat _hue, _saturation, _brightness;

    UIColor *_color;  
}
@property (nonatomic, assign) BOOL suppressColorKVO;
@property (nonatomic, readwrite) UIColor *color;
@end

@implementation Light

@synthesize suppressColorKVO = _suppressColorKVO;

- (void)setHue:(CGFloat)hue saturation:(CGFloat)saturation
{
    BOOL dirty = NO;
    if (saturation != _saturation) {
        // clamp its value
        [self willChangeValueForKey:@"saturation"];
        _saturation = MIN(MAX(saturation, 0.0f), 1.0f);
        [self didChangeValueForKey:@"saturation"];
        dirty = YES;
    }
    if (hue != _hue) {
        [self willChangeValueForKey:@"hue"];
        _hue = MIN(MAX(hue, 0.0f), 1.0f);
        [self didChangeValueForKey:@"hue"];
        dirty = YES;
    }
    if (dirty) {
        if (!_suppressColorKVO) {
            [self setColor: self.color];
        }
    }
}

// other stuff... the color accessors are also custom.  Derived from the h, s, b values.

@end

I assume I'm not playing nice with CoreData, but I have no idea what's wrong. These hue, saturation, brightness are all 'transient' (not in the core data sense) because they are constantly updated by some hardware we are interfacing with so there's no need to save their state.

Was it helpful?

Solution 2

In the end it had nothing to do with CoreData. This approach above DOES work with CoreData objects. You can have in a subclass some "transient" properties that exist outside of the CoreData NSManagedObject and you can create your own ivars for them, and your own accessors, and it cooperates.

In relation to this question, I have a complex system that also sends some commands to some hardware, and the hardware returns a response whether it accepted the command with the current status. It turns out I had a bug in that handler which was setting these values back to some unexpected value.

What helped me debug it were using watchpoints in the debugger. Really handy feature! You set a watchpoint and it will break in the debugger whenever the memory address of your variable is set with a new value. (A tiny bit more on that here)

OTHER TIPS

If hue and saturation are properties in your model then you should be setting their values using setPrimitiveValue:forKey: (or the associated generated primitive methods).

That said, your code all looks custom as model attributes would be NSNumber instances and mogenerator would create value methods for you. So I'm going to guess that these attributes you have aren't backed in the model and that's why they aren't being stored.

So, add the attributes to the model and access the values using the appropriate methods.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top