hi, Im in the process of making a new app to better learn core data. I have already followed along the Ultimate portfolio app, which actually gave me the idea for this current app. I find Core data quite interesting, but at the same time things don't always go to plan ;).

In going mvvm I was getting a few issues and weird behaviors when injecting stuff around so I decided to make my data controlller a singleton just for prototyping to speed it up. I have since rewritten it without the singleton and Im running into all sorts if headaches. I seem to be going in circles a bit, getting one thing to work for something else down the line to break. I know it's just a lack of experience and not impossible, but it seems having the dataController as a singleton just really simplifies alot of stuff.

Without going into too much detail on the app - is using a singleton really that bad?

Also, planning to use NSPersistentCloudKitContainer to have it sync across devices - got a little niggle in my mind that when I get there perhaps the singleton might cause issues... ?

I cant imagine in this particular app needing multiple viewcontexts..

So may I ask a question. If you follow along the PortfolioApp you're basically using a Singleton for the DataController. It's always the same EnvironmentObject you're using. So what are you doing different?

I often struggle with non-updating SwiftUI views myself when I think they should. What I figured out is, that in CoreData update for SwiftUI views is only triggered when the viewContext is actually saved and not when you just change values on the object.

Technically, what you're working with is not a singleton, but a shared instance. And that is usually the correct way to do it.

You can tell it's not a singleton because you can create multiple instances of DataController; if it were truly a singleton, you could only ever create one of them (for instance, by having a private initializer).

Foundation uses the shared instance concept in quite a few places, e.g. UserDefaults.standard, FileManager.default, URLSession.shared, etc. You can create other instances of UserDefaults, FileManager and URLSession if the shared ones do not meet your needs, so although they may look and act as such, they are not actually singletons.

So don't worry about it too much. ;)

@Hatsushira - as roosterboy points out, thats not really a singleton, as you could create another instance of it. If I create a Datacontroller.shared and make the init private, then I can actually access the datacontroller directly from inside a view model just by calling DataController.shared, without having to pass it in somehow - which seems to help with some problems Im having, and avoid injecting too much into the viewModel. I donno - it just feels a bit dirty, and cheaty, but Im not really sure it will be a problem or not, and will it affect the cloudkit persistent container down the line?

edit: The reason im a bit unsure and hesitant is that Im quite early on in this current app - and its the sort of fork in the road where if i go too far it'll be impossible to go back, but also right now still possible to try both ways with a bit of heavy handed editing! Anyway i just started again, with the singleton, unless someone comes and tells me off soon ;)

This interests me as well. As I recall, in the portfolio app it's stated that the singleton pattern is avoided because it will help with testing—which is true. DataController.preview has inMemory set to true. However, I don't think it's ever stated why we aren't using a shared instance. As I see it, it would make the code cleaner and avoid your views from having to know anything about DataController, even if they only have a brief reference to it.

Also, planning to use NSPersistentCloudKitContainer to have it sync across devices - got a little niggle in my mind that when I get there perhaps the singleton might cause issues... ?

What makes you think so?

DataProvider.preview is a shared instance, just as UserDefaults.standard, FileManager.default, and URLSession.shared are.

@roosterboy That isn't in contention. The question is why not use a shared instance, using that pattern, across the entire app.

What makes you think so?

Havent checked back on this thread for a while. In hindsight - at the time I mentioned that I didn't really understand what I was talking about to be honest! Been exploring CloudKit a bit, and also my CoreData understanding has definitly been increasing after digging myself plenty of graves 😉

I went with the singleton approach in the end. I really find it way nicer and less fiddley with viewModels etc. Hopefully it won't come back to bite me too hard.