#Swift share singleton throughout project code#
This will make your code far more robust and testable. Instead of accessing the static methods of your singleton you can inject a NetworkProvider object into the class in the constructor that uses it. You will want to use classes, or structs with non static functions because when something isn't a singleton you can use dependency injection. If you then find yourself with many Service objects, you can combine these objects with a facade pattern, that groups functionality when appropriate for a given View/ViewModel. Why not just have a NetworkManager object that you initialize?Įven better why not separate out the services into a few logical classes? One service per class may get a bit arduous, but if you think critically you will likely be able to group services together appropriately. I would recommend thinking carefully about using a singleton. This seems to be an extremely common way of handling networking in iOS and Swift probably because it is very simple to reason about a single global singleton object for services. You can, and should, always solve the problem using dependency injection. That might sound a bit strict, but the drawbacks of singletons outweigh the little benefits of taking the shortcut. There are many articles online which try to answer the question: “when is it ok to use a singleton?” A shared operation queue to prioritize, sequence, and schedule the asynchronous tasks of the app.A URL session that groups related network requests.The disk storage where data is saved, be it the file system, a database, the user defaults of the app, or a Core Data managed object context.There are always parts of an app’s architecture that need to be accessed from many places. In any real app, shared resources are necessary and unavoidable. If singletons are the wrong solution, what is then the correct one? The critical point here is the distinction between singletons and shared resources. Massive view controllers are not the only monolithic objects you should avoid in iOS. Since it’s easy to access a singleton from anywhere, the chances are high that code that needs to be shared ends inside an existing singleton.
Singleton classes often become monoliths.In a singleton, instead, resetting state might not be so natural and might require specific and complex code. When you can have multiple instances, you can discard the old one and then create a new one. There are cases in which you need to reset the shared state. Singletons carry state around for the lifetime of the application.When any part of an app can access or change the global state, you get weird and hard to fix bugs. Even value types like Swift structures and enumerations can access a singleton, which is a bad practice. The global accessibility of singletons makes shared resources accessible from anywhere, especially from code that should not have any access. Ironically, the definition of singleton is one of the reasons why singletons are bad. Singletons provide a globally mutable shared state.Note: These are excerpts from this article about swift singletons. Here are a few reasons why you should NOT develop singletons: Sure, you save some time taking this shortcut, but this code will bite you back later when the architecture of your app grows or when you add unit testing to your project. Developing singletons isn't a good idea in most cases.
0 kommentar(er)
