Core data code in the app delegate and more

Hi

I've read in several places that the default coredata code produce by xcode, when creating a new project, shouldn't really be in the app delegate file. I'm new to core data and am finding it difficult to make sense of the many contradictory examples I'm finding on the Internet. In some cases, admittedly they are just examples, the data manipulation and retrieval code is also in the app delegate.

Is this correct?

Should custom code in the app delegate be limited to calls to other classes?

What are the pitfalls of putting functionality in the app delegate?

I ask because I shifted the default persistent container and context etc. into a separate class, as when I tried to do a save in the background (using DispatchQueue) I got an error stating something along the line that I couldn't do that against the viewContext as it was part of the app delegate (apologies for not being specific, that was over a week ago).

Foolishly I thought I'd do my learning by building what I thought, based on many years experience with VB etc., was a very simple app. Turns out that nothing is that simple. I've hit so many walls I think that my approach in many places is fundamentally wrong. I don't learn well reading manuals, rather I prefer working examples etc.

If anyone has an example of, or a link to, code that demonstrates correctly how to work with core data with relationships etc. it'd be much appreciated.

In particular how to:

a) not lock up the UI (I have potentially thousands of related records).

b) know when all data for a relationship has been retrieved (I'm getting an error now stating an array populated from NSMutableSet.allObjects mutated while being iterated)

Thanks in advance...

Ps. My code is written in Swift.

Replies

Contradictory examples exist on the Internet because there are a variety of different ways to structure code, and the ultimate rule is "Does this code work?"


Counter points: Once upon a time, the first thing in the Core Data programming guide was essentially "Put this manual down and don't come back until you're familiar with threading, the object model, and other related mechanisms. Go work on sample projects that don't use Core Data; then come back when you're ready."


In particular:

"know when all data for a relationship has been retrieved (I'm getting an error now stating an array populated from NSMutableSet.allObjects mutated while being iterated)"

That doesn't appear to be the right question. If you're getting an error stating that an array is being mutated while being iterated, that's a problem with your code where you need to make a copy of the array before you iterate it. If you don't understand what's mutating the array, that's a more important point to investigate.

>I've read in several places that the default coredata code produce by xcode, when creating a new project, shouldn't really be in the app delegate file.


>...the data manipulation and retrieval code is also in the app delegate.


>Is this correct?


The current CD FAQsays this about stuf/where, app delegate, fetches etc.:


Where is a managed object context created?

Where a managed object context comes from is entirely application-dependent. In a Cocoa document-based application using NSPersistentDocument, the persistent document typically creates the context and gives you access to it through the managedObjectContext method.


In a single-window application, if you create your project using the standard project assistant, the application delegate (the instance of the

NSApplicationDelegate
class) again creates the context and gives you access to it through the
managedObjectContext
method. In this case, however, the code to create the context (and the rest of the Core Data stack) is explicit. It is written for you automatically as part of the template.


Do not use instances of subclasses of

NSController
directly to execute fetches. For example, do not create an instance of
NSArrayController
specifically to execute a fetch. Controllers are for managing the interaction between your model objects and your application interface. At the model object level, use a managed object context to perform the fetches directly.

> I've hit so many walls I think that my approach in many places is fundamentally wrong.

Keep in mind that CD assumes a specific basket of pre-existing skill sets. Your approach is only wrong in that context and how you measure up. Attempting CD without them puts you on a playing field without knowing what the game is, much less understanding how to play it. Nothing like a stretch goal to drive learning, but keep your expectations in line with this one. There may simply be more walls than you anticipated, so dress accordingly.


And don't get me started on VB...it's ruined more good minds than lead dinnerware. Word from the 23rd century is it and disco still s u c k.