I get the following warning when I run my app in iOS5
CoreData: warning: Relationship properties should be #dynamic, not ivars (entity foo, class foo, property bar). This will be an error in the future.
the property bar is being declared in the class as #dynamic. I would like to fix this before it becomes "an error in the future".
You should be using the Xcode to generate your MO subclasses. You will not see this error from the classes generated by the IDE.
Related
I am trying to store an array of Ints in Core Data. I have configured my model with:
Entity: Performance
Attribute: secondsSinceStart: Transformable
Within the Xcode Data Model Inspector panel I have set the attribute's custom class as [Int]
Since setting the custom class, Xcode produces the following warning:
file:///....xcdatamodel: warning: Misconfigured Property:
Performance.secondsSinceStart is using a nil or insecure value transformer.
Please switch to NSSecureUnarchiveFromDataTransformerName or a custom NSValueTransformer subclass of NSSecureUnarchiveFromDataTransformer
What do I need to do to satisfy this warning?
I have tried to "Create NSManagedObject Subclass" for this entity, but Xcode then gives an error that Multiple commands produce ....'Performance+CoreDataProperties.o'
I have a class BorderedView class which is the subclass of UIView. After migrating to swift 4 I am getting few error in this class. Can't figure out whats wrong.Please see the image
Is there any way to fix multiple errors at once by Adding '#objc' to expose this instance method to Objective-C, I actually had over 200 of these errors, after I done fixed about 70 errors, got tired sick if doing this one by one.
I tried selecting multiple of these errors in issue navigator but dont see a way of Fix at once.
The only way I see is to select one error at a time and hit Fix, ooh this is sickening, please help if you know any way.
You'll want to run the migrator – go "Edit > Convert > To Current Swift Syntax..." in Xcode, and select "Minimize Inference" for the "Swift 4 #objc inference" option (I actually didn't realise until recently that the most of what the migrator does is just automatically applying compiler fix-its).
If you're already in a Swift 4 target, you won't be able to run migration on it. You can fix this by just changing the "Swift Language Version" build setting to "Swift 3.2" for that target, and then running the migrator on it (which will switch the version back to 4).
After the migrator has run, you'll notice that the "Swift 3 #objc inference" build setting has been set to "On" – you'll want to test your program with this build setting to ensure you don't get any runtime warnings about Obj-C entrypoints that aren't marked as #objc, and then change the build setting to "Default" when done, as discussed in this Q&A.
Additionally, after migration, feel free to look over the places where #objc has been added – you may be able to neaten code up by using a single #objc extension of the given class to define a group of methods that you want to expose to Obj-C. If you're looking at a class that requires Obj-C exposure for all its compatible members, then you can mark the class #objcMembers. See this Q&A for more info on that.
You can use the #objcMembers attribute on your whole class or struct.
You need to choose the classes on which you want to apply the #objcMembers attributes.
You can follow this tutorial.
According to Apple doc:
When a Swift class introduces many new methods or properties that require behavior from the Objective-C runtime, use the #objcMembers attribute in the declaration of that class. Applying the #objcMembers attribute to a class implicitly adds the #objc attribute to all of its Objective-C compatible members. Because applying the #objc attribute can increase the compiled size of an app and adversely affect performance, only apply the #objcMembers attribute on declarations when each member needs to have the #objc attribute applied.
I'm having a strange issue that appeared with iOS 8 Beta 5 (this issue did not occur with previous versions).
I tried to create an empty project and try to replicate the issue, but I'm unable to do so, so I'm not quite sure where the issue lies.
What I'm seeing is that attempting to access methods of a custom NSManagedObject subclass results in a strange EXC_BAD_ACCESS error.
For example:
var titleWithComma: String {
return "\(self.title),"
}
This method, out of many others, causes this issue when called. However, adding a dynamic keyword before it makes the issue go away:
dynamic var titleWithComma: String {
return "\(self.title),"
}
I know I'm not giving enough info, because I honestly don't know how to pinpoint the actual issue, but can anyone explain what is possibly happening, and why adding dynamic might resolve this issue?
From Swift Language Reference (Language Reference > Declarations > Declaration Modifier)
Apply this modifier to any member of a class that can be represented
by Objective-C. When you mark a member declaration with the dynamic
modifier, access to that member is always dynamically dispatched using
the Objective-C runtime. Access to that member is never inlined or
devirtualized by the compiler.
Because declarations marked with the dynamic modifier are dispatched
using the Objective-C runtime, they’re implicitly marked with the objc
attribute.
It means that your property/method can be accessed by Objective-C code or class. Normally it happens when you sub-classing a Swift class of Objective-C base class.
This is from the prerelease Swift / Objective-C interoperability documentation:
Implementing Core Data Managed Object Subclasses
Core Data provides the underlying storage and implementation of properties in subclasses of the NSManagedObject class. Add the #NSManaged attribute before each property definition in your managed object subclass that corresponds to an attribute or relationship in your Core Data model. Like the #dynamic attribute in Objective-C, the #NSManaged attribute informs the Swift compiler that the storage and implementation of a property will be provided at runtime. However, unlike #dynamic, the #NSManaged attribute is available only for Core Data support.
So, because of some of the Objective-C runtime features that Core Data uses under the covers, Swift properties need to be specially annotated.
I'm trying to create core data application.
Some times when trying to save data, i'm seeing following error:
Error: NSInvalidArgumentException,
Reason: * -_referenceData64 only defined for abstract class. Define -[NSTemporaryObjectID_default _referenceData64]!,
Description: * -_referenceData64 only defined for abstract class. Define -[NSTemporaryObjectID_default _referenceData64]!
I didn't understand why this error is coming and how to avoid it. Can some one help me please.
Edit: The original answer below is technically correct but doesn't accurately describe the true source of the error. The runtime can't find the correct attribute but the reason it can't find it is because the entity exist in another managed object context. The OP probably never had a _referenceData64 attribute for any of his entities.
See: http://www.cocoadev.com/index.pl?TemporaryObjectIdsDoNotRespondToReferenceData
Original Answer:
You have a class that has an attribute _referenceData64. In the data model, that class is marked as "abstract'. Select the entity in data model editor and check the box below that says "abstract". If it is checked, then that is your problem.
An abstract entity is never instantiated. Unless is has a subclass, you can't actually set its attributes to any value. Abstract entities just exist to provide templates for subclasses.