I'm devellopping an IOS app for one month and I feel like I'm ready to create the data base. So as I've learn at school, I took my pencil and start to create my data base design.
Then I start to read the core data guides, in fact I've already used core data but it was in smaller projects. So I read about the Managed Object and they seems to always fit exactly the model object (MVC) of the applications.
So this is my question. Does I have to write the Managed Objects as an sqlLite data base shema (with split tables etc...) and start to write some methods to construct my model objects from thoses tables ? OR should I write the managed object exaclty as the Model objects ? They will be reconstructed much easier but won't it be less efficient?
To ask it in an other way: do the core data base shema should looks like an sqlLit data base with split tables or should it looks like as a set of my Model Objects?
I hope my question is clear.
Thank you,
Alexandre
If you want to use core data, you should not, in any way interact with the SQLite database. The exact way core data stores the objects should be opaque to you.
There is nothing to stop you writing the database layer yourself. You can make and interact with an SQLite database directly and do everything yourself.
General advice is that core data has been around a long time and any issues you encounter making objects and keeping them in sync across threads, caching and speed of access have already been encountered and fixed by the core data team. Save yourself some work, Stand on the shoulders of giants and use Core Data.
Just because you have tagged your question with iOS, one of the best things you can do, is to forget about traditional model relationship techniques you have previously used in relational database (especially the one used with web applications), and structure your NSManagedObject graph depending also on the use you are doing in your UI.
This is especially true when you have something like UITableView. For example, if you are showing only title and description in a table cell, and then you have detail view with all the data, it has perfect sense to model your graph like this:
EntityMain {
NSString *title,
NSString *desc,
// other that may be useful, such as a state...ecc
toOne relationship --> EntityDesc
}
EntityDesc {
NSString *prop1,
NSString *prop2,
......
....
NSString *prop 20
}
Where EntityMain is retrieved, say, by a NSFetchedResultsController, while in the detail view you can retrieve the whole object. In this case you are not fetching more than necessary, and performance will benefit.
This will also help you in case you want to have a separated NSManagedObjectContext for detail editing.
Related
I have a static table for settings where I want to pull some stuff from an entity in Core Data. The use case does not lend itself to a table of records as you usually see. Rather each row of the static table is really a field related to the user--as in a user profile. I have a feeling that in testing I may have created more than one record in the entity. I know there are programs that let you see the SQL lite database underneath, but my question assumes you do not have this tool and are relying just on Xcode.
My question is when you have more than one record in a Core Data entity/table, and you try to load data from the managed object context into a VC, one field into one element, what record is shown by default?
Related to this, if you don't know how many managed object or rows are in the database, is there anyway to specify which record you want since there are no auto ids as you would use in a traditional database?
The record that gets loaded from the fetch first. Depending on your sort that might be consistent or it might be random.
I'm making a simple bank account tracker, for self-instructional purposes. I'm using Core Data to store three entities, related as in the screenshot:
WMMGTransaction objects are simply stored as they are recorded, and extracted as needed to feed tableviews and detail views. This will be done via NSFetchedResultsController and a predicate. I'm using MagicalRecord to access Core Data, if that matters.
My question is this:
When I pass WMMGAccount data from one VC to another, such as when creating a new account, or when selecting one from a list (via delegation as a rule), does it matter if I pass a reference to the entire entity, or can I just use an NSString bearing the .name of the account and identify the account when required with a predicate and an NSFetchedResultsController? I guess this is a strategy question, and may generate discussion, rather than having a cut and dried answer, but I'm wrestling with it, so I thought I'd ask.
It sounds like you're asking if you should pass an object to the code that needs it, or if you should pass information that could be used to look up the same object again.
Unless you need to use the managed object on a different thread or queue, you should always pass the actual object. No sense re-fetching an object you already have. It's extra work and code complexity that (unless there are some unusual extenuating details you didn't mention) won't help in any way.
If you are needing to use the object on a different queue or thread, passing information that can be used to look it up is the correct approach. But in that case-- don't pass the value of one of the properties. Use the managed object ID.
Core Data won't force name values to be unique, while the object's managedObjectID is unique. It's also faster when retrieving the object, because you can use objectForID: or existingObjectForID: instead of performing a fetch.
I use Core Data within my iOS 7 app to handle the editing and creation of entities. The entities have relationships between them, which all have inverses (as Apple advises).
For the sake of this question, let's pick any one of these interrelated entities and call it the Root entity: the thing that I want to encode with; the thing that logically lives on the 'top' of the hierarchy. I will call this the 'object graph'.
The question is:
What's the easiest way of encoding and decoding such an object graph to and from NSData?
The reason I want to do this is that I'd like my Core Data object graph to be persisted onto a cloud service, without the need of writing my own NSIncrementalStore subclass (it's a bit involved...!).
AutoCoding together with HRCoder almost looks like it could do the job, but I've experimented with this combination and it doesn't quite work with NSManagedObjects at the time of writing.
Still, I'm seeking alternatives. There can't only be one way to do this, surely.
It doesn't have to be JSON, but it'd be nice. Binary would be fine.
It seems to me you do not need to subclass NSIncrementalStore. You can create records and save them to your store with a plain vanilla store created via addPersistentStoreWithType:... with a NSPersistentStoreCoordinator.
The straight-forward way is to handle the incoming JSON by simply taking the data and copying it to the properties of your NSManagedObject subclasses, like this:
object.title = jsonDictionary[#"title"];
object.numericAttribute = [jsonDictionary[#"numericAttribute] integerValue];
If you take care about naming the attribute and entity names exactly the same you can maybe use some shortcuts using KVC, like
[object setValue:jsonDictionary[key] forKey:key];
I once did the above for a large legacy project where it was not feasible to repeat the old attribute names, so I used a custom property list (plist) to match around 800 attribute names.
I'm fairly new to iOS development, so I need some advise.
I'm working on a project (creating a character sheet app for an upcoming table top RPG), and I seem to have put the cart a bit before the horse.
I've already created a subclass of NSObject called characterClass that holds everything I need for a single instance of the character sheet. It also has methods to calculate derived information. I have 2 more classes storing abilities, and have them in NSArrays in the characterClass. Now that it's working, I need to work on data persistance, and storing/retrieving multiple characters.
I'm thinking, of using Core Data, creating a separate entity that matches my characterClass, and having a characterClass init method that pulls the data out of Core Data and puts it into the current instance of characterClass. That seems a bit obtuse to me, (implementing a class separate from the entity) but maybe it's a good way to do it.
I would eventually like to set up dropbox syncing for this information, so whatever I do I would like to have compatible with that. (Core Data with XML files as the backend?)
What would be the best method for something like this?
Rather than just pull the data out of Core Data and use it to create your character class, you could just tweak your character class so that it is an NSManagedObject subclass. That way you are storing your objects directly in Core Data
I'm learning Core Data and I understand all the examples for creating a brand-new object, assigning values and saving it to the managedContext (insertNewObjectForEntityForName).
However, what if I've already created an object elsewhere (model Category)? In this case I'd want to just assign the current Context to this Model, and then save it.
What is the command/approach to take an in-memory Model, and then assign to a context so it can be saved?
If you want to use Core Data to manage your data, you'll need to:
create an appropriate model description (.xcdatamodeld file)
modify your model class(es) so that they inherit from NSManagedObject
set the "Class" for each entity in your model description to one of your NSManagedObject subclasses
add code to your app to create and manage the Core Data stack, fetch data, etc.
This is all very do-able, but I wouldn't recommend that you attempt it until you have a solid understanding of Core Data and your reasons for adopting it in your project. The lack of clarity in your question may indicate that you're not quite there yet; you might benefit from working on a small project that uses Core Data from the start.
If all you want to do is to save your data, you should know that Core Data is not the only way to do that. A much simpler approach to saving your data would be to adopt the NSCoding protocol in your data model and then use a NSKeyedArchiver to store your data. Get the full story from the Archives and Serializations Programming Guide. There are other ways to do it as well, but NSKeyedArchiver is a good place to start.
You can only save NSManagedObjects (and their subclasses) to CoreData. NSManagesObject can not be created except in the context of an NSManagedObjectContext.
So, what you're saying is confusing. Do you have a non-CoreData model object?