iPhone Code Snippet – The Singleton Pattern

There are many pages of discussions around the internet about whether or not you should use global variables in your applications. I’m not going to to into the depths of these discussions, but I have come to live by the following ethos when it comes to using global variables in my application;

Use them sparingly; Having too many global variables floating around makes it very hard to keep track of what’s going on. I never use more than one global object for each logical section of my code – even if that object contains a handful of other objects from that section.

But you do sometimes need them; I once wrote a small game where I decided not to use my own globals at all. Truth be told, I ended up with a bit of a mess – a large number of similar constructors with a numbers of parameters to link my objects together. Sure, the units were technically separate and didn’t rely on each other – but the reality was, that when you get deep enough into your code – some classes are only ever going to be used in this project (view controllers etc).

Use them when it’s applicable; Generally, global variables are applicable in situations when you’ve got an object / class of which you are only ever going to need one of them and they don’t logically sit as a child of one single part of the application. For instance, the ‘application’ object in some languages – where the object represents the running application.

So, Singleton Eh?

The Singleton model is often used to instantiate just one instance of a class which doesn’t allow a second instance of that same class to be loaded anywhere in the application. Some implementations will throw an exception if you try to create a second instance of the class, some will create the singleton for you when you first try to access it, and some will even let you create other instances if you want, but will always manage a ’single shared instance’ for you. Many of the core Apple classes follow this pattern, such as [UIApplication sharedApplication].

Anyway, Apple do a very good job (naturally) of providing a good example of the Singleton model. The following code is rather similar to the Apple example, but it also includes what you should have in the header file. It is also a stable part of any library of code snippets, so it has to be here really!

SingletonClass.h

#import <Foundation/Foundation.h>
#import <UIKit/UIKit.h>

@interface SingletonClass : NSObject {

}

+ (id)sharedInstance;
@end

SingletonClass.m

#import "SingletonClass.h"

@implementation SingletonClass

static SingletonClass *sharedInstance = nil;

// Get the shared instance and create it if necessary.
+ (SingletonClass*)sharedInstance {
    if (sharedInstance == nil) {
        sharedInstance = [[super allocWithZone:NULL] init];
    }

    return sharedInstance;
}

// We don't want to allocate a new instance, so return the current one.
+ (id)allocWithZone:(NSZone*)zone {
    return [[self sharedInstance] retain];
}

// Equally, we don't want to generate multiple copies of the singleton.
- (id)copyWithZone:(NSZone *)zone {
    return self;
}

// Once again - do nothing, as we don't have a retain counter for this object.
- (id)retain {
    return self;
}

// Replace the retain counter so we can never release this object.
- (NSUInteger)retainCount {
    return NSUIntegerMax;
}

// This function is empty, as we don't want to let the user release this object.
- (void)release {

}

//Do nothing, other than return the shared instance - as this is expected from autorelease.
- (id)autorelease {
    return self;
}

@end

There you go – copy and paste this into your new project, rename the interface and implementations and you’re done – a ready to use Singleton in your project.

What do you think?