Objective C singleton pattern templates discussion

gistfile1.m

// Accessorizer's default generated singleton code for class Foo

static Foo *sharedInstance = nil; 

+ (void) initialize
{
    if (sharedInstance == nil)
        sharedInstance = [[self alloc] init];
        }

+ (id) sharedFoo
{
    //Already set by +initialize.
    return sharedInstance;
}

+ (id) allocWithZone: (NSZone *) zone
{
    //Usually already set by +initialize.
    @synchronized(self)
    {
        if (sharedInstance)
        {
            //The caller expects to receive a new object, so implicitly retain it
            //to balance out the eventual release message.
            return [sharedInstance retain];
        } else
        {
            //When not already set, +initialize is our caller.
            //It's creating the shared instance, let this go through.
            return [super allocWithZone: zone];
        }
    }
}

- (id) init
{
    //If sharedInstance is nil, +initialize is our caller, so initialize the instance.
    //If it is not nil, simply return the instance without re-initializing it.
    if (sharedInstance == nil)
    {
        self = [super init];
        if (self)
        {
            //Initialize the instance here.
        }
    }
    return self;
}

- (id) copyWithZone: (NSZone *) zone
{
    return self;
}
- (id) retain
{
    return self;
}
- (unsigned) retainCount
{
    return UINT_MAX; // denotes an object that cannot be released
}
- (void) release
{
    // do nothing 
}
- (id) autorelease
{
    return self;
}

gistfile2.m

// Apple's documented version (from Cocoa Fundamentals Guide)

// http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/CocoaObjects.html%23//apple_ref/doc/uid/TP40002974-CH4-SW32

static MyGizmoClass *sharedGizmoManager = nil;
 
+ (MyGizmoClass*)sharedManager
{
    if (sharedGizmoManager == nil) {
        sharedGizmoManager = [[super allocWithZone:NULL] init];
    }
    return sharedGizmoManager;
}
 
+ (id)allocWithZone:(NSZone *)zone
{
    return [[self sharedManager] retain];
}
 
- (id)copyWithZone:(NSZone *)zone
{
    return self;
}
 
- (id)retain
{
    return self;
}
 
- (NSUInteger)retainCount
{
    return NSUIntegerMax;  //denotes an object that cannot be released
}
 
- (void)release
{
    //do nothing
}
 
- (id)autorelease
{
    return self;
}

fascinating that this isn't clear cut and documented.

Apple's docs are wrong. As simple as that.

As I mentioned above init can fail.

I don't think Apple example code should always be considered best practice. Esp. when it is pretty easy to pick holes in. Quite frankly I wish Apple would remove this code form their docs - it really is bad code. And with ARC out now - it isn't even relevant.

I've never seen a bug in 12+ years of Cocoa programming that would have been avoided by overriding the reference counting methods.

I suspect it will be documented soon, given the remarks made in the Writing Easy to Change Code session, but we'll see...

Hi folks - yes, I got that Singleton code from Peter Hosey and it seemed in 2009, he had a compelling case against what Apple was suggesting. I since added GCD a la Mike Ash. I can improve the Singleton (long version) for Accessorizer 3.0 once we can all agree is THE best way. I'm all ears. Send me what you think is the correct and best/safest way to write a non-GCD based singleton. Apple's documentation on Singleton code has changed from time to time. Is their current version THE correct way? -Thanks, Kevin

I use the + (Foo *)sharedInstance; method and normal memory management rules.

99% of the time i never retain or release the singleton explicitly - it gets lazy init-ed in the sharedInstance method and then effectively leaked. If dealloc has to do some clean up work then I'll hook it up to the applicationWillTerminate: notification and clean it up there (note - for this reason I keep the static variable OUT of the sharedinstance block so it can be released and nil-ed elsewhere).

The 1% of the time the singleton is retained/released the normal memory management rules work just fine. If you retain it, you ought to release it.

I avoid copying the singleton by simply just not adopting the NSCopying protocol.

Really - less is more here. Just use the simple sharedInstance approach and move on with your life. If you use common sense and follow the normal Cocoa patterns you won't see any singleton related bugs.

Apple should only include best practice in their documentation. I agree that they don't always do so.
I like defensive programming.

thanks for chiming in schwa. That's pretty much how I wrote things by hand before I got accessorizer. I like the lazy load/creation because you can do more extensive initialization because you aren't in an +initialize context.

Seems like an easy test for sanity checking would be an NSAssert in - init that tests to see if the sharedInstance has already been created or not.

Fun addition: some Cocoa classes behave as "semi-singletons" on purpose. For example, [NSFileManager defaultManager] returns a "shared" file manager, but you can also (and apparently this is now the suggested method) use [[NSFileManager alloc] init] and get a thread-safe one. (I can't think of any other examples right now...)

@quavera the two samples here https://gist.github.com/1050447#gistcomment-37789 and https://gist.github.com/1050447#gistcomment-37797 are really the best singleton implementations now (pre-blocks and post-blocks). I'd definitely encourage you to use them.

BTW: I had Apple's implementation in Accessorizer for several years. Then a bunch of developers chimed in saying it was not correct. This led to Peter's version. I see now he's changed it somewhat. But again, I'm going to release Accessorizer 3.0 in Aug/Sept with ARC support among other things. I'll add a updated version of a Singleton based on your input.

Thanks for those links!

editing the non blocks version to move static var out as both schwa and I generally do.

no more overrides? I got those overrides from Apple's documentation some time ago.

@quavera if you read the thread the consensus here seems to be:

1. that the Apple docs aren't great
2. it's not necessary to enforce singleton-ness
3. less is better.

(I'm not 100% in agreement with #2, and will probably put an NSAssert into my - init that tests to see if the sharedInstance is nil and assert if not. Something like NSAssert( sharedInstance == nil, @"initializing a second copy of your singleton class, probably not what you want"); either as an assert or a debug NSLog message.)

no more overrides.

they're dangerous and scramble the normal ref counting mechanism (which isn't even available to you in ARC anyway).

If the user wants to retain/release the singleton - let him. It won't cause any harm at all.

If the user decides to release it - well that's a stupid programmer who isn't following the Obj-C reference counting rules. Not much you can or should do to prevent that.

ARC makes all this noise go away.

thanks to all for this discussion - I have a few switches (options) in the Accessorizer Singleton code gen interface. I can re-implement/add some custom options there. People just need to email me what they want and I'll do my best to accommodate. Lastly, if there's ever a question with the code generated by Accessorizer, do NOT hesitate to contact me via email so we can discuss, modify, improve etc.