A singleton SettingsManager was suggested, but singletons always get a bad wrap.
So is this a good use of a singleton? What would be the correct way to handle this?
You can pass the settings in the constructors, with setter methods or have a "state object" that contains the configuration.
For "updating" the states on every class in real time I'd rather rely on explicit state change using the Observer pattern.
EDIT: I'd also like to know what other developers do, or if there's anything wrong with my methods, so I second your question.
I am working on an application that periodically pulls information from a server about a physical object (sorry, I can't be more specific than this, so please don't ask). This information needs to be accessed by several different classes, and displayed in view controllers on different tabs. A view controller will pull the information and make it available to all the other view controllers.
A singleton provided an effective solution to this because only one data model of my physical object's state can exist at any given time, with the added benefit that I can access it from any view controller without much effort.
I may be wrong, but I thought the purpose of a singleton was for models where there can be one and only one instance of your class? Singletons (like other design patterns) were designed to solve a specific problem. But I concede that they are probably overused.
One advantage is that the classes are then reusable in other projects because they aren't coupled to an application specific settings provider.
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.
http://developer.apple.com/library/ios/#documentation/uikit/...
It is almost everwhere.
[MyClass sharedMyclass] is the Objective-C equivalent of getInstance()
Also, singletons make good sense in mobile apps, as it is a very different type of a beast than a server side app.
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.
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.
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.
Hopefully this will stem the tide of questions on Stack Overflow about different Objective-c singleton implementations.
I'm also interested in hearing what is considered the best practice for things like passing around config options, an eventloop, or message bus.
When you DO need global state, then a singleton object is a reasonable way to achieve it. But chances are fairly high that you don't.
As I'm not in the mobile sphere, I wouldn't know how to avoid a singleton for an app that is constrained by speed and space requirements. I've already shown an example above, what's your solution in this environment, with the constraints of the questioner?
If he's making a game, this is completely acceptable design. Games programming is wildly different from application or server programming. Also, strict TDD is much, much less useful in games programming than anywhere else. Writing unit tests for central data structures and algorithms is useful, of course, but the majority of modules/classes/objects are so small, uncritical, and change completely so often that it's not worth bothering.