I would like to take a singleton class that gets used by multiple view controllers, copy it, and save it to an array that will be displayed in another view controller with a table view that will show multiple instances of that class. This array will eventually be archived to be retrieve with the same data.
Before I attempt this, is there a way I can duplicate this singleton instance, save it to the array, re-initialize it for the next use, and so on (without getting the same exact previously uninitialized object)?
It's not a singleton that you want.
A singleton must always return the same instance.
What you want is a normal class that maybe have a convenience class method to feed you some pre-populated object.
If it's possible to create more than one instance of an object it's not a singleton anymore.
But your singleton class could hold a variable amount of instance of other class that you wish to display.
So in that way what you are asking could be possible, but without the copy part on the singleton.
I'm not sure where you are going with this and if it's the best way to
go but here is an idea :
you can have a singleton class that would hold an array of an other class. So you could call your singleton like this
TheSingletonClassName *mySingleton = [TheSingletonClassName sharedTheSingletonClassName];
OtherClass *myOtherClass = [mySingleton newOtherClassInstancePlease];
In your newOtherClassInstancePlease method you implement the necessary thing to store that new object into an array, that you can distribute like this
NSArray *otherClassArray = [mySingleton allOtherClasses];
Or NSMutableArray if you prefer.
With that you would be able to share, create new and even delete object. if you implement the necessary method on your singleton.
But again don't copy a singleton, if the singleton is well implemented sending it a copy call should throw an exception, or return the single singleton instance that exists.
Related
We always make singleton object through Class method.What will happened if i make that method instance(use - instead of +) and call that method through a nil object or simply through an object?
Conceptually a the instance method is not attached to any specific instance of a class.
This means that from a design point of view it doesn't make sense to invoke it on an existing object. It's like requiring that a +(int) sum:(int)a with:(int)b should be an instance method when it doesn't need to know anything about an object.
In addition usually a singleton class constructor shouldn't be accessible from clients, if you need to instantiate one to call -instance on it this would defeat the purpose.
Last thing, a singleton should be the only possible instance of an object, if you need to have one to instantiate one then you are in a deadlock: you need an instance to create an instance but you are no allowed to have more than an instance.
Regarding calling it on nil object, if I remember correctly a pointer returned from a message sent to nil will always be nil too.
In my app I'm using singleton class (as sharedInstance). Of course I need to use data that is stored in that singleton in multiple classes (view controllers).
Because writing
[[[SingletonClass sharedInstance] arrayWithData] count] or
[[[SingletonClass sharedIntanse] arrayWithData] objectAtIndex:index] or some other methods that you use on array is not comfortable I thought to, in the begining of lifecycle of non-singleton class, assign property (strong, nonatomic) of that non-singleton class to have the same address as SingletonClass.
self.arrayPropertyOfOtherClassOne = [[SingletonClass sharedInstance] arrayWithData]
and in some other class
self.arrayPropertyOfOtherClassTwo = [[SingletonClass sharedInstance] arrayWithData]
Is it good programming practice?
In my opinion there is nothing bad with it. Properties will point to the same address as property in Singleton and after non-singleton class will be destroyed also properties that where pointing to singleton so Reference Count = Refrence count - 1.
Am I correct?
In my opinion there is nothing bad with it.
Generally you would want to maintain a pointer to the singleton, not to some object that it contains. By keeping a pointer to the object it contains you are adding a harder dependency and a requirement that that object doesn't change or changes in some defined way. If you have defined and documented that then it should be ok, but, usually the singleton should be able to destroy that object and create a new one as required so you may want to rethink keeping a reference to it.
Keeping a reference to the singleton itself is fine because that will never be destroyed.
Properties will point to the same address as property in Singleton
True
and after non-singleton class will be destroyed also properties that where pointing to singleton so Reference Count = Refrence count - 1.
True
I have a simple custom object ("Ingredient") with instance variables, class methods, and instance methods. This custom object is inexorably entwined throughout my application. I want to store instances of this custom object using Core Data. From what I have read, having instance variables and methods in managed objects are discouraged.
So now I'm confused on how to proceed.
From examples of similar situations, it seems that it is common practice to fetch the results and put it in an array like so:
NSMutableArray *array = [managedObjectContext executeFetchRequest:fetchRequest error:&error];
But I am unclear what I can do with the mutableArray of objects. Can I do all the things I want to do currently with my custom object: modify instance variables, send the object to methods, etc?
Or do I create a "ArchivedIngredient" managed object with attributes matching my "Ingredient" instance variables, using my "Ingredient" object as I currently do - then convert "Ingredient" back to a "ArchivedIngredient" object when I need it stored? If so, how would that be done?
What am I missing here?
From what I have read, having instance variables and methods in managed objects are discouraged.
I do not now what you mean by this, but if what you mean is that you are not supposed to create classes based on your core data entity, you are wrong. You can use the core data inspector to assign a custom class to your entity, and create the header and source file of the implementation of that class by selecting the entity on your model, and using Xcode's product menu to find "Create NSManagedObject Subclass". This will generate your NSManagedObject subclass. You can add instance method and class method, just like other classes.
When you modify a property of your custom class, and you wish to save these changes, you need to get the managed object context you used to fetch the object and call the save method. This will put the changes in the persistent store.
Also, note that the method you are calling "executeFetchRequest" does NOT return a mutable array. It returns a immutable subclass of NSArray, which you must treat as an NSArray.
I'm working with game center and wanted to have a singleton class for accessing the GK functionality which I've setup, but I then introduced a couple of methods which needed a delegate. Obviously delegates can't really work properly with a singleton, but I want/need the data loaded in this class to be loaded once and be there all the time.
Is there a nice way that I'm missing of keeping the data there all the time, but having the class instantiated as and when it's needed?
Yoy say "singleton class", and by that I assume you mean that this class only has class methods. That's fine, you can still use it, since class objects are still objects. That said, you will probably need to maintain state. Each delegate call will include some parameter that allows the object to identify the sender.
What I would probably do myself is create a NSMutableDictionary in an "initialize" method, then have objects register themselves before sending delegate methods, and when they register create another mutableDictionary, and save that in the first one with the sending object as the key (or some other unique identifier).
Every delegate call has to include the sender, and with that you can retrieve the dictionary associated with that object.
I have a custom ViewController class and many instances of it, and I want them all to be able to message the same Model (another custom class, only one instance). Passing pointers to the Model along to new instances of the ViewController seems impractical, especially since the model is lazily instantiated. What is the cleanest, most idiomatic, ARC way to do this?
Usually a singleton in ObjC will have a class method that serves as an accessor for the single instance. The convention is for this to be called either defaultX or sharedX. If your model class is indeed a singleton, you should already have such a method. Since class names are globally available, all you have to do to access the instance anywhere in your program is [MyModelClass sharedModel].