Overwrite NSUserDefaults values via plist - ios

I have created a default preferences plist file, and when the app is launched, I register those default values. But I allow the user to change a single setting which changes nearly all of the settings I've registered, in addition to changing each individual setting. Basically, I allow them to change a "theme" which changes almost every other stored setting. When the user does select a theme, instead of calling setObject:forKey for every single setting and manually defining what it should be for the selected theme, I am wondering if it is wise to create another plist file for each theme. I am thinking I could simply overwrite the values stored in NSUserDefaults where the keys match. And in doing so, I could also more easily detect when the app's settings are the same settings of any theme, or if they've customized a theme. I would simply detect if the value stored in NSUserDefaults equals that of the value stored in each theme plist for each key, and if any of them differ I know they have customized it and are not using a built-in theme. If I don't utilize a plist, I would have to compare each stored value against a manually defined value, therefore defining the default value for that theme in two different locations (where I set the settings when they select a theme and where I check to see if the current settings are the same settings of an available theme).
If that's an appropriate implementation, how does one overwrite existing values inNSUserDefaultsusing the values stored in a plist? If not, what would you recommend in this situation?

See, settings is a concept in your application (storing and using a UI textSettings), which is better to design with abstraction from the actual implementation (persisting in .plists, databases et cetera) in mind.
All those individual values are grouped together by a single concept, and thus can be represented by a class in your project. This class "wraps up" implementation details related to the concept. This logic becomes isolated from other parts of your program, and when you need to change it, your changes are confined to a single entity, ergo every change is less likely to break the rest of your code.
This class can be implemented like that:
/////////////
// TextSettings.h
#import <Foundation/Foundation.h>
#interface TextSettings : NSObject <NSCoding>
#property (nonatomic, strong) UIColor *mainColor;
#property (nonatomic, copy) UIFont *font;
+ (instancetype)defaultTextSettings;
#end
/////////////
// TextSettings.m
#implementation TextSettings
+ (instancetype)defaultTextSettings
{
TextSettings *textSettings = [[TextSettings alloc] init];
textSettings.font = [UIFont systemFontOfSize:14.0f];
textSettings.mainColor = [UIColor whiteColor];
return textSettings;
}
#pragma mark - NSCoding
// Read more about NSCoding on: http://nshipster.com/nscoding/
- (id)initWithCoder:(NSCoder *)aDecoder
{
self = [super init];
if (self) {
_font = [aDecoder decodeObjectForKey:#"_font"];
_mainColor = [aDecoder decodeObjectForKey:#"_mainColor"];
}
return self;
}
- (void)encodeWithCoder:(NSCoder *)aCoder
{
[aCoder encodeObject:self.font forKey:#"_font"];
[aCoder encodeObject:self.mainColor forKey:#"_mainColor"];
}
#pragma mark - Equality
- (BOOL)isEqual:(id)object
{
if (object == nil) {
return NO;
}
if ([object isKindOfClass:[self class]] == NO) {
return NO;
}
TextSettings *otherTextSettings = object;
return [self.font isEqual:otherTextSettings.font] && [self.mainColor isEqual:otherTextSettings.mainColor];
}
// You must override -hash if you override -isEqual
- (NSUInteger)hash
{
return self.class.hash ^ self.font.hash ^ self.mainColor.hash;
}
#end
When you have such an object you can:
easily test them for equality
easily archive and unarchive (serialize and deserialize) them
Equality testing
// TextSettings *myTextSettings
if ([myTextSettings isEqual:[TextSettings defaultTextSettings]]) {
// User didn't change the textSettings...
}
else {
// User changed the textSettings!
}
Serialization/deserialization
// In a controller responsible for displaying something according to textSettings.
// textSettings (self.textSettings) is a #property in this controller.
- (void)saveCurrentTextSettings
{
NSData *data = [NSKeyedArchiver archivedDataWithRootObject:self.textSettings];
[[NSUserDefaults standardUserDefaults] setObject:data forKey:#"currentTextSettings"];
}
- (void)loadTextSettings
{
NSData *data = [[NSUserDefaults standardUserDefaults] dataForKey:#"currentTextSettings"];
self.textSettings = [NSKeyedUnarchiver unarchiveObjectWithData:data];
}
That's pretty much it.
When you want to add new fields to TextSettings, you must (1) declare them as #properties, (2) add checks to -isEqual: and -hash implementations and (3) add unarchiving/archiving code to -encodeWithCoder and -initWithCoder.
That's too much! you may say, but I'd say no – it is hardly an overkill. Definitely better than searching and comparing individual values in NSUserDefaults.
UPD:
To use it as just plain settings:
// Called when user chooses new value
- (void)userDidChooseFont:(UIFont *)font
{
self.textSettings.font = font;
[self saveTextSettings];
}
- (void)saveTextSettings
{
NSData *data = [NSKeyedArchiver archivedDataWithRootObject:self.textSettings];
[[NSUserDefaults standardUserDefaults] setObject:data forKey:#"textSettings"];
}

Related

Objective-C pattern for creating mutable copies

I have many "model" objects whose properties are defined as "readonly" and shared among various components.
In some cases I need to create local mutable copies of the objects (using them for local mutable state)
I rather not implement NSMutableCopy protocol as the object should be immutable after it is created. The modified object could be "passed" around after copy+mutate operations.
Is there a suggested mechanism , or should I just implement a constructor receiving the "changed" parameters?
For example an object which parses a JSON to native types :
#interface ImmutableObject : NSObject
// various "readonly" properties
...
-(instancetype)initWithJSON:(NSDictionary *)jsonDictionary;
#property (nonatomic, readonly) MyClass1 *prop1;
#property (nonatomic, readonly) MyClass2 *prop2;
...
#property (nonatomic, readonly) NSArray<MyClass100 *> *prop100;
#end
#implementation
-(instancetype)initWithJSON:(NSDictionary *)jsonDictionary {
self = [super init];
[self parseDictionaryToNative:jsonDictionary];
return self;
}
#end
Somewhere in code:
ImmutableObject *mutated = [immutableObject mutableCopy]; // best way to accomplish this?
// change some values...
mutated.prop1 = ... // change the value to something new
self.state = [mutated copy]; // save the new object
#spinalwrap is correct, but in this case there is no reason to create the extra copy before storing it. NSMutableArray is a subclass of NSArray, so can be used anywhere an NSArray can be used (and this is very common). Same for yours. In your particular case, you'd probably do it this way:
MutableObject *mutated = [immutableObject mutableCopy]; // create an instance of MutableObject
mutated.prop1 = ... // change the value to something new
self.state = mutated; // Since `state` is an immutable type,
// attempts to mutate this later will be compiler errors
This is safe because you know that this block of code is the only block that has a reference to the mutable version of the object (because you created it here).
That said, once you've created a mutable subclass, you now need to consider the possibility that any ImmutableObject you are passed might actually be a MutableObject, and so make defensive copies (just as is done with NSArray, NSString, etc.) For example:
- (void)cacheObject:(ImmutableObject *)object {
// Need to copy here because object might really be a MutableObject
[self.cache addObject:[object copy]];
}
This is made fairly efficient by implementing copy on ImmutableObject and return self, and implementing copy on MutableObject as an actual copy, usually like this:
ImmutableObject.m
- (ImmutableObject *)copy {
return self;
}
MutableObject.m
// as in spinalwrap's example
- (MutableObject *)mutableCopy {
MutableObject *instance = [MutableObject new];
instance.prop1 = [self.prop1 copy]; // depends what you want here and what kind of class the properties are... do you need a deep copy? that might be a bit more work.
// etc...
return instance;
}
// No need to duplicate code here. Just declare it immutable;
// no one else has a pointer to it
- (ImmutableObject *)copy {
return (ImmutableObject *)[self mutableCopy];
}
So the copy is almost free if the object was immutable already. I say "fairly efficient" because it still causes some unnecessary copies of mutable objects that are never mutated. Swift's copy-on-write system for value types was specifically created to deal with this problem in ObjC. But the above is the common pattern in ObjC.
note that NSMutableArray, NSMutableData etc. are different classes than their immutable counterparts. So in this case, you maybe should define a MutableObject class with the same interface as the ImmutableObject class (but with mutable properties) and use that if you want to have a mutable object.
MutableObject *mutated = [immutableObject mutableCopy]; // create an instance of MutableObject
mutated.prop1 = ... // change the value to something new
self.state = [mutated copy]; // creates an ImmutableObject
the implementation of ImmutableObject's mutableCopy could be something like:
- (MutableObject *) mutableCopy
{
MutableObject *instance = [MutableObject new];
instance.prop1 = [self.prop1 copy]; // depends what you want here and what kind of class the properties are... do you need a deep copy? that might be a bit more work.
// etc...
return instance;
}
and MutableObject's copy method could look like this:
- (ImmutableObject *) copy
{
ImmutableObject *instance = [ImmutableObject new];
instance.prop1 = [self.prop1 copy];
// etc...
return instance;
}
You're not forced to use the NSMutableCopy protocol formally, but you can.

What are the traps and tribulations when it comes to subclassing NSMutableDictionary?

Apple says
There should typically be little need to subclass NSMutableDictionary.
If you do need to customize behavior, it is often better to consider
composition rather than subclassing.
(See https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSMutableDictionary_Class/)
They should probably make this a little stronger and say pursue this at your own risk.
However, there are situations where it can be important to subclass NSMutableDictionary. In my case, notationally, it really was relevant to my code. There are quite a few hurdles to overcome. There are other web and SO entries on this, but I encountered some seemingly new issues on my travels through this, so wanted to write this up for my memory and help others. So, I'll post my answer to this. Feel free to contribute your own additional findings.
1) There are no proxy objects. At the outset, for some reason, Apple seems to have made NSMutableDictionary different in some unusual ways than NSMutableSet. My underlying need to subclass NSMutableDictionary really stems from a need to know about mutation changes to an NSMutableDictionary instance. NSMutableSets, for example, make this some what easier. NSMutableSets give you access to a "proxy" object: mutableSetValueForKey. This gives you a mechanism to know when the set contents mutate. See https://www.objc.io/issues/7-foundation/key-value-coding-and-observing/ for some details. What you'd expect to see would be something like mutableDictValueForKey but that seems to not exist.
2) Implement init in your subclass methods! Apple tells you you need to override methods:
In a subclass, you must override both of its primitive methods:
setObject:forKey:
removeObjectForKey:
You must also override the primitive methods of the NSDictionary
class.
and the NSDictionary primitive methods are:
initWithObjects:forKeys:count:
#property count
objectForKey:
keyEnumerator:
BUT, you must also override the init method!
3) Doing this in Swift doesn't work yet! At least as of the date I was trying this (about 10/8/15, and Xcode 7), you must do make your NSMutableDictionary subclass in Objective-C, not Swift. See Cannot override initializer of NSDictionary in Swift
4) NSCoding doesn't work with NSMutableDictionary subclasses! In my NSMutableDictionary subclass, I tried implementing the NSCoding protocol, but couldn't get it work in the context of keyed archivers. The keyed archiver would generate an empty NSMutableDictionary (when decoded), not my own subclass, and I don't know why. Some special NSMutableDictionary magic?
5) subscript in Swift may not cut it. I tried only implementing the subscript method for Swift (see https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Subscripts.html), but notationally this left much to be desired. I really wanted a type that was fully interoperable with NSDictionary/NSMutableDictionary, which seems to require a subclass.
6) Don't just implement the methods; you need your own data! If you just try to override the methods as above, and invoke "super" your code will not work. You need to use "composition" to internally implement an NSMutableDictionary property. Or whatever other mechanism you want for implementing your dictionary. Again, some class cluster magic going on. See my dict property in the .m file below.
Here's what I have to date in terms of my Objective-C code:
//
// SMMutableDictionary.h
// Dictionary
//
// Created by Christopher Prince on 10/6/15.
// Copyright © 2015 Spastic Muffin, LLC. All rights reserved.
//
/* I subclassed NSMutableDictionary because:
1) because I needed a way to know when a key was set or removed. With other mutable objects you can use proxy objects (e.g., see https://www.objc.io/issues/7-foundation/key-value-coding-and-observing/), but a proxy object doesn't seem to be provided by Apple for NSMutableDictionary's.
2) for notational convenience in some other code that I was writing.
*/
// QUESTION: Can I set up an observer to detect any changes to the value of the key's within the dictionary? We'd have to remove this KVO observer if the object was removed. Presumably, with this interface, the way that the object would be removed would be (a) setting with nil, and (b) deallocation of this SMMutableDictionary itself.
#import <Foundation/Foundation.h>
#class SMMutableDictionary;
#protocol SMMutableDictionaryDelegate <NSObject>
#required
// Reports on the assignment to a keyed value for this dictionary and the removal of a key: setObject:forKey: and removeObjectForKey:
- (void) dictionaryWasChanged: (SMMutableDictionary * _Nonnull) dict;
#end
#interface SMMutableDictionary : NSMutableDictionary
// For some reason (more of the ugliness associated with having an NSMutableDictionary subclass), when you unarchive a keyed archive of an SMMutableDictionary, it doesn't give you back the SMMutableDictionary, it gives you an NSMutableDictionary. So, this method is for your convenience. AND, almost even better, when you use a keyed archiver to archive, it uses our encoder method, but doesn't actually generate an archive containing our dictionary!! SO, don't use keyed archiver methods directly, use the following two methods:
- (NSData * _Nullable) archive;
+ (instancetype _Nullable) unarchiveFromData: (NSData * _Nonnull) keyedArchiverData;
// Optional delegate
#property (nonatomic, weak, nullable) id<SMMutableDictionaryDelegate> delegate;
#end
Here's the .m file:
//
// SMMutableDictionary.m
// Dictionary
//
// Created by Christopher Prince on 10/6/15.
// Copyright © 2015 Spastic Muffin, LLC. All rights reserved.
//
// I wanted to make this a Swift NSMutableDictionary subclass, but run into issues...
// See https://stackoverflow.com/questions/28636598/cannot-override-initializer-of-nsdictionary-in-swift
// http://www.cocoawithlove.com/2008/12/ordereddictionary-subclassing-cocoa.html
// See also https://stackoverflow.com/questions/10799444/nsdictionary-method-only-defined-for-abstract-class-my-app-crashed
// I tried only implementing the subscript method for Swift (see https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Subscripts.html), but notationally this left much to be desired. I really wanted a type that was fully interoperable with NSDictionary/NSMutableDictionary, which seems to require a subclass.
// See also http://www.smackie.org/notes/2007/07/11/subclassing-nsmutabledictionary/
#import "SMMutableDictionary.h"
#interface SMMutableDictionary()
#property (nonatomic, strong) NSMutableDictionary *dict;
#end
// See this for methods you have to implement to subclass: https://developer.apple.com/library/prerelease/ios/documentation/Cocoa/Reference/Foundation/Classes/NSMutableDictionary_Class/index.html
// HOWEVER, while they didn't say you have to subclass the init method, it did't work for me without doing that. i.e., I needed to have [1] below.
#implementation SMMutableDictionary
- (instancetype) initWithObjects:(const id _Nonnull __unsafe_unretained *)objects forKeys:(const id<NSCopying> _Nonnull __unsafe_unretained *)keys count:(NSUInteger)cnt;
{
self = [super init];
if (self) {
self.dict = [[NSMutableDictionary alloc] initWithObjects:objects forKeys:keys count:cnt];
}
return self;
}
// [1].
- (instancetype) init;
{
self = [super init];
if (self) {
self.dict = [NSMutableDictionary new];
}
return self;
}
// Both of these are useless. See the keyed archiver/unarchiver methods on the .h interface.
/*
- (void)encodeWithCoder:(NSCoder *)aCoder;
{
//[aCoder encodeObject:self.dict];
[aCoder encodeObject:self.dict forKey:#"dict"];
}
*/
/*
- (nullable instancetype)initWithCoder:(NSCoder *)aDecoder;
{
self = [super initWithCoder:aDecoder];
if (self) {
//self.dict = [aDecoder decodeObject];
self.dict = [aDecoder decodeObjectForKey:#"dict"];
}
return self;
}
*/
- (NSData * _Nullable) archive;
{
return [NSKeyedArchiver archivedDataWithRootObject:self.dict];
}
+ (instancetype _Nullable) unarchiveFromData: (NSData * _Nonnull) keyedArchiverData;
{
NSMutableDictionary *dict = [NSKeyedUnarchiver unarchiveObjectWithData:keyedArchiverData];
if (nil == dict) return nil;
return [[SMMutableDictionary alloc] initWithDictionary:dict];
}
- (NSUInteger) count;
{
return self.dict.count;
}
- (id) objectForKey:(id)aKey;
{
return [self.dict objectForKey:aKey];
}
- (NSEnumerator *)keyEnumerator;
{
return [self.dict keyEnumerator];
}
- (void) setObject:(id)anObject forKey:(id<NSCopying>)aKey;
{
[self.dict setObject:anObject forKey:aKey];
if (self.delegate) {
[self.delegate dictionaryWasChanged:self];
}
}
- (void) removeObjectForKey:(id)aKey;
{
[self.dict removeObjectForKey:aKey];
if (self.delegate) {
[self.delegate dictionaryWasChanged:self];
}
}
#end
Update on 10/9/15
To clarify what I meant by "mutation changes" (responding to #quelish below), here's a KVO example with an NSMutableDictionary. Note that the output of this does not reflect Test 1 below. I.e., a change to a key is not indicated by KVO. This example is adapted from https://developer.apple.com/library/prerelease/mac/documentation/Swift/Conceptual/BuildingCocoaApps/AdoptingCocoaDesignPatterns.html#//apple_ref/doc/uid/TP40014216-CH7-XID_5
If you do know all of the keys to your dictionary, you may be able to use KVO. See Observing NSMutableDictionary changes
//
// ViewController.swift
// Dictionary2
//
// Created by Christopher Prince on 10/9/15.
// Copyright © 2015 Spastic Muffin, LLC. All rights reserved.
//
import UIKit
private var myContext = 0
class ViewController: UIViewController {
var obj = MyObserver()
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
print("Test 1")
obj.objectToObserve.myDict["key1"] = "value1"
print("Test 2")
obj.objectToObserve.myDict = NSMutableDictionary()
}
}
class MyObjectToObserve: NSObject {
dynamic var myDict = NSMutableDictionary()
override var description : String {
return "\(myDict)"
}
}
class MyObserver: NSObject {
var objectToObserve = MyObjectToObserve()
override init() {
super.init()
objectToObserve.addObserver(self, forKeyPath: "myDict", options: NSKeyValueObservingOptions(rawValue: 0), context: &myContext)
}
override func observeValueForKeyPath(keyPath: String?, ofObject object: AnyObject?, change: [String : AnyObject]?, context: UnsafeMutablePointer<Void>) {
if context == &myContext {
//let newValue = change?[NSKeyValueChangeNewKey]
print("change: \(change)")
print("object: \(object)")
} else {
super.observeValueForKeyPath(keyPath, ofObject: object, change: change, context: context)
}
}
deinit {
objectToObserve.removeObserver(self, forKeyPath: "myDate", context: &myContext)
}
}

How add NSDictionary to EKEvent

i would like to add extra data to EKEvent, i tried NSDictionary (there is a lot of data to add) but it doesn't work..
sample code:
NSMutableDictionary *dictionary = [[NSMutableDictionary alloc]init];
[eventStore setValue:dictionary forKey:MAIN_DICTIONARY];
any ideas?
You're using setValue:forKey: in a wrong way. That a look here. There are different options to achieve what you want: category, subclassing or create a class that contains the EKEvent and the NSMutableDictionary. It depends on how you need to use the EKEvent.
You cannot do it this way, because even with key-value coding you can only set (declared or non declared) properties known by the instance. Basically the accessors (setter, getter) are executed. But there is no property MAIN_THREAD,no setter setMAIN_THREAD: in EKEvent.
If you want to extend instances of a foreign class that are created by the system (the instances, not the class), there are to ways to add data:
You create an own class, let's say MyEvent and give them a reference to the system instance (EKEvent) as a property plus the properties you need. When you get an instance of EKEvent you look-up your list of MyEventss using the identifier. With that you have the full access to your data.
You use associated objects. But you have to take care that they are not handled by the instance, i. e. while copying.
The first solution is better by far. Simple sample code:
#interface MyEvent : NSObject
#property (readonly) EKEvent* systemEvent;
#property id customProperty;
- (instancetype)eventForSystemEvent:(EKEvent*)systemEvent;
#end
#implemenation MyEvent
// Look-Up
NSMutableDictionary *eventLookUp;
+ (void)initialize
{
if( self == [MyEvent class])
{
eventLookUp = [NSMutableDictionary new];
}
}
- (instancetype)eventForSystemEvent:(EKEvent*)systemEvent
{
return eventLookUp[systemEvent.calendarItemIdentifier];
}
// Instance creation
- (instancetype)initWithSystemEvent:(EKEvent*)systemEvent
{
// Usual initializer
…
eventLookUp[systemEvent.calendarItemIdentifier] = systemEvent;
return self;
}
+ (instancetype)newEventWithSystemEvent:(EKEvent*)systemEvent
{
return [[self alloc] initWithSystemEvent:systemEvent];
}
#end
Typped in Safari

Passing multiple tags with UIButton

OK I have a specific situation. I am using a custom class to create some buttons and I can set their tag property with unique numbers like:
button.tag =[NSNumber numberWithInt:[10]];
This is very useful in another part of my program because I can access this unique tag like:
UIButton *clicked= (UIButton *) sender;
ButtonTag = [NSString stringWithFormat:#"%d", clicked.tag];
Now I want to pass one more unique property just like this. I am making this up but this is how I envision it
button.tagCREATED_BY_ME =[NSNumber numberWithInt:[9000]];
The question might be poorly worded but I don't know any better so I called it "tag".(correct wording might be element/property etc) How do I create a similar property to function just like .tag?
Thanks a lot!
arda
What do you want to achieve?
There is the possibility of adding an associative references. The good part about this, is that you don't need to sub-class it. So, start by creating a Category for the UIButton:
#interface UIButton (ExtraTag)
#property (nonatomic, retain) id extraTag;
#end
And the .m:
static char const * const ExtraTagKey = "ExtraTag";
#implementation UIButton (ExtraTag)
#dynamic extraTag;
- (id)extraTag {
return objc_getAssociatedObject(self, ExtraTagKey);
}
- (void)setExtraTag:(id)newExtraTag {
objc_setAssociatedObject(self, ExtraTagKey, newExtraTag, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
You can check the article I used.
CALayer allows Key-Value coding actually.
You can literally just do this (on any UI object):
[button.layer setValue:#(9000) forKey:#"tagCREATED_BY_ME"];
and to read it just use
[button.layer valueForKey:#"tagCREATED_BY_ME"]
Obligatory, the above is all you need to get this up and going, you're good to go.
For others, more advanced /or/ specific stuff follows:
If you need these keys to have a default value when nothing has yet been assigned to them... You can set these custom "tags" (eh) to have default return values if you name them according to a pattern. For example I start all of my layer keys name's with "customKey_". So the above would have been #"customKey_tagCREATED_BY_ME", then you can have your .m file return the default key values for any standard key like masksToBounds but then return a very specific value for your keys (aka keys that start with "customKey_") with the following method:
+(id)defaultValueForKey:(NSString *)key {
if ([key hasPrefix:#"customKey_"]) {
return #(0);
}
return [CALayer defaultValueForKey:key];
}
The reason you have to have a naming pattern (like always having the prefix "customKey_") is so you don't interfere with a CALayer's natural properties like .size and .backgroundColor, etc. Your default value you want returned will only be returned on properties (key) starting with "customKey_" or whatever naming pattern you use.
In your subclassed/custom button, you can add a string property or even an integer property whichever you feel good.
#interface CustomButton: ....
...
#property(strong) NSString *createdBy;
#end
Then you can access those as aButton.createdBy
You can also use Associated references instead of tags manipulation
#import <objc/runtime.h>
static char kThumbnailButtonAssociatedPhotoKey;
// ...
- (void)setAssociatedPhoto:(Photo *)associatedPhoto
forThumbnailButton:(UIButton *)thumbnailButton
{
objc_setAssociatedObject(thumbnailButton,
&kThumbnailButtonAssociatedPhotoKey,
associatedPhoto,
OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
- (Photo *)associatedPhotoForThumbnailButton:(UIButton *)thumbnailButton
{
return objc_getAssociatedObject(thumbnailButton,
&kThumbnailButtonAssociatedPhotoKey);
}
Now we can easily set/get the associated photo for a button:
- (void)configureThumbnailButtonForPhoto:(Photo *)photo
{
// ...
[self setAssociatedPhoto:photo
forThumbnailButton:thumbnailButton];
// ...
}
- (void)thumbnailButtonTapped
{
Photo *photo = [self associatedPhotoForThumbnailButton:thumbnailButton];
// ...
}
Blog post about tags and associated references
You can subclass UIButton.
In your subclass, add a new property:
#property (strong, nonatomic) NSNumber *tagCREATED_BY_ME;
You could look into KVC.
Or if you wanted to stick to the KISS principle - subclass UIButton and create a property.

With CoreData, if I have an #dynamic property, can I override its getter just like it was #synthesized? (Lazy Instantiation)

Using CoreData I created an entity, then I subclassed it into its own file, where it has the #propertys, then it has the #dynamic parts in the .m file.
When I want something to have a certain value if it's never been set, I always use lazy instantiation, like follows:
- (NSString *)preview {
if ([self.body length] < 200) {
_preview = self.body;
}
else {
_preview = [self.body substringWithRange:NSMakeRange(0, 200)];
}
return _preview;
}
But how do I do this with #dynamic properties? If I do the same thing, it says _preview is an undeclared property, but it's in the .h file. What do I do different to lazy instantiate it?
One standard method is to define preview as a transient attribute in the Core Data model (so that the value is not actually stored in the database), and implement a custom getter method. In your case it would look like:
- (NSString *)preview
{
[self willAccessValueForKey:#"preview"];
NSString *preview = [self primitiveValueForKey:#"preview"];
[self didAccessValueForKey:#"preview"];
if (preview == nil) {
if ([self.body length] < 200) {
preview = self.body;
} else {
preview = [self.body substringWithRange:NSMakeRange(0, 200)];
}
[self setPrimitiveValue:preview forKey:#"preview"];
}
return preview;
}
(You can provide custom getter, setter methods for #dynamic properties. However, Core Data
properties are not simply backed up by instance variables. That is the reason why you cannot
access _preview.)
If you need the preview to be re-calculated if the body attribute changes, then you
must also implement a custom setter method for body that sets preview back to nil.
For more information, read Non-Standard Persistent Attributes in the "Core Data Programming Guide".
Update: The current version of the Core Data Programming Guide does
not contain that chapter anymore. You can find an archived version
from the Way Back Machine. Of course this has to be taken with
a grain of salt since it is not part of the official documentation
anymore.
See documentation on using primitiveValueForKey:
basically:
#dynamic name;
- (NSString *)name
{
[self willAccessValueForKey:#"name"];
NSString *myName = [self primitiveName];
[self didAccessValueForKey:#"name"];
return myName;
}
- (void)setName:(NSString *)newName
{
[self willChangeValueForKey:#"name"];
[self setPrimitiveName:newName];
[self didChangeValueForKey:#"name"];
}

Resources