Any advice on how to store a simple custom config class in core data. Options would be I think:
Entity with a "key" and "value" attributes - perhaps different attributes to represent different possible types (e.g. Integer16, String etc)
Custom class type entity which specific attributes for each config item I want - only catch would be that you would only ever want have one record in this entity, but the benefits would be it should be more usable I think: e.g. for the "fontSize" config items it would just be once you get the 1st record back from core data: "configRecord.fontSize". No need to access via a key-value arrangement and then cast the result or whatever.
Comments?
If there would only ever be one of these, I am not sure why you would save this information in Core Data and not simply as NSUserDefaults. Don't get me wrong, I like Core Data a lot. But seems like a lot of overhead for what could be stored as a dictionary.
If you had many of these, then Core Data and your second option would enable easy searching, etc. But this is not the case.
In terms of "configRecord.fontSize" convenience, you could read in NSUserDefaults into your own custom class and provide getters/setters there - without resorting to Core Data.
Just my two cents worth ;-)
I've run with my options 2 which seems to work a treat - and lieu of any suggested disadvantages (which I haven't found yet)
Related
I have an application that tracks a user and shows where they've been using MKOverlay. How can I save this information into Core Data so that when the user wants to see where they went yesterday they can load the map/overlay from Core Data?
I have a similar project. Mine is for cycle paths. Here is how I structure my core data model:
I use an order parameter so I can work out how the points connect up. But i think you can just check the 'ordered' property of the relationship now although im not entirely sure how it works. The min / max attributes are for more efficient searches. I store the lat long values as integers to save space after a suggestion to one of my posts. You might find this useful too.
You probably want to add some attributes to the Way such as Date.
You can save any object in a core data model, but if they are not the default type like string, int, etc. you won't be able to query on them.
So you have to construct your entity with property that you will be able to query.
So I see 2 options, you save every information in an entity, but this way you will need to alloc again all objects.
Or you only save the property you will need to query and archive your object in a transformable or in a Binary Data property.
I don't know what would be best.
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 have a some classes which I need to serialize in two different ways: first- "basic" fields, and the second- some other fields.
e.g. a User class which I sometimes need to serialize just the "first name" and "last name" fields, and sometimes I need to serialize the "id" and "email"
fields as well.
The best way I found to do this so far is mark the basic fields with the [DataMember] attribute, and let .NET do the serializing for me, and for the rest
mark them with a customize attribute and do the serialization myself.
This solution proved to be very costly:
I first sirialize the basic attributes (as mentioned, .NET does that for me)
Then I get the property names of the fields marked with the custom attribute (using reflection namespace),
Then I try to get the those fields and their values from the object, and add their serialization to the basic serialization (not very successfully so far).....
Question is:
Is there a better way? preferbly by which .NET will do the rest of the work for me, and if not, at least one by which I don't need to go through all the
object's fields, find the relevant ones and serialize them myself..
Thank you all..
Oren,
Are you having to run these operations 1000x or more per minute? If not, all but the clumsiest of solutions will not be too costly. For exmample, if you need to do it like this, working from 2 objects is probably just fine. if you haven't actually run real timing comparisons, there's a huge chance you're wrong about what's expensive and what isn't.
But if you want to do it like this anyway, here is a solution that will only take 1% more time.
have an object, e.g., Core, for the subset, and Full for the whole thing
in the constructor of Full, instantiate a private instance of Core (composition pattern sort of). This has insignificant overhead.
Full will not have private member variables for the Core members. Full's setters and getters of the core data will refer to the private instance of Core. So no overhead.
Now you have 2 objects to serialize.
Sometimes I need instantiate CoreDateEntity to store some infomations for temporarily using.
But I needn't it be stored into DB.
currently I created a similar class which have same structures as the CoreDateEntity does.
It works well but I have to do many datas transfer between Two models.
Is there any better way to handle this?
Thanks for all the replies. but you guys just give me half answer of this. consider about this, I need place some entity without MOC into current database pool, how could I do this? I already checked the documents of CoreData, seems I didn't find API to transfer one entity from MOC to another MOC(manage object context).
According to Apple docs you can initialize a managed object without context if you specify nil as context.
- (id)initWithEntity:(NSEntityDescription *)entity insertIntoManagedObjectContext:(NSManagedObjectContext *)context
You can assign entities to different stores when you set up the data model. Have one store be the persistent store and the other an in-memory store. You can't form relationships across stores but it sounds like you don't need that.
To assign a configuration, hit the configuration tab (the one with the wrench icon) in the entity detail (where you give it its name, class and parent). When you create the persistent store, add the configuration name to the options dictionary.
Update:
I think you maybe overcomplicating things. It sounds like you have some managed objects that will be temporary and some that will persisted but sometimes you may want to save the temporary objects. I don't think you should bother trying to separate out the "temporary" objects. Doing so just adds complexity without any performance benefit. Instead, just use ordinary persisted objects and then delete the ones you don't want.
Always try the simplest solution first.
Use two different managed object context's and only save the objects from one context. Be careful not to set relationships between objects of two different context's - this doesn't work.
I can't seem to find any information in the documentation or via Google on this, but if there is something, a pointer to it would be great.
In my app, I have a Thing as a core data class. I intend to have that Thing contain many Items which has a bunch of fields in it, like order and created_date and so forth. However, there are a variety of Item types, each with their own set of fields. Ideally, I'd like to create several subclasses of Item, so that I can access all the items together in a single array or something.
In Rails, I'd use STI for this. Does Core Data support similar behaviour?
Thanks!
You can create an Item abstract entity and then have each of your unique items extend from it. Keep the relationship in the abstract so that your Thing can see all of them.
Be warned, however, that under the hood, all of those children will actually be put into a single wide table so you will need to test for performance considerations.