I use a lot of singletons, I have set up many as I call them 'singleton frameworks'.
Also, I like to write the definition of the singleton in the prefix header of my XCode project, so I can use all my singletons in every class with only 1 line of code! To me this seems like heaven, but I keep noticing that I have to deal a lot with memory warnings in all of my apps. So I was wondering, does that have anything to do with putting my singleton definitions in the prefix header? To me it seems since a singleton is only one instance it doesn't matter at all if you put it in the prefix header or not. Perhaps it's more the fact that the 8 different singletons exist at the same time, each of them having different objects?
Here is an example of a regular prefix header in my projects:
//Imports
#import "Program.h"
#import "Category.h"
#import "GetSpecs.h"
#import "FlurryAPI.h"
#import "AdSmallView.h"
#import "SoundPlayer.h"
#import "ButtonAlert.h"
#import "NSViewHelper.h"
#import "NSDateHelper.h"
#import "NSStringHelper.h"
#import "TESTAppDelegate.h"
#import "EGORefreshTableHeaderView.h"
//Singletons
#define gSpecs [GetSpecs sharedGetSpecs]
#define bAlert [ButtonAlert sharedButtonAlert]
#define sPlayer [SoundPlayer sharedSoundPlayer]
#define adSmallV [AdSmallView sharedAdSmallView]
#define vHelper [NSViewHelper sharedNSViewHelper]
#define dateHelper [NSDateHelper sharedNSDateHelper]
#define nsprefs [NSUserDefaults standardUserDefaults]
#define strHelper [NSStringHelper sharedNSStringHelper]
#define pDel ((TESTAppDelegate *)[[UIApplication sharedApplication] delegate])
So to conclude, I have 2 questions: 1. is it bad practice to put singleton definitions in the prefix header? 2. can memory issues be caused by this prefix header part or is it more possible it's the fact that many different singletons are continuously 'alive'?
Interesting approach. It's not a problem to have these as #defines in the precompiled header-- this does make them available everywhere, and as jtbandes says, they are only invoked on usage anyways, so no memory concerns there.
It strikes me as stylistically a little goofy that you're essentially creating global "magic" reserved words that look like they could be local variable names. If others are reading your code, they're not especially self-explanatory. If doing this, I would probably at least start them with a capital or make them all-caps to indicate they're a definition/macro.
It's also a little unorthodox to be pulling so many app headers into the precompiled header (which is normally quite lean, and used for core system stuff), but the actual effects on compile time here on modern machines will be totally negligible.
Your statements about why you create singletons, and memory warnings, lead me to think that you may still be learning programming. Singletons are fine way in an object oriented world to encapsulate an object that should only exist once. If you're using them as a way to avoid "writing the same code over and over", any regular function or method where you need it will work as well. For "helpers", you should look into "categories" as well which might do some of the lifting for you there. Re: the 8 different singletons. Zillions of objects coexist at the same time while your app is running, singletons and otherwise. That alone is not an issue-- they don't bother eachother as long as they're all managed correctly.