I have a iphone application in which I use nsecoding for saving my objects. However it has been decided that it should be saved using core data.
The questions is - what is the best way to convert my exsisting model classes to datacore classes. Should I create a new thorugh the xdatamodel editor and replace the old or what is the best strategy. I have not figure out an easy way to do this :P
Regards
Bjarke
Roughly, what you will need to do is this:
Create a data model that reflects the classes that you have already created - and I think you'll have to do it by hand in the model editor.
Then change your classes so they become subclasses of NSManagedObject. You'll have to make sure your properties are restricted to types handled by Core Data, of course.
Related
Its more of a best practices sort of question. Here it goes...
I have automatically generated some classes for my entities in core data , now I want to use them as model objects to convert those models in JSON and send it over to the server. So my question is whether it is ok to use these classes or should I create separate classes and use a data mapper class to map these core data and model classes...
Which is a better approach and why...?
Thanks for your inputs...
You can use your NSManagedObject subclasses and add methods to those classes as you would any other NSObject class. This is perfectly acceptable (and would be better practice than to create separate object classes and using data mappers).
Use mogen to avoid the problem mentioned by #svena. It will automatically manage generation of core data models to prevent overriding your own code. Also I would suggest trying RestKit for server interactions. At least you can borrow their object serialization code because it does exactly what you want.
I have a bit confusion in choosing whether to use NSManagedObjet class objects directly as models or whether to create separate classess for models and create data mappers to map data from these model class to NSManagedObject class objects.
Is there any harm in using Core Data objects as models ? What are the pros and cons of both approches?
Thanks in advance,
Regards,
tek3
I read your question and I take it you are not asking whether to use NSManagedObject directly or whether to subclass NSManagedObject, but if you should have your model as separate classes which use Core Data by explicit methods written by yourself.
Core Data is designed to act as the model layer for your application. I do not see any real benefits in having your own model classes, writing an interface for them and implementing it in core data behind the scenes, unless you really need the freedom to give up core data entirely at some point.
I recommend you create your model classes as subclasses of NSManagedObject. You are free to extend those in any way you deem necessary beyond what core data provides you, but at the same time your model classes will have full benefits from the core data framework: faulting, caching, data integrity assurances, cascade deletes, etc...
If you just use NSManagedObject, you will not have the benefit of the convenient "dot.notation" when referring to attributes and relationships.
Also, you will have to retrieve all values with valueForKey and set them with setValueForKey followed by strings. This can be extremely error prone and cumbersome and the resulting code is not nearly as readably as with the dot notation.
Finally, in your object classes you can implement all kinds of additional functionality. Where would you put this code otherwise? Remember the principle of encapsulation that helps produce independent and reusable code.
Can Core Data allow me to create new table programmatically? or if I need that I need to use SQLite directly.
thanks
From a CoreData perspective, you don't really create new tables because database tables are only one possible type of persistence store associated with the core data model.
You can, however, create new core data entities programatically using the NSEntityDescription class. In the NSEntityDescription class documentation you will find this:
Entity descriptions are editable until they are used by an object graph manager. This
allows you to create or modify them dynamically. However, once a description is used
(when the managed object model to which it belongs is associated with a persistent store
coordinator), it must not (indeed cannot) be changed. This is enforced at runtime: any
attempt to mutate a model or any of its sub-objects after the model is associated with a
persistent store coordinator causes an exception to be thrown. If you need to modify a
model that is in use, create a copy, modify the copy, and then discard the objects with
the old model.
I've never tried to modify one at runtime, so I'm not sure exactly how well this works when you have an existing SQLite persistence store, if at all. But it's probably worth playing around with NSEntityDescription to see if it gets you close to what you are trying to do.
You typically create the managed object model graphically using Xcode's Data Model Design tool. (If you wish you can construct the model programmatically at runtime
Core Data programming Guide
You can however:
Create a Object Model Context (outside of the current one you are in/using)
Create one or more Entities
Create a SEPARATE persistent store for that model
Save entities etc...
Close the store when you're done
You can't change models on the fly as they are pretty much fixed when they're pulled into the runtime environment.
I have a list of objects that can sometimes change, and I want to keep a persistent cache on the device whenever the app is closed or move to the background.
Most of the objects in the list will not change, so i was wondering what is the best way to save the list. I have two major options i think about:
Using NSKeyedArchiver / unArchiver - This is the most convenient method, because the objects i'm serializing hold other custom objects, so this way i can just write a custom encode method for each of them. The major problem is that i didn't find on Google how to serialize only the changed objects, and serializing the entire list every time seems very wasteful.
Using SQLite - this is what i'm currently using, and the worst problem here is that adding \ changing properties of the objects is very complicated, and much less elegant.
Is there any way that i can enjoy the convenience of NSKeyedArchiver but only serialize the changed objects?
Like Adam Ko I would suggest using Core Data:
This kind of problem is what it's really good at, after all!
If your cache items are independent from each other, this could be achieved by simply wrapping your cache-items by a thin layer of NSManagedObject (i.e. you could benefit from Core Data with only minor changes to your app).
This wrapper entity could store an archived version of a cache item in an attribute of type NSBinaryDataAttributeType and provide access to the unarchived object through a transient property.
See Non-Standard Persistent Attributes for an example.
I'm implementing a new iPhone app and am relatively new to Cocoa development overall. I am at the stage of choosing how the persistence layer of this app will work, and it looks like I'm basically choosing between Core Data and sqlite3.
The persisted models in this app are intended to have a schema that is loaded at runtime (from some kind of defn file, probably XML). By which I mean, this app is intended to have objects that are user-definable to some extent, e.g. the Customer type (which has certain built-in fields like "name" and "email") can be modified to have extra fields based on the user's specific needs (e.g. a user might want to add a "favourite fruit" field to their Customer type).
Having said that, will Core Data work for an app with a non-baked-in data model like this? I've just started playing around with the Core Data object designer thing in XCode and it seems like this thing wants to work with objects that have fixed fields that are compiled in.
I'm definitely trying to take the path of least resistance here, and I can see the benefits of using an Apple-supplied data framework, but don't want to start down that path if it's going to lock me into a data model that's defined at compile time.
The Core Data data model needs to be defined at compile time, but that does not mean you can't allow for custom fields to be added and used by end users.
It just means that you would define an entity for custom fields and create the fields as objects.
It is best to design a data model that meets your needs rather than think of how you would solve the problem in SQL.