Is it possible to add custom class(not inherited from NSManagedObject) as Entity in CodeData?
Or that is the best way to do if I have Custom class(user profile).
I want to save some users in Core data. Problem is that my Custom class will be changed in future. So, I want that Custom class and CoreData Entity will be inherit from one class. Is it possible to do?
All entities in Core Data are instances of, or instances of subclasses of, NSManagedObject. You have no choice about this.
If you only want to save some user profiles then you should maintain a subclass of NSObject which you usually use and which is able to be created from an NSManagedObject instance (that you have fetched from the data store for that purpose). You will also need a way to create / update an NSManagedObject instance with new details from this user profile class.
If you change the user profile class but not the attributes of the entities in the Core Data model then you don't need to do a migration of the data store.
Related
I would like to know how can we manage our domain Model and NSManagedObject Model. My scenario is I have to show last 5 comments from coredata which I fetch from coredata manager class, and it returns 5 objects of Comments (:NSManagedObject) object. now I want to to fetch next n number of comments from our server API and will parse them into my domain model object Comments( inherited from NSObject).
Now I have two types of object which logically represents the same object. I want to know best practice/design pattern, how we should handle/implement this.
One obvious solution is to loop through NSManagedObject Model and populate 5 new models of my domain object derived from NSObject and then continue to fetch these objects from my APIManager class. But I want to know the best way if there it is any.
First of all, CoreData is not thread safe, so don’t use those comments objects into the controllers or the views. Isolate core data in a separate layer and transform these objects into a view model or some other form of immutable struct for the view.
Second, you can use a nsfetched result controller in a “provider” class to keep you informed automatically of what are the last 5 comments. A delegate can inform your view of when this provider data change.
You can refresh your server data in background with your api ma manager and when you get the data back, store them in coredata. If you used a nsfetched result controller, you won’t need to do anything else as coredata will automatically notify the object you setup to return you comments
I have NSObject class name TrackInfo which contains tracks info like name , artist name,thumb image etc.
I use this class as downloading data and save information to that class after parsing data.
Now I have another tab in which, I have to show some data. This is same kind of data like trackInfo. But when app is in OFFLINE, I have to make NSManagedObject. It is same as trackinfo.
Can I use NSObject class instead of NSManagedObject or Vice-Versa ?
What I basically wants to do is, I have to display track info from one class either Trackinfo (NSObject class) or NSManagedObjectClass which is used to save data when app is in offline.
Short answer is yes, you can. How? You can find a useful discussion Organising Core Data for iOS.
The long answer can be grabbed within the documentation.
NSManagedObject is a generic class that implements all the basic
behavior required of a Core Data model object. It is not possible to
use instances of direct subclasses of NSObject (or any other class not
inheriting from NSManagedObject) with a managed object context. You
may create custom subclasses of NSManagedObject, although this is not
always required. If no custom logic is needed, a complete object graph
can be formed with NSManagedObject instances.
A managed object is associated with an entity description (an instance
of NSEntityDescription) that provides metadata about the object
(including the name of the entity that the object represents and the
names of its attributes and relationships) and with a managed object
context that tracks changes to the object graph. It is important that
a managed object is properly configured for use with Core Data. If you
instantiate a managed object directly, you must call the designated
initializer (initWithEntity:insertIntoManagedObjectContext:).
About your question, it depends on what you need to achieve. If your goal is to perform a sync mechanism between your device and the server, you should set up 1) a model with a TrackInfo entity 2) a Core Data stack that relies on a persistent store like SQLite. Then you should modify TrackInfo to take into account modifications to that entity. For example, a dirty flag property (0 or 1) or a timestamp. When you do a modification on your TrackInfo you update that property. When the connection is restored you need to query against that property and sync with the server. If you choose the timestamp, the server should say what is the latest timestamp to query against.
How are discrepancies between the Core Data Editor and the custom NSManagedObject subclass handled by Xcode?
For instance, let's say in the editor I have and Entity called Person with attributes firstName and age. I then create an NSManagedObject subclass of Person from the editor and in the header of the subclass I add the attribute lastName but I don't update the editor with this new attribute.
Depends somewhat on exactly how you define the property, but usually it will be treated like a transient property, so its value will not be set when the object is retrieved from the store unless you write some custom code to set it, nor will Core Data make any attempt to save it to the store. Also you won't be able to use the property in any fetch or sort predicate that results in core data generating sqlite SQL calls.
I had a subclass of NSObject that acted as my app's main data model, with lots of properties and methods. I decided I wanted to use Core Data to saved this data, so I changed the subclass to be of NSManagedObject. I created the entity in the .xcdatamodeld and linked it with my NSManagedObject subclass. What I'm wondering is if it is okay to keep properties in my subclass that are not saved? For example, this class contains a NSOperationQueue property, but of course I don't want Core Data interacting with this property.
When you automagically create (or re-create) an NSManagedObject from an Entity you lose anything else you had in that file. It is common for people to use categories to customize the logic for NSManagedObjects. It allows you to add customization to the default NSManagedObject without changing the code in that file!
Nice and clean.
This link may be helpful: http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/objectivec/chapters/occategories.html
Yes, it is perfectly alright to have properties and methods of its own in a NSManagedObject subclass.
Additionally, if you want any of those properties to take advantage of Core Data caching mechanism, you can add them as transient to your entity model.
I'm about to implement a like functionality between a User entity and some other entity, such that User A can like an entity X. However, I'm not sure how to best implement this in Core Data.
There are two main points I need to consider:
Adding another likeable entity should be trivial
There needs to be a way to sync a Like that has been performed offline
My initial thought was to create an abstract Core Data entity Like.
A User has a to-many relationship with Like, and a Like has one User.
Then for each entity that should be likeable, I create a subclass of Like that has a to-one relationship to the likeable entity. The relationship to the User is inherited.
This way, the abstract entity Like can have attributes such as "syncedAt" and "deletedAt" so that it's possible to find out if a Like type entity has been synced to the server or not.
Does this sound reasonable or are there better ways to solve this problem in Core Data? Are there disadvantages to this design that I'm not foreseeing?
why not have a parent entity LikableEntity which your likable entityies inherit from: this could have the synchedAt attributes. The your User has a to-many relationship likedEntities which contains anything it has liked