|
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 Foundation uses the shared instance concept in quite a few places, e.g. 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.
What makes you think so? |
|
|
|
@roosterboy That isn't in contention. The question is why not use a shared instance, using that pattern, across the entire app. |
|
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. |
SPONSORED Get accurate app localizations in minutes using AI. Choose your languages & receive translations for 40+ markets!
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.