Fundamental iOS design patterns: SharedInstance (Singleton in Objective C)

Brief introduction

Singleton is one of the (if not THE) most commonly used/abused design pattern adopted in software development.
Basically it’s used to restrict the instantiation of a class to one object only that can be used safely across application architecture. Its implementation is pretty simple compared to other patterns and it’s very similar for the most of programming languages, but in Objective C it has a slightly different approach due to the lack of “normal constructor” that are instead replaced by alloc/init paradigm.

How it works in Objective C

In Objective C, we can speak more appropriately about the SharedInstance pattern rather than traditional Singleton.
This one is often used in Apple frameworks and differently from its twin brother, it does not explicitly forbid the instantiation of multiple class instances, but it simply provide a class method that will return a shared instance. During the first call to that method the instance will be allocated and the next calls will return the previously object created. So this is a sort of hybrid approach.
A common class that use this pattern is UIApplication which implements a sharedApplication method (which returns the current running application). Differently from Singleton which use getInstance(), in Objective C the corresponding method has not a fixed name but it should start with “shared” followed by the “type” of class (so for UIApplication is “sharedApplication” for MYAmazingManager will be “sharedManager“). Anyway there are several exceptions, for example NSFileManager has a “defaultManager” acting as a sharedInstance accessor that could be renamed “sharedManager“.

Pattern implementation

In my singleton implementations I simply call the accessor “sharedInstance“, in this way I can use a simple pre-compiler macro that automatically synthesize this methods for me.
Even implementation of this pattern may vary and personally I adopted one which is thread-safe and rely on CGD (Grand Central Dispatch), which is an affective C level API provided by Apple in order to handle concurrency.

The implementation of my sharedInstance method is the following (comments explain how it works):

+ (id)sharedInstance 
	// structure used to test whether the block has completed or not
	static dispatch_once_t p = 0;
	// initialize sharedObject as nil (first call only)
	__strong static id _sharedObject = nil;
	// executes a block object once and only once for the lifetime of an application
	dispatch_once(&p, ^{
		_sharedObject = [[self alloc] init];
	// returns the same object each time
	return _sharedObject;

Pattern in action!

SharedInstance pattern is IMO the best way to share data across multiple viewControllers in iOS applications.
One practical example is a data manager to share Core Data stuff such managed object context. I realized my own manager so that I can access this objects anywhere with ease like:

[[MYDataManager sharedInstance] managedObjectContext];

Quick iOS tip: where is the right place to add and remove observers in UIViewControllers?

While I was debugging my iPhone app I noticed (thanks to my verbose logs) that certain methods were called multiple times… apparently like if they were in a loop. I lost several time trying to figure out why and then I realized that the problem was related to defining them in the wrong place! (technically not wrong at all, but definitely wrong in my app context).
I was adding listeners in viewDidLoad and removing them in viewDidUnload.
This is acceptable only if you have simple UIViewControllers that don’t work in composite controllers hierarchy (they are not contained in UINavigationController or UITabBarController).
viewDidLoad is called after the view controller’s view has been released, but in a controllers hierarchy this does not happen since controllers are retained by the container! This leads to multiple messages dispatched to registered observers, so if you have a UINavigationController containing a sequence of 5 viewController, handlers will be triggered 5 times (one for each controller).
The safely approach to add and remove listeners is instead in viewWillAppear: and viewWillDisappear:

- (void)viewWillAppear:(BOOL)animated
   [super viewWillAppear:animated];
   [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(foo:) name:UIKeyboardDidShowNotification object:nil];

- (void)viewWillDisappear:(BOOL)animated
   [super viewWillDisappear:animated];
   [[NSNotificationCenter defaultCenter] removeObserver:self name:UIKeyboardDidShowNotification object:nil];

Quick iOS tip: invoke UITableView dataSource and delegate methods from a UITableViewCell

I faced a situation in my app where I wanted to access to UITableView datasource from a UITableViewCell. Specifically I implemented the same behavior of left green (+) button in the label contained in the cell, so if you click on it the editing action “UITableViewCellEditingStyleInsert” will be committed.
Since a cell is contained in a table we can easily access to it using self.superview (cast is required because superview returns a basic UIView *), then once we are sure that the table has a valid dataSource, we can manually invoke the selector tableView:commitEditingStyle:forRowAtIndexPath:. In order to pass the proper indexPath dynamically we rely on table method indexPathForCell: (we don’t know in which cell we are but table does!).
The complete code snippet is the following:

UITableView *table = (UITableView *)self.superview;
SEL sel = @selector(tableView:commitEditingStyle:forRowAtIndexPath:);
if ([table isKindOfClass:[UITableView class]] && [table.dataSource respondsToSelector:sel]) {
    [table.dataSource tableView:table 
              forRowAtIndexPath:[table indexPathForCell:self]];

My migration to ARC (Automatic Reference Counting), using Xcode 4.2 refactor assistant

Starting from Xcode 4.2 and the introduction of the new LLMV compiler, is now possible to use “Automatic Reference Counting” (ARC). This powerful feature frees developers from memory management by eliminating the need of sending release and autorelease messages. Anyway this is very different from a garbage collector, in that it’s a compile-time feature, which basically analyze the code and automatically inserts that calls when necessary for us. In this way we have the best of two worlds: we don’t have to worry about releasing, deallocations and memory leaks, but simultaneously we have the performance of a memory managed language. This is very cool, however I don’t envy new upcoming iOS developers whose will start directly using ARC. It’s very important learning and understanding how memory management works in Objective c, and the difference between owning a reference to an object or not (I recommend this reading). For example I fear that new developers won’t understand the use and benefits of NSAutoreleasePool (that have been replaced with @autorelease block in ARC).
Anyway in the last days I switched my code to ARC using Xcode refactor system and I want to share my experience.
These are the steps I followed:

1. “Preferences” -> “General” -> check “continue building after error”

This step is fundamental to avoid an huge waste of time repeating the next steps every time an error is encountered!

2. “Edit” -> “Refactor” -> “Convert to Objective-C ARC”

3. “Select targets to convert” (check them)

4. Click “precheck”

5. “Cannot Convert to Objective-C ARC” (Xcode found N issues that prevent conversion from proceeding. Fix all ARC readiness issues and try again.)

You will see this message at least once, because your code contains calls that are forbidden by ARC.

6. Fix them using suggestions (click on errors to open the popup containing the tip). Then repeat from step 1

7. “Convert to automatic reference counting” window will appear (once issues have been fixed)

8. Click next

9. Review automatic changes

10. Save

If after clicking on “save” nothing happens, you may be unlucky as I am and Xcode is unable to prooced because it silently fails trying to generate a snapshot of your project. I solved the problem by doing a clean install, that means run “sudo /Developer/Library/uninstall-devtools” to remove all files and install Xcode from the scratch (by the way this had also improved its performances).

The migration was pretty painless in my case, however I had to disable ARC on certain files because it was very hard to refactor the code in order to make it ARC-friendly (this is the case for heavy use of Core Foundation functions).
To disable ARC in these files I added the flag “-fno-objc-arc” in the column “compiler flags” under “Build phases” tab (related to my target).
I then did a small refactor by marking NSError pointer as “autoreleasing”:

NSError *__autoreleasing error = nil;

This is in fact a little optimization trick, that avoid the creation of an extra temporary variable by the compiler. (read more here).

I also marked all readonly properties as “strong” and removed the “__unsafe_unretained” placed by Xcode.

…that’s all folks… all works pretty well, the code is shorten and cleaner and I’m satisfied :)

Getting right UIImage and CGImage pixel size according to device display (retina or not)

I just fixed an issue related to the wrong display of an UIImageView in my (never ending WIP) app. The problem is that starting with iOS 4 and with the introduction of retina display in iPhone 4, the attribute “size” does not return the real pixel dimensions but points. So on a retina display device an image of 100×100 pixel will return a size of 200×200 (values are doubled). Theoretically there is an helpful attribute “scale” that should return a float value representing the adopted scale (2.0f for retina display, 1.0f for other).
Unfortunately, in my case it returns always 1, both for the iOS simulator than the real device (iPhone 4 with iOS 5), and my images are rendered incorrectly.
After digging on Google (which as usual points me to my beloved Stackoverflow), I gathered several helpful informations that helped me solving the problem and inspired a few helpful precompiler macros :)
The scale value, which is essential to implement retina display-aware software can be retrieved using:

[[UIScreen mainScreen] scale];

So, I realized the following macros:

// return true if the device has a retina display, false otherwise
#define IS_RETINA_DISPLAY() [[UIScreen mainScreen] respondsToSelector:@selector(scale)] && [[UIScreen mainScreen] scale] == 2.0f

// return the scale value based on device's display (2 retina, 1 other)
#define DISPLAY_SCALE IS_RETINA_DISPLAY() ? 2.0f : 1.0f

// if the device has a retina display return the real scaled pixel size, otherwise the same size will be returned
#define PIXEL_SIZE(size) IS_RETINA_DISPLAY() ? CGSizeMake(size.width/2.0f, size.height/2.0f) : size

Then I used a little trick, to initialize an UIImage with the correct dimensions. Fundamentally I initialize an “helper image” first from which extract a CGImage in order to allocate a new UIImage using the initializer initWithCGImage:scale:orientation: (as scale I use the previous defined macro DISPLAY_SCALE).

UIImage *helperImage = [[UIImage alloc] initWithData:data];
UIImage *pic = [[UIImage alloc] initWithCGImage:helperImage.CGImage scale:DISPLAY_SCALE orientation:UIImageOrientationUp];