I need to store int in CloudKit, but it seems neither Int 16, 32, 64 bit are supported. How do you treat this issue? I want to assign a Core Data value to a CloudKit record's attribute.
recordS.setObject(recordValue, forKey:attributeName)
#property (nonatomic) int32_t recordValue; <- declaration in Core Data header
int32_t needs to be wrapped into NSNumber
NSNumber(int: recordValue)
From the documentation:
The following classes adopt this protocol and are supported by
CloudKit:
NSString
NSNumber
NSArray
NSDate
NSData
CKReference
CKAsset
CLLocation
So your CKRecord just can't pass directly an Int from CloudKit, it needs to pass a NSNumber like so:
record["my_integer_key"] = NSNumber(value: my_record_value)
Conversely, when you want to read a CKRecord fetched from CloudKit, you can't assume it's an Int out from the box, because it's a NSNumber really :
my_integer_property = (record["my_integer_key"] as NSNumber).intValue
Related
I want to create a "business object" based on a NSDictionary. The reason for this is that I want implementations to be able to extend this object with arbitrary keys, and another reason is that I am persisting it using the convenient plist format (the objects stored are either integers, floats or strings).
The business object contains a number of predefined properties, e.g.
#property NSString* customerName;
#property NSString* productCode;
#property int count;
#property double unitPrice;
I want to serialize this, for example to a property list (this is not a strict requirement, it could be some other easy-to-use format). Preferably, the implementation of the class should be just
#synthesize customerName, productCode, count, unitPrice:
for the example above. To use this class, I want to do something like:
MyBusinessObject* obj = [MyBusinessObject businessObjectWithContentsOfFile:fileName];
obj.productCode = #"Example";
[obj setObject:#"Some data" forKey:#"AnExtendedProperty"];
[obj writeToFile:fileName atomically:YES];
You should make your class KVC complaint. KVC does the magic. Look here.Ex,
// assume inputValues contains values we want to
// set on the person
NSDictionary * inputValues;
YOURCLASS * person = [[YOURCLASS alloc] init];
[person setValuesForKeysWithDictionary: inputValues];
The "path of least resistance" turned out to be using NSCoding instead.
i have an array of some values that i use in a mathematical formula, and i want to know which is the better data structure(NSArray or NSDictionary or ...) to use? Thanks.
Any reason for not using NS(Mutable)Dictionary (NSNumber/NSString) as key / value?
You can try some thing like this:
XYPair:NSObject<NSCoding,NSCopying>
{
NSNumber *xValue;
NSNumber *yValue;
}
let the initializer be some thing like,
-(id) initWithXValue:(NSNumber*)x YValue:(NSNumber)y;
Usage:
XYPair *someEntry = [XYPair alloc] initWithXValue:[NSNumber numberWithInt:1000] YValue:[NSNumber numberWithInt:0.25]];
NSMutableDictionary *ds = [NSMutableDictionary alloc] initWithObjects:someEntry,#"1",nil];
Dont forget to implement NSCoding (requried for archiving),NSCopying(in order to qualify to be a valid key) for XYPair
I am implementing a copyWithZone method for a custom A class, in which a NSNumber pointer was declared as (retain) property
#class A <NSCopying>
{
NSNumber *num;
}
#property (nonatomic, retain) NSNumber *num; // synthesized in .m file
-(id) copyWithZone:(NSZone*) zone {
A *new = [[A alloc] init];
new.num = [num copy];
return new;
}
When I debug, I always find new.num is the same address as the self.num.
Even if I use
new.num = [NSNumber numberWithFloat: [num floatValue]];
I still get the same address. In the end, I have to use
new.num = [[[NSNumber alloc] initWithFloat:[num floatValue]] autorelease]
to achieve the result I want. I am just wondering why NSNumber complies to but does not return a new memory address when copied?
Thanks
Leo
NSNumber is immutable. Making a copy is pointless and, thus, the frameworks just return self when copy is invoked.
If a class implements NSCopying, you should mark the property as copy (not retain). -copy on immutable classes (NSString) will simply return a reference to the object (w/a bumped retain count). If passed a mutable instance, it'll be copied to an immutable instance. This prevents an external party from changing the state behind your object's back.
Not only is NSNumber immutable - for low values it as also a Flyweight.
NSNumber isn't mutable, so there is no need to force physical copying.
You should be using [[A alloc] initWithZone:zone] when implementing the NSCopying protocol.
As others have stated though, NSNumber is immutable and so returns the same object.
I am working an application in which data is being populated from an sqlite database. All database related stuff is done in the appdelegate class. I have used NSMutable array to hold objects.
I have used a separate NSObject class for properties.
I am getting the error: property 'x' with 'retain' attribute must be of object type.
My appdelegate.m file's code is as:
NSString *amovieName = [NSString stringWithUTF8String:(char *)sqlite3_column_text(compiledStatement, 0)];
NSInteger amovieId = sqlite3_column_int(compiledStatement, 1);
//problem is here the
//value of movieId is coming from database.
//But error: "must be of object type" is puzzling me.
//I am assuming to use NSNumber here.
my NSObject file's code is as:
in .h file-
NSInteger movieId;
its property as:
#property (nonatomic, retain) NSInteger movieId;
and in .m file-
#synthesize movieId;
then I have just initialize as:
-(id)initWithmovieName:(NSString *)mN movieId:(NSInteger)mId
{
self.movieName=mN;
self.movieId=mId;
return self;
}
I found another way as:
assigning value in a NSnumber object .then type caste in NSInteger.for ex;
NSNumber aNSNumbermovieID = sqlite3_column_int(compiledStatement, 1);
NSInteger amovieId = [aNSNumbermovieID integerValue];
but still I am getting the same errors(property 'x' with 'retain' attribute must be of object type).
Any suggestion?
NSInteger is a scalar and not an object. So you shouldn't retain it, it should be assigned. Changing your property will clear up the warning message. You don't need to do the NSNumber stuff that you added in.
#property (nonatomic, assign) NSInteger movieId;
It's a little confusing since NSInteger sounds like a class, but it's just a typedef for int. Apple introduced it as part of 64-bit support so that they can typedef it to the appropriately sized integer for the processor the code is being compiled for.
Just use NSNumber and you can do:
#property (nonatomic, retain) NSNumber *movieId;
I think the error is because of the #property retain for NSInteger. Assign is for primitive values like BOOL, NSInteger or double. For objects use retain or copy, depending on if you want to keep a reference to the original object or make a copy of it.
Here NSInteger is clearly not an object so you should try assign instead of retain
I'm fetching some objects out of a data store but the results aren't what I'm expecting. I'm new to CoreData but I'm fairly certain this should work. What am I missing?
Note that User is a valid managed object and that I include its header file in this code, and that UserID is a valid property of that class.
NSFetchRequest *requestLocal = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:#"User" inManagedObjectContext:messageManagedObjectContext];
[requestLocal setEntity:entity];
// Set the predicate
NSPredicate *predicate = [NSPredicate predicateWithFormat:#"ANY UserID IN %#", userList];
[requestLocal setPredicate:predicate];
// Set the sorting
... sorting details removed but exist and are fine ...
// Request the data
NSArray *fetchResults = [messageManagedObjectContext executeFetchRequest:requestLocal error:&error];
[requestLocal release];
for (int i; i < [fetchResults count]; i++) {
[fetchResults objectAtIndex:i].UserID = ...<----HERE
}
Isn't fetchResults an array of User objects? Wouldn't [fetchResults objectAtIndex:i] be a User object? Why do I get an error when building that "request for member 'UserID' in something not a structure or union"?
Sorry if this is a basic error, I'm clearly missing some basic concept. I've done a ton of searching and it seems like it should be right. (I also tried fast enumeration but it complained that fetchResults items weren't valid Objective C objects, effectively the same error, I think.)
Update:
(from comment below)
My goal is to update the object, calling saveAction after changing it.
Does the KVC method still refer to the actual object? I tried fast enumeration with:
for (User thisUser in fetchResults) {
... but it didn't like that.
I used the more generic version:
(id thisUser in fetchResults)
...but it won't let me set
[thisUser valueForKey:#"FirstName"] = anything
... insisting that there's no Lvalue.
Will:
[[thisUser valueForKey:#"FirstName"] stringWithString:#"Bob"]
... do the trick or is there a better way? Sorry, I know it's nearly a new question, but I still don't get what is in the fetchResults array.
Your fetchedResults variable contains a NSArray object. However, a NSArray can hold any arbitrary group of objects. Unlike a standard C array, there is no requirement that the NSArray objects all be of a single class.
The dot notation you are using here:
[fetchResults objectAtIndex:i].UserID =
... while a legal syntax, nevertheless confuses the compiler because the compiler has no idea what class of object is returned by [fetchResults objectAtIndex:i]. Without knowing the class it has no idea what the heck UserID is. Hence the error "request for member 'UserID' in something not a structure or union". At the very least you have to cast the return of [fetchResults objectAtIndex:i] to some class so that the complier has a clue as to what 'UserID' is.
However, you simply shouldn't use this construction even though it legal because it is dangerous. See below for the best practice form.
Understanding NSManagedObject and its subclasses can be tricky because NSManagedObject itself uses a trick called associative storage which allows any generic NSManagedObject instances to store any property of any entity defined in any model. This can confuse novices because there are multiple ways to refer to the same entities, instances and properties. Sometimes the examples use generic NSMangedObjects and setValue:forKey:/valueForKey: and other times they use objectInstance.propertyName.
Associative storage works like a dictionary attached to every instance of the NSManagedObject class. When you insert a generic NSManagedObject like this:
NSManagedObject *mo=[NSEntityDescription insertNewObjectForEntityForName:#"User"
inManagedObjectContext:self.managedObjectContext];
... you get an instance of the NSManageObject class whose associative storage keys are set to the properties of the User entity as defined in your data model. You can then set and retrieve the values using key-value coding (which has the same syntax as dictionaries) thusly:
[mo setValue:#"userid0001" forKey:#"UserID"];
NSString *aUserID=[mo valueForKey:#"UserID"];
Associative storage allows you represent any complex data model in code without having to write any custom NSManagedObject subclasses. (In Cocoa, it allows you to use bindings which let you create entire programs without writing any data management code at all.)
However, the generic NSManagedObject class is little better than a glorified dictionary whose saving and reading is handled automatically. If you need data objects with customized behaviors you need to explicitly define a NSManagedObject subclass. If you let Xcode generate the class from the entity in the data model you end up with a source file something like:
User.h
#interface User : NSManagedObject
{
}
#property (nonatomic, retain) NSString * firstName;
#property (nonatomic, retain) NSString * userID;
#property (nonatomic, retain) NSString * lastName;
#end
User.m
#import "User.h"
#implementation User
#dynamic firstName;
#dynamic userID;
#dynamic lastName;
#end
Now, you are no longer limited by to the key-value syntax of associative storage. You can use the dot syntax because the complier has a class to refer to:
User *aUser=[NSEntityDescription insertNewObjectForEntityForName:#"User"
inManagedObjectContext:self.managedObjectContext];
aUser.userID=#"userID0001";
NSString *aUserID=aUser.userID;
With all this in mind, the proper forms of reference to the fetchedResults array become clear. Suppose you want to set all userID properties to a single default value. If you use the generic NSManagedObject class you use:
for (NSManagedObject *aMO in fetchedResults) {
[aMO setValue:#"userid0001" forKey:#"UserID"];
NSString *aUserID=[aMO valueForKey:#"UserID"];
}
If you use a dedicated subclass you would use:
for (User *aUserin fetchedResults) {
aUser.userID=#"userID0001";
NSString *aUserID=aUser.userID;
}
(Note: you can always use the generic form for all NSManagedObject subclasses as well.)
Accessing your CoreData attributes by property Accessors (dot notation) will only work if you have defined a custom NSManagedObject subclass in your Model and defined properties on that class. The implementation should be #dynamic. You'll then have to cast the object to the proper class:
//Assume this exists:
#interface User : NSManagesObject
{
}
#property (nonatomic, retain) NSString* UserID;
#end
#implementation User
#dynamic UserID
#end
// You could do:
for (int i; i < [fetchResults count]; i++) {
((User*)[fetchResults objectAtIndex:i]).UserID = ... // This works
}
Or you may use KVC to access your models properties like this (without needing a class):
for (int i; i < [fetchResults count]; i++) {
[[fetchResults objectAtIndex:i] valueForKey:#"UserID"] = ... // This too
}
You would set the value using [object setValue:newValue forKey:#"UserID"] please note, that newValue needs to be an object in general and one of NSString, NSNumber, NSDate, NSSet for CoreData.
Two additional thoughts:
Your could and should use fast Enumeration on the results array:
for (id object in fetchResults) {
[object valueForKey:#"UserID"] = ...
}
I do not understand the ANY keyword in your predicate. "UserID IN %#" should do as well.
Your basic problem is that -objectAtIndex: returtns an object of type id. No accessors are defined for type id so when you use dot notation with the object returned by -objectAtIndex: the compiler assumes you mean to access a C structure member. id is a pointer type, not a structure type, hence the error you are getting.
The whole core data stuff is a red herring with regard to this issue. You'd get the same error if User was derived from NSObject and you had populated the array yourself manually.
The ways out of it are:
Use fast enumeration
for (User* aUser in theArray)
{
....
}
which is the preferred idiom if you need to iterate through the whole array
Cast the result of -objectAtIndex: to the correct type.
((User*)[theArray objectAtIndex: i]).userId;
Use the message sending syntax instead of dot notation
[[theArray objectAtIndex: i] setUserId: ...];
Personally, I'd go with 1 and 3.
for (User* aUser in theArray)
{
[aUser setUserId: ...]
}
Clearly any of the above are dangerous if you are not certain that the objects in the array are User objects. You can use -respondsToSelector: to make sure it will work if you like.