I've been thinking about using a singleton on my data class in my current app. I've also been thinking of reasons not to use the pattern and currently I am stuck in the middle.
The reason I am for the singleton in this case is due to accessibility to methods and properties easily that I need to use more than once throughout the app. I could use the appDelegate for this but that muddles up the area of concern as these methods / variables have nothing to do with the app state - more to do with user input. The data will be persisted with eventually with NSUserDefaults - which is a singleton already.
The reason I am against it is because its another singleton to an app that already bass one (The appDelegate)
My question:
Would using another Singleton to access the data model be the correct way / acceptable way of doing it - or should I look at another approach?
I personally think there would be nothing wrong with a singleton as a data model - using the app delegate to instantiate it when the app starts and then access its various methods / properties when I need them throughout the app. This would be the only other singleton in the app (Maybe another one for user management - e.g.; logging in / out / profile / credentials, etc? )
Any thoughts?
Thanks all!
There is no problem having multiple singleton classes within ios, in fact in many of my projects most of the classes are singletons. Normally I have the data access logic and control within a singleton and then actual object classes as instances.
As you have already identified you really do not want to be putting something into AppDelegate that does not apply to the whole app.
From my point of view do not instanciate the class from AppDelegate, simply have the class instanciate itself on first access.
Whenever I am explaining singleton Objective-C to people I always direct them to this site, it may be worth a view for you:
http://www.galloway.me.uk/tutorials/singleton-classes/
It explains only what you need in a really easy to understand way. The bit that does the 'self-instanciating' is this bit:
+ (id)sharedManager {
static MyManager *sharedMyManager = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedMyManager = [[self alloc] init];
});
return sharedMyManager;
}
You could use singleton in these case. Don't use delegate to hold values for your app. You may use same singleton for user management also.
Note : Don't use globals unless you need to do so. Singletons and top-level data should be used only when the data they contain truly belongs at the top level.
Related
I understand that dispatch_once is something that is equivalent to a static variable and that the piece of code inside dispatch_once is executed only once throughout the application.
I am going through a huge code base and came across something like this
+ (DBHelper *)sharedInstance {
static DBHelper *sharedDBHelper = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedDBHelper = [[super alloc] initUniqueInstance];
});
return sharedDBHelper;
}
DBHelper.sharedInstance is used to get an object and is used in a lot of places ot generate objects.
I'm confused as to why dispatch_once is being used here since that would mean you could have only one object of the class?
This is the standard pattern for a shared instance, otherwise known as a faux singleton.
In many cases programmers choose to use a single object that can be easily accessed from any part of an application - by calling a static method which returns back a reference to the shared object, i.e. sharedInstance in your example - as a means to provide communication/shared data between otherwise independent parts of the application.
It is a faux singleton pattern as it does not prevent other instances of the same type - DBHelper in your example - from being created. A true singleton model is one in which only a single instance of the type can ever be created. (Apple used to have sample code showing how to create true singletons, but it was never updated for the post-ARC world, for more details on that including an ARC version see this answer.)
HTH
It's a singleton (a design pattern). You only need one instance of the class instantiated, so that's all you create.
I have doubts regarding the creation of singleton class in Objective-C/iOS.
Where ever I see the trick to create a singleton class in objective-C is this code
+ (id)sharedManager {
static MyManager *sharedMyManager = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedMyManager = [[self alloc] init];
});
return sharedMyManager;
}
Whenever I call [MyManager sharedManager] of course I get the same address. However, I can also write [MyManager new] in which case the address is different.
1.Isn't the concept of singleton class is that it restricts the instantiation of a class to one object?
2.If we can create another object its not a singleton anymore, is it?
In my iOS app I tried [UIApplication new]. I got an exception in runtime. Now this I get. You cannot make another instance of UIApplication since its a singleton class.
So why the use of shared instance considered to be the way of creating a singleton class or have I got this all wrong?
The sharedManager is the convenience method you'd use to access the singleton instance. While this doesn't guarantee that there will be only one instance of that manager over the app, if everyone is using sharedManager then there will practically exist only one instance of that manager.
This kind of singletons are singletons by convenience, not by implementation. You should use them, for multiple reasons:
you can unit test them, by calling alloc init in your unit tests and making use of that brand new allocated object
it makes your life easier if decide to later refactor the manager and no longer use it as a singleton if you consider it from the begging like a regular object to work with
Of-course, you can make a singleton by-the-book by overriding the init and allocWithZone: to either return the only instance or by raising an exception, however I'm not sure they'd worth the effort.
There's a very good tech talk regarding singletons held by Misko Hevery in the Google clean code talks playlist, the link to the video: here. This kind of singletons are referred as lower case S singletons, not capital S ones in the video, and Misko explains very well why they are preferred.
It doesn't break singleton concept. You choose your way to implement what you want. If you want to create only singleton instance, you can make run error by override init function:
[NSException exceptionWithName:NSInternalInconsistencyException
reason:#"bla bla bla..." userInfo:nil];
or
you can override it to force return to shared instance.
Of course, you can. But it not recommend if you are using singleton.
Objective-C uses a pragmatic approach. Your +sharedManager method returns a singleton. If someone is stupid enough to call [SingletonClass new] or [[SingletonClass alloc] init], that's their problem. They'll get what they deserve. There is no reason to prevent people from shooting themselves in the foot if that is what they want to do.
There are millions of programming errors that people can make and that the developer of a class or the compiler cannot prevent. No point wasting effort on preventing this particular error.
I've got a test project to use the private data object on several view controller.
(I've downloaded it from web & git-hub)
- (ExampleAppDataObject*) theAppDataObject;
{
id<AppDelegateProtocol> theDelegate = (id<AppDelegateProtocol>) [UIApplication sharedApplication].delegate;
ExampleAppDataObject* theDataObject;
theDataObject = (ExampleAppDataObject*) theDelegate.theAppDataObject;
return theDataObject;
}
First question is, theDelegate was casted with AppDelegateProtocol, even this applications UIApplication delegate name was ViewControllerDataSharingAppDelegate, and there's no warning. I can't under stand why, maybe it's because that was a id type?
(AppDelegateProtocol is a custom delegate protocol he declared in the AppDelegate.)
Second, it shows this kind of code on every view controller, and it seems like just a single-ton pattern.
I don't think this is not the best way to transfer data between view controller.
Which is the best way to transfer object data type?
Thanks.
Creating a protocol decouples the code somewhat from the specific implementation. You could conceivably have several applications, each of which uses its own custom class as an app delegate, but all implementations conform to the AppDelegateProtocol.
I used to use the app delegate to hold global data and methods a lot when I first started in iOS.
However, that fills your app delegate with app-specific code.
I've shifted away from that approach recently, and use a data container singleton (and perhaps a utility methods singleton as well.) As is typical for a singleton, I define a class method that lets me fetch the singleton. I add properties to my singleton as needed to store data, and then just use the class method to get a pointer to the singleton. I write my class method to lazy load the singleton.
Its also easy to make your data container singleton persistent by making it conform to NSCoding. Then every time you get moved to the background, just save your singleton somewhere. On app launch, read it in.
I need some advice about best practice of developing iOS app design
Here's what I'm dealing with: when iOS device looses internet connection (or doesn't have one and figuring that out) I want my app to go to some sort of offline mode, i.e. firing some event, sending some NSNotifications, m.b. showing some sort of alert etc. Accordingly, when iOS device gets it's connection back I want the oposite thing - move my app to some sort of online mode.
So, what I want is to have ability to access app's mode (i.e. to check whether app is online or offline) from within some of my ViewControllers. I'm thinking of two methods of storing app's state:
1) Have some AppDelegate's property and access it from anywhere via my AppDelegate. AFAIK, that's a wrong approach, because AppDelegate is not supposed to be used as global object for application, but for doing launch initialization and controlling application's state changes.
2) Store this information on Model level. But I have no idea what am I supposed to use on Model level for such purpose. I don't think using Core Data or NSUserDefaults is a good idea, because I don't want this property to be persistent, I need it only during current application running. And apart from Core Data and NSUserDefaults I don't actually know any other Model level techniques.
I don't include any code examples, because it's mostly a theoretical question.
you can use singleton pattern and store the variable as a property
for example
#interface GlobalData : NSObject
#property BOOL connectionAvailable;
+ (GlobalData *)sharedInstance;
#end
#implementation
+ (GlobalData *)sharedInstance {
static GlobalData *sharedInstance;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedInstance = [[GlobalData alloc] init];
});
return sharedInstance;
}
#end
// --- in some method
[GlobalData sharedInstance].connectionAvailable = /* connection state */;
// --- in some other method
BOOL connectionAvailable = [GlobalData sharedInstance].connectionAvailable;
The second approach works best. You surely don't need any persistence a property indicating the internet connection. A good thing to do is having your Model be a singleton class, that exposes a readonly BOOL property for the internet connection and your view controllers can subscribe to its changes via key-value observing. Your model can also implement internally the Reachability class for updating the internet connection status.
I'm assuming you're using Apple's Reachability class. http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html
I created a category on the Reachability class to add a sharedInstance singleton that allows you to check the state of the internet connection. I use this in all my apps.
Here's how you do singletons:
How do I implement an Objective-C singleton that is compatible with ARC?
I have been using app delegate as a "global bucket" to share data between various view controllers. Typically I do something like this:
My_AppDelegate *appDelegate = (My_AppDelegate *)[[UIApplication sharedApplication] delegate];
And then, I would stick data into the appDelegate, and pick up data from the appDelegate with another view controller. Somehow, this seems clumsy and inappropriate (although it does work).
Is there a better way? Can I set-up a "listener" on some kind of a global sharing area, if somebody sticks a data element in there, another object would get a 'call-back' to let it know that somebody has data ready for it?
In Java we used to do this with Observer/Observable class - maybe there is something like this, or better in iOS?
A cleaner, although not necessarily different, way to do this is to create a singleton class, e.g. AppData, which you can access in a variety of ways, and which would be available to all your other classes. It has the benefit of separating your app-specific stuff from the app delegate stuff. You might define the class this way:
#interface AppData : NSObject
// Perhaps you'll declare some class methods here...
#end
A common thing I do is define class methods on such a class to access, for example, settings values, or app-specific constants or other singleton objects. There are a lot of possibilities.
In the end, you can get a lot done with just class methods, that you would call something like [AppData theMethod]. Just remember there's no self to access inside a class method.
Taking it one step further, you can define ivars for the AppData class, and then manage a singleton instance of AppData. Use a class method, e.g. +sharedInstance, to get a handle to the singleton on which you could then call mehods. For example, [[AppData sharedInstance] someMethod:myArgument]. Your implementation of +sharedInstance can be where you manage the actual creation of the singleton, which the method ultimately returns.
I am not sure if I'd call this approach a "best practice", but I've found this pattern quite handy.