Question

I don’t have enough C knowledge to work out the right thing to do here.

I have a large number of NSManagedObjects that are one step down from the level I am currently working at – my view controller is displaying a table of parent objects, with a detail indicator against each one showing the number of child objects.

The user is able to create a set of filter criteria which are stored in an NSDictionary. My child objects have a complex set of calculations which they perform, based on these criteria, to determine if they pass or do not pass the filter. This is externally represented by a simple read-only boolean property.

What I would like to do is have a static variable in the child object to hold the filter settings dictionary, so that I don’t have to call out to user defaults or similar to get the filter settings for each child object.

At the point of the user creating the filter settings, I don’t have any specific pointer to a child object, and I don’t really want to create a fetch request just to get hold of one – so would something like this be appropriate?

.h:

@interface Child : NSManagedObject
+(void)setFilterSettings:(NSDictionary*)newFilterSettings;
@end

.m:

static NSDictionary *filterSettings;

@implementation Child

+(void)setFilterSettings:(NSDictionary*)newFilterSettings
{
    filterSettings = newFilterSettings;
}
@end

And when the filter settings are made:

[Child setFilterSettings:newFilterSettings];

Assuming this is valid, what, if anything, do I need to do in terms of memory management? I am using ARC.

Answer 1

There’s nothing wrong with the above code. This is the standard way to implement class variables, which do not otherwise exist in ObjC.

(Side note: I’m a huge fan of ARC, everyone should use it as soon as they can, but I still instinctively twitch when I see an unretained setter….)