Lantean

Suppose that… for whatever reason, you need to target iOS 3.x. Yes. You need to build an app that should run on any possible device. Or say that… you simply don’t wanna use GCD.

What’s the alternative to write a singleton?
[cc lang=”objc”]
+ (id)sharedInstance
{
if(_instance = nil)
{
@synchronized(self)
{
if(_instance == nil)
{
_instance = [[[self class] alloc] init];
}
}
}
return _instance;
}[/cc]
This is a nice alternative to the GCD option. The first time the instance is created, you’ll suffer the lag caused by the @synchronized block. But after that. it’s just an if. No context switch. No whatsoever! REALLY performant!

So… you write a new piece of code. You run it. Test it. Ship it!. And in two weeks, you end up flooded by iTunes Connect Crash Reports.

What happened?. It turned out that an attribute parsed from a backend response ended up being a NSString instead of an NSNumber. And it was only after an untested-and-specific-workflow that your application actually used that field.

How do we prevent this?. ASSERTIONS!. A good friend of mine teached me that… great software blows everywhere before getting published. If your code works perfectly… you should be scared!.

What are assertions?. Simple. Checkpoints that will produce controlled crashes while your app is in Debug mode. How do you use them?.

Well, you’ll need to declare few macros first. Say… we name this include ‘LADebug.h’:
[cc lang=”objc”]
#ifdef DEBUG
#   define ASSERT(x)            assert(x)
#   define ASSERT_CLASS(x, y)   assert([x isKindOfClass:[y class]])
#else
#   define ASSERT(x)           
#   define ASSERT_CLASS(x, y) 
#endif
[/cc]

So.. those macros will be available only if the DEBUG flag is present. How do you use them?…. this is just a simple example…

[cc lang=”objc”]
– (void)processResponse:(NSArray*)array callback:(id)callback
{ 
ASSERT_CLASS(array, NSArray);
ASSERT(callback);
…
}
[/cc]

This example will procude a controlled crash if the parameter ‘array’ is not an instance of NSArray. Or if the ‘callback’ parameter is not present.

This will make your debug target a little heavier. But if you use this app-wide, you’ll be able to detect problems early in the development stages, and you’ll have the chance of fixing them!.

Cool, ha?. (Thanks Tincho!).

 

So… what’s the recommended way (thread safety + performance) to implement a singleton?

Well.. it looks pretty much like this!
[cc lang=”objc”]
+ (instancetype)sharedInstance
{
static dispatch_once_t pred;
static Foo* bar = nil;

dispatch_once(&pred, ^{ bar = [[Foo alloc] init]; });
return bar;
}[/cc]