hey Jaber. Singletons are fine for that purpose, actually they are probably the best solution.
iOS uses singletons everywhere, so feel free to use them.
Don't fall the trap of the cargo culture thinking. Google has a completely different problem than you do. Their code spans hundreds of thousands (or millions), of code, in distributed systems, etc..
Don't fall the trap of the cargo culture thinking. Google has a completely different problem than you do. Their code spans hundreds of thousands (or millions), of code, in distributed systems, etc..
This is probably the single most useful quote in this entire discussion. Singletons are not inherently bad -- they were created for a reason, but because people abuse them, they have a bad rep.
There are many instances where you need just one instance of a class, not just a hardware device driver (for instance, when you need GPS location coordinates on a mobile device across several different classes).
No, Settings/Configuration is a classic example of where using a Singleton horribly breaks testability, because you can't run multiple "application runs" in the same "test run" without completely exiting and rebuilding the app runtime environment.
Testing frameworks exit and rebuild the app runtime environment all the time, to isolate the effects of one test case from the next. When your singleton instantiation is paramatrized, for instance with a configuration file, than there is no testability problem whatsoever.
I would go as far as to say that if you have to do multiple "application runs" in the same "test run", where these "application runs" require different configurations to have the test cover some specific scenario, then your code has larger problems than having the configuration in a singleton.
In java, singletons are enforced by the type system - i.e. There's no public way to make more of the object. Usually that's what people mean by 'singleton' in java. If you don't have the source and you outgrow the single instance, there's nothing you can do except stop using the class.
In Objective-C, people do occasionally simulate that by mungng init and alloc, but that is definitely a bad idea. More often a singleton class will have a conventional init and alloc, but have a class method like +sharedInstance which lazily instantiates and dispenses a single instance of the object during the lifetime of the application. That's what people most often mean by 'singleton' in objective-c. It's basically a global variable, but when you outgrow it, it's often not hard to switch to allocating more than one.
Also, partly due to what many would see as a deficiency - the fact that it's much harder to produce architecture independent libraries in objective-c than java, the source is available more of the time, so evolving past a singleton is more often straightforward.
iOS uses singletons everywhere, so feel free to use them.
Don't fall the trap of the cargo culture thinking. Google has a completely different problem than you do. Their code spans hundreds of thousands (or millions), of code, in distributed systems, etc..
your iOS app probably has different constrains.