I'm an OSX beginner. Where is the best place to store an NSMutableArray of objects. the objects need to be presented to the user for updating, deleting etc. I've already written the code to manage and present the data to the user. i just need to now start saving the data. i don't envisage the array containing more than 50 objects.
i'm not sure where to persist the data. should i use a os file or NSUserDefaults. what does osx etiquette say?
thanks
Since you mention that the user will need to update and delete the data, Core Data is a very good option.
In addition to the benefits of the framework itself, Core Data integrates well with the OS X tool chain. The model design tools allow you to create your schema graphically, quickly and easily. You can use templates in the Instruments application to measure Core Data’s performance, and to debug various problems. On OS X desktop, Core Data also integrates with Interface Builder to allow you to create user interfaces from your model. These aspects help to further shorten your application design, implementation, and debugging cycles.
You can read more about the key features in the documentation to be sure that's what you're looking for.
Related
I am a Mac App Dev and have some questions about how to use Core-Data correctly.
I have multiple TableViews and they are all playing around with the same data (which I want to save persistently with Core-Data). I know the central part of Core-Data which I have to work with - NSManagedObjectContext and I know how to create NSManagedObjects and save/edit/delete these in the persistent store.
But actually I'm wondering about how to organize all that together with multiple ViewControllers,Views,Tables,.. efficiently and without merge conflicts. I've read about some approaches for that: one was by passing the context down from the delegate through every layer of your code. Somebody else suggests to create a singleton-class, let's call it DatabaseManager, which holds the NSManagedObjectContext instance and you go and ask it from there. (I especially like this approach, don't know why.) Or just ask the delegate every time with [[NSApplication sharedApplication] delegate], does this have any disadvantages?
Okay, a lot of questions here but that was only about the How. Now I want to know about your recommendations of where I should actually do all interaction with the managedObjectsContext. (to be in compliance with MVC and don't mess up my code and make it more complicated than it has to be..)
Should I save stuff to Core-Data in my NSTableViewDelegate/-DataSource Classes directly or just fire up an Notification for someone else?
Should I implement some instance methods for my Model-Objects (like -(void)saveInstanceToDatabase,..) to encapsulate Core-Data-Interaction?
Ok thanks in advance for all the brave guys who read until this point and give me some kind of response :D I always appreciate code-examples!
After years of working with Core Data... I've come to the conclusion it's not very good. There are some serious flaws in it's design that can only be solved properly by abstracting the whole thing away.
I recommend implementing your own model for manage objects, which uses core data underneath but does not ever expose it.
Your views and controllers and application delegate and all of that should not ever touch core data at all. They should talk to a series of classes you create yourself, which has been custom tailored for your particular application.
That object layer can use core data underneath, or it might use something else like FMDB or NSCoding or even just plain old NSData objects (this is the fastest option, if you need extremely high performance with large amounts of data, especially when combined with features like NSDataReadingMappedIfSafe).
Start with Core Data. Look at the other options if you have problems. Having your own layer on top means you can easily abandon it in future. And many developers have chosen to move away from Core Data shortly after their app ships to the public. Often due to unsolvable bugs or performance issues.
Howdie,
This is my first post, so if this has been answered somewhere please forgive me (I did search).
Problem:
I have a Cocoa app that needs to share a single Core Data database among multiple user accounts on the system.
Idea:
I would create a daemon to handle requests from the users (to cross user privilege boundaries) to save/retrieve the data from Core Data. Create a shared Managed Object Context that is used in the application and pass that MOC to the daemon through NSXPCConnection. The daemon will have a fully realized Core Data Stack. I can then set the MOC that was created in the app to be a child of the MOC that was created by the daemon. Hit save and I'm done?
Question:
Would this even work? Is this just a dumb idea? What are the other solutions? NSManagedObjectContext conforms to the NSCoder protocol, but in order to use it with XPC I have to subclass it and make it conform to the NSSecureCoding protocol? Would I also just need to make sure my ManagedObject subclasses conform to NSSecureCoder protocol to use with NSXPConnection? I suppose I can ditch the context all together and just send the managed objects.
I'm assuming NSXPCConnection copys objects instead of using pointers? Is this correct?
Also, I'd probably have to keep performance in mind as the objects are coded/ decoded as fully realized objects and not faulted. Is this correct?
Thank you in advance for your help.
Maybe it works. ;-)
But there are some special problems you have to deal with. To make a long story short: I think that it would be better to use an incremental store doing this. But its documentation is close to poor.
We implemented something like this for syncing. And we have to implement this for networking. (That is, what you want to do.) Here are the problems:
A.
Moving around the context won't help. The context contains a subset of the store objects. Which one is in the context is random to the app programmer. (Inserted and changed objects will live there, but not changed, not inserted objects can be there and can go away.)
B.
You can of course move around the store. Since it is on the hard disk, this would be easier, if you have access to that location, where it is stored. You can use an XPC service for that.
Doing so has the problem that you do not know, what one user changed. You only get the whole store. In contrast an incremental store knows the specific changes through the save request.
C.
"Different users" means that you have conflicts. This is "unnatural" to Core Data. Is is a graph modeller and being that, it is not "connection based". It opens a document, owns it, changes it, stores it, and closes it. As every document it is typically not owned by two or more apps (including two running instances of one app) at one time. There is no real good mechanism for working on a store simultaneously. So you have to handle that yourself. It is probably easier to handle that on the level of the incremental store than on a level build on top of it.
What you want to do is not that easy, if you do not make assumptions you can make in your special case. (For example having a locking mechanism on a higher level.)
My 0,05 $.
When using core data, how would I insert to values into a database, or even interact with a database. Is there a good tutorial for this? I have went over Core Data tutorial, but majority the files were done locally.
UPDATE
Someone from my previous question answered this "Core Data can use a database to accomplish this, but that's it's business, not yours. When you use Core Data, it is a black box. You tell it to save the data and then step out of the way."
Does that mean it automatically does the database side for me?
Thank you!
Core data is a black box in that it is an object oriented API for interacting with the SQLite db on the device (and in iCloud). If you are pushing to a web service that has a SQL database backend... Well, I've used a php controller for the web service that provides a rest interface. Then I get data from my device and hit the rest controller methods passing whatever data is appropriate as parameters in an http post. Not sure whether that's general or best practice but that's how we've done it in my experience
Core Data is not a db manager, and does much more than simply interact with your db. At the very least, you should consider Core Data as an ORM. Perhaps, the best way to understand Core Data is to think it as a graph administrator. You are going to interact with core data via a context (NSManagedObjectContext) that will let you fetch objects from it, and also insert, edit and delete them. Objects are subclasses of NSManagedObject. One important thing to care about are threads. NSManagedObject are not thread safe, you should never pass them between threads. Use NSManagedObjectsIDs instead. The important thing, you don't need to care about how core data store things, you can set the format of the store, but that's all (in that respect, you do have to take a few things into consideration when choosing the store, like performance, and whether you need to persist data between runs, but let's Core Data handle the details).
And if you want to know more, Marcus Zarra's book is excellent
I am unsure about the structure of coreData and how the objects are saved in a directory. So what I know is that you create an instance of UIManagedDocument and make a URL for it and where it will save files. Then you call "SaveToURL", what exactly is created when you call this? is it the core data stack? Then when you save information into the entities you declared is a separate file created within the stack for each set of information in an entity? Finally, what exactly is a context of a UIManagedDocument.
These are the three main questions
What is created when you call "SaveToURL", is it a document or a
file or a stack?
When you save information in entities, are separate files created
within this file/stack?
what is a UIManagedDocument context?
I strongly suggest you read Core Data Programming Guide and start with Core Data Basics Chapter.
UIManagedDocument is a special kind of document, an UIDocument subclass, that stores its data using Core Data Framework. So it combines the power of document architecture and core data capabilities.
You can read more about document based architecture from Document Based App Programming Guide for iOS and I recommend WWDC2011 Storing Documents in iCloud using iOS5 session video. I also recommend Stanford CS193P: iPad and iPhone App Development (Fall 2011) Lecture 13.
What is created when you call saveToURL:forSaveOperation:completionHandler: is an implementation detail of UIManagedDocument and UIDocument and you should not really worry or depend on it. However in current implementation a folder containing an sqlite database file is being created.
No. All entities will be contained in a single database file also
more generally called: a persistent store. It is possible to use
more than one persistent store, but those are more advanced use
cases and UIManagedDocument currently uses one.
UIManagedDocument's context refers to a NSManagedObjectContext from underlying Core Data Framework. UIManagedDocument actually operates two of those in parallel to spin off IO operations to a background thread. When it comes to the nature of a context itself here's a quote from Core Data Programming Guide:
You can think of a managed object context as an intelligent scratch
pad. When you fetch objects from a persistent store, you bring
temporary copies onto the scratch pad where they form an object graph
(or a collection of object graphs). You can then modify those objects
however you like. Unless you actually save those changes, however, the
persistent store remains unaltered.
But it really is a good idea to take a look at the lectures and other material I posted above to get a general picture of the technologies used and their potential value to you as a developer in different situations.
when I develop an iPhone App (Time Tracker, ToDoList etc) I never know whats the best way to deal with the data. Once I used a plist, next time sqlite or CoreData.
How do you decide whats the best for your project?
(Only talking about data management)
For Example if you want to develop:
Time Tracker App > Is PList your choice?
RSS Reader App > CoreData?
Photo App > sqlite?
EMail Client > ?
For a beginner can you point me roughly to proper directions?
(I know it depends a lot on the App and what you like to do with
it but any thought will help)
I'm far away from developing complicated apps, they are still pretty simple.
Thanks for help,
Marc
You can use these rules of thumb to decide what storage model will work for your app.
If the data fits in memory entirely and is relatively unstructured, use plist
If the data fits in memory entirely and has tree-like structure, use XML
If the data does not fit in memory and has a structure of a graph, and the app does not need extraordinary query capabilities, use Core Data
If the data does not fit in memory, has a complex structure, or the app benefits from powerful query capabilities provided by relational databases, use sqlite
If the data must be secret (e.g. a password), use keychain.
Note that these choices often overlap, because multiple storage models will fit the same app. Your final decision depends on your personal preferences - you pick a technology that you understand better.
There was a very good question about sqlite vs. Core Data on Stack Overflow, you may want to read through the answers to that question.
My rule of thumb for each of those would be:
Time Tracker App > Core Data
RSS Reader App > Core Data
Photo App > Core Data
EMail Client > Core Data
Though in each case there would be things you would store on the file system. For instance, the photo app would obviously put the actual photos on the file system. The text of the emails would be on the file system etc. The actual RSS messages might be text files too, but with meta data in Core Data objects.
At some point, you might find that the data you are storing is outgrowing the scalability of Core Data. At that point you would consider moving to SQLite.
The point is that Core Data is so easy to use and so superior to the alleged lighter weight alternatives, why wouldn't you use it?