StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>You can define your own subclass of <code>NSManagedObject</code>, and set all of your entities to use it.</p> <p>The subclass can have whatever initialiser/save patterns you define, so long as it calls the proper parent class's initialiser.</p> <p>You could have a <code>+entity</code> method, which might link to a statically defined context (this will restrict you to a single managed object context of course, but that's not always bad as long as you can also call the more primitive initialisers when you need a second context).</p> <p>You might even have a <code>+entityWithName:</code> method.</p> <p>As for saving the context, once again you can always define a subclass and add a simple <code>-save</code> method which saves the context and throws an exception if the save fails. You may choose to do this with a category extending the <code>NSManagedObject</code> class, instead of a subclass.</p> <p>Note it is impossible to save <em>just</em> the change you made to that one entry object. You can only save all changes to an <em>entire</em> managed object context. If you need to save a single record, then you need to create a temporary managed object context, make a single change in it, then save the temporary context, and then sync the temporary context change over to all other managed object context's that currently exist in the app (there is an API to do make this complicated process relatively easy).</p> <p>I don't like the code you posted to save the context, for several reasons:</p> <ul> <li>Don't define a <code>managedObjectContext</code> variable that just points to <code>self.managedObjectContext</code>. In almost all situations that's an extra line of code for no benefit. At best you're making your code hard to read, at worst you might be introducing bugs.</li> <li>Why are you checking if it is <code>nil</code>? Usually you should design your code so that it cannot ever be <code>nil</code>. Do the <code>nil</code> check in the constructor of your object, and if it's <code>nil</code> that is a critical failure. Your whole app is completely useless for the user, and you should make it clear to the user that they can't use the app by doing something drastic, such as a crash (an error alert first would be nice, but I wouldn't bother. I'd just throw an exception).</li> <li>Why are you doing a check for <code>hasChanges</code>? I cannot think of many situations where you would need to do this check. Perhaps your app is allowing a user to make many changes, and then saving them several minutes later? This is bad. The context should be changed milliseconds after a group of changes are made, or else you're risking data loss. Your app could crash, the phone could run out of battery, or the user might receive a phone call and your app is consuming enough RAM that the OS will terminate it instantly in order to present the "incoming call" screen. You shouldn't need to check for <code>hasChanges</code> because you always perform a save operation immediately after making some changes.</li> <li>As I kind of mentioned before, if the save fails you should present an error to the user then throw an exception. Avoid using <code>NSLog()</code> in deployment code, it's really only useful for development and beta builds.</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload