{"id":568763,"date":"2010-05-18T11:25:08","date_gmt":"2010-05-18T15:25:08","guid":{"rendered":"https:\/\/gigapple.wordpress.com\/?p=44800"},"modified":"2010-05-18T11:25:08","modified_gmt":"2010-05-18T15:25:08","slug":"iphone-dev-sessions-using-singletons","status":"publish","type":"post","link":"https:\/\/mereja.media\/index\/568763","title":{"rendered":"iPhone Dev Sessions: Using Singletons"},"content":{"rendered":"

Managing an application\u2019s state can sometimes require complex interaction with persistence and messaging with various resources, or it can be as simple as keeping track of a counter from one view to the next.<\/p>\n

Two popular techniques to pass references to objects from one view to the next are to create properties in the Application Delegate, or to continue to pass references from one view to the next like a relay race passes a baton from one runner to the next using a series of carefully placed update methods making for an allocation nightmare and increase the opportunities for memory leaks or the hard to track down crashes. Sometimes this need in programming is referred to as implementing Global Variables. There is also a well established design pattern that can assist with this need as well, it is called the Singleton Pattern.<\/p>\n

Singleton Pattern
\n<\/strong><\/h2>\n

The Singleton Pattern is a derivative of the Factory Pattern that ensures that one and only one instance of an Object can ever exist. By creating one or more implementations of the Singleton Pattern within a given application, the concept of \u2018global variables\u2019 can better be managed through tighter control. This allows for what is called lazy instantiation. If you do not need the variable based on what is going on in the application, then do not ask for or create an instance of one.\u00a0 In Objective-C, Apple has outlined the recommended technique for implementing the singleton pattern.<\/p>\n

\"Objective-C<\/p>\n

Objective-C Singleton Pattern<\/p>\n<\/div>\n

\nstatic MySingletonClass *sharedGizmoManager = nil;\n(MySingletonClass*)sharedManager{\n  if (sharedSingletonManager == nil) {\n    sharedSingletonManager = [[super allocWithZone:NULL] init];\n  }\n  return sharedGizmoManager;\n}\n(id)allocWithZone:(NSZone *)zone{\n  return [[self sharedManager] retain];\n}\n(id)copyWithZone:(NSZone *)zone{\n  return self;\n}\n(id)retain{\n  return self;\n}\n(NSUInteger)retainCount{\n  return NSUIntegerMax;\n}\n(void)release{\n  \/\/do nothing\n}\n(id)autorelease{\n  return self;\n}\n<\/pre>\n
But you may find that the following is all that is necessary:<\/p>\n
Singleton.h<\/strong><\/em><\/p>\n
\n#import <Foundation\/Foundation.h>\n@interface Singleton : NSObject {\n}\n+ (Singleton*) retrieveSingleton;\n@end\n<\/pre>\n
Singleton.m<\/strong><\/em><\/p>\n
\n#import "Singleton.h"\n@implementation Singleton\nstatic Singleton *sharedSingleton = nil;\n+ (Singleton*) retrieveSingleton {\n  @synchronized(self) {\n    if (sharedSingleton == nil) {\n      sharedSingleton = [[Singleton alloc] init];\n    }\n  }\n  return sharedSingleton;\n}\n+ (id) allocWithZone:(NSZone *) zone {\n  @synchronized(self) {\n    if (sharedSingleton == nil) {\n      sharedSingleton = [super allocWithZone:zone];\n      return sharedSingleton;\n    }\n  }\n  return nil;\n}\n@end\n<\/pre>\n
Try and keep each singleton\u2019s scope limited to manage only the information that is related to a particular use case and not as a catch-all for all global information across the application. It is probably best to utilize each singleton as a delegate to the information it is responsible for managing, and not use it as a means to gain access to any objects it has associations with. Although on the iPhone, and when being used in primarily a read only or a write seldom implementation, the risk of writing code that is not thread safe increases when utilizing shared objects. Keeping concurrency in mind, and utilizing the singleton as a delegate to the information at hand, one can watch out for multi thread related issues and deal with them in kind. One thing to watch out for would be include updating or setting properties of the singleton from within an implemented perform selector or a notification. If concurrency issues do arise, it may become necessary to synchronize access to certain properties or methods.<\/p>\n
No, not the AppDelegate!<\/strong><\/h2>\n
So why not just keep adding properties to the AppDelegate? After all, the AppDelegate is a singleton as well and is therefore accessible by invoking the sharedApplication class method. The problem with this techniques is that you end up loading up the application with too much information that may or may not be necessary depending on what functions the user chooses to evoke. It could also lead to longer and longer startup times. Get the application started as quickly as possible, and don\u2019t leave the user hanging for too long.<\/p>\n
What about Global Constants?<\/strong><\/h2>\n
Keep in mind that this is not the best technique to employ if all you need is a means to define and gain access to Global Constants. The quickest way to do that is to create a Precompiled Prefix Header file and include that in your project. By default, most of the projects generated in XCode that create iPhone Applications will include a file with an extension of .pch. This file will initially look like the following:<\/p>\n
\n#ifdef __OBJC__\n#import <Foundation\/Foundation.h>\n#import <UIKit\/UIKit.h>\n#endif\n<\/pre>\n
One can then add any number of #define statements that will be included in all header files across the entire project.<\/p>\n
\n#define SOME_STRING_CONSTANT @"My Important String"\n<\/pre>\n
Conclusion<\/strong><\/h2>\n
The Singleton Pattern can be used to make the complex and ugly means of sharing a simple variable between two different views or view controls an easy task. If used sparingly and some basic guidelines are followed as not to bloat the application and create a multi thread nightmare to debug, this technique can be quite useful. Much more so than passing Objects back and forth among views or by breaking the encapsulation of the AppDelegate by assigning it more responsibility than it should have.<\/p>\n
References<\/em><\/p>\n