I have a bunch of Boy objects and a bunch of Girl objects. I want to keep a list of the girl that each boy likes the most. It is OK if multiple boys like the same girl.
I was going to use an NSMutableDictionary, but the setObject: forKey: method of that class copies the key before adding the pair to the dictionary. So rather than the boy liking the girl, we would have a clone of the boy liking the girl.
Normally I would do this by adding a favoriteGirl property to the Boy class. But the problem is that the boys are really UIView objects, so I would have to subclass a bunch of different UIView subclasses.
Obviously I could write my own custom class to do this . . . but it feels like Apple must have a simple way to do what I want . . . what am I missing?
The speed of the lookup is important.
One option I thought of was to implement copying as a category on UIView objects, and just have the method retain the object. But I'm nervous about what side effects this might have.
EDIT: the girls are not UIViews. They are objects that contain information the boys will want to refer to from time to time.
You can do this with a CFMutableDictionaryRef (the Core Foundation equivalent of NSMutableDictionary). You can specify different options about how keys and values behave (like whether they're retained or copied, etc).
Using [NSValue valueWithNonretainedObject:] as the key is a better way, but be really careful that the objects will not be retained so you have to make sure to remove it from the dictionary when you release your original object.
I am not sure that I understand the model. Is it that you want to be able to map each Boy to a single favorite Girl? So, it would be okay to have a map from Boy to vector of Girl? If so, you could use std::map, std::vector > ... in other words, go over to Objective-C++ and use the Standard Template Library's map and vector containers.
It sounds to me that what you really need is separate model classes for Boys and Girls (then perhaps BoyView and GirlView if they're actually different, otherwise maybe a simple PersonView).
If you have a simple class to represent a Boy or Girl, then you can override isEqual: which I think would eliminate your issue with NSDictionary copying keys (though I'm not sure I entirely understand your model either).
Related
So I want to know if this is a good idea or a bad idea.
I'm building a simple iOS game (using standard UI Controls) which allows a user to create Characters, and Monster "Templates", then build Encounters which references Characters and Monsters and interact with them.
When the user creates an encouner, there is a simple Modal View which allows them to name the encounter, then push to another VC to select the characters participating, go back, push to a second view controller to select the Monster Templates involved, as well as how many of those monsters will be participating.
The goal, in the end, is to have the Monster Templates be used to construct "real" monsters that will be references in the Encounter.
Sample Encounter
Player Characters
Ramza Beoulve
Delita Hiral
Monsters
Orc 1
Orc 2
Orc 3
For the character selection piece, I used an NSSet to store the Character Entities selected and pass it between view controllers. (This way I avoid having to mess with the managed object context very much prior to actually saving the new encounter)
For the monsters, since I need to store a quanitity as well as the entity, it's a little more complicated.
So my original thought was to store them in an NSArray of NSDictionaries which in turn contain the Monster Template and the Quantity.
The problem with that approach is I have to loop through the NSArray and open each individual dictionary to check if a particular monster template exists or not.
It might not matter much at this scale of application, but it seems inefficient.
So I thought instead it might be better to simply maintain two NSMutable Arrays
NSMutableArray *selectedMonsterTemplates;
NSMutableArray *selectedMonsterTemplateQuantities;
This way I can simply call
[selectedMonsterTemplates containsObject:monsterTemplate];
when I need to check if something is already in there, and when I add or subtract the quantity for a particular monster, I can simply update both Arrays.
Then when the Encounter is saved I can simply iterate over the Array once to create my individual monster instances in the quantity desired, and associate them with the Encounter.
I'm concerned that this approach, while simple and efficient, might lead to concurrency problems if there is a small mistake in the code. Is there a better way to go about this?
Maybe its a better design to add a class, lets say TemplateStore. (Or whatever you like)
#interface TemplateStore : NSObject {
MonsterTemplate *template; //Super class of a monster entity.
NSInteger quantity;
}
- (id) initWIthMosterTemplate:(MonsterTemplate *)temp;
- (void) increaseQuantity;
- (BOOL) isKindOfTemplate:(MonsterTemplate *)otherTemp;
#property (readonly, retain) MonsterTemplate *template;
#property NSInteger quantity;
#end
WHen you store this kind of object in an array, you can iterate over it and use the isKindOfTemplate method to know if the MonsterTemplate exists. Then just increase the quantity.
Generally speaking, you wouldn't make an array of dictionaries just to hold structured data, you'd use a single dictionary with the item (template) as the key and the quantity as the value. Pseudocodey it would be like:
quantity=dict[template];
Of course that's assuming you have templates stored as pointers somewhere. A better alternative is to use structures:
struct monster_t { template_t t; int quantity; }
And then you hold an array of these things:
monster_t[] bestiary;
Or even better, figure out an ID of sorts (unique monster name file?) and hold it in a dictionary:
dictionary<string, monster_t> dict;
dict["big_monster_01"].quantity=5;
Of course this system is pretty useless, you don't care about quantity at all. What you do care about is about actual monster instances in the world, basically templates with customized values for hit stats, loot etc and a position:
struct monster_instance_t { monster_t template; vector position; }
monster_instance_t[] monsters; // who cares what they are?
// that's what polymorphism is for!
I am little bit backward in knowledge on these three topics: NSMutableDictionary, NSEnumerator, NSMutableSet. When I want to use them, it feels very hard, even when I've gone through the developer documentation.
Is there any sample code to understand it clearly for all three topics?
Please help me.
Thank you,
Madan Mohan.
The best way to understand these depends on what your prior experience is. NSDictionary is exactly what it sounds like: a dictionary. What that means is that given a key (or a headword, as in a dictionary), you can look up a value (or definition):
For instance, this dictionary gives information about my dog:
KEY VALUE
-------------------------------------------
#"name" #"tucker"
#"species" #"canis lupus familiaris"
#"favorite" #"biscuits"
With a dictionary dogInfo containing that information, we could send [dogInfo objectForKey:#"name"] and expect to receive #"tucker".
The difference between NSDictionary and NSMutableDictionary is that the latter allows changes after initialization. This lets you do things like [dogInfo setObject:#"fetch" forKey:#"game"]. This is helpful for maintaining state, memoizing referentially transparent requests, etc.
NSSet is a way to have a bunch of objects, with a few important bits: there is no defined order to those objects, and there can only be one of each object (no duplicates). Use NSSet for when you need to contain unique, unordered objects. NSMutableSet is the variant of NSSet which allows for changes (such as adding or removing objects) after initialization.
NSEnumerator is a bit more complicated, but you usually won't need to deal with it unless you are writing your own libraries, are coding archaically, or are doing complex enumerations. Subclasses of NSEnumerator are used by collection classes, such as NSDictionary, NSArray, and NSSet, to allow their objects to be enumerated. Usually, you'd just enumerate over them using a foreach-loop, since they all implement <NSFastEnumeration>. But sometimes, you'll want to do more specific things, like enumerate over the objects (instead of the keys) of a dictionary, or enumerate over an array in reverse. This is where instances of NSEnumerator (usually defined as properties on your collection objects) will become helpful.
Update
Justin in the comments pointed out that NSEnumerator conforms to <NSFastEnumeration>; that means, the chances are next-to-nothing that you'll need to know how to use an NSEnumerator; you can just do a foreach loop over the enumerator itself, like so:
for (id object in [dogDict objectEnumerator]) {
// doing something with the object, disregarding its key
}
How do I take a NSObject that I have set all the attributes of and then copy that into another block of memory that an array can use so I can re use the original one?
In short, you don't.
If you want to put the object in an array and then create a new object, do exactly that; addObject: to the array and alloc/init a new one.
If you are asking how you copy an object into, say, a random malloc() block somewhere -- say, in the middle of an array -- then that is a very different issue. It can technically be done, but basically no one does so as the frameworks and runtime aren't designed for that.
Without knowing more about your specific needs, it is impossible to go into more detail.
Making a copy of an object is done by sending it the copy message. This only works on instances of classes that implement the NSCopying protocol.
Read Implementing Copy for a good overview. Then read Implementing NSCopying Considered Harmful for some more background info.
I have an NSArray that contains two types of objects. Lets call them Apple and Orange.
Apple *myApple = [self.searchQueryResults objectAtIndex:indexPath.row];
When I am building my cell's I don't know what type is in my array, apples or oranges. How can I use the generic id type to store the object, and then cast appropriately?
You can use isKindOfClass:(Class)aClass to test the class type:
if ([myObject isKindOfClass:[Apple class]])
// do stuff
I'm not sure why you think you have to cast though. NSArray doesn't care what type of object you store in it, so when you pull it out, it'll still be the same object. But if you want you could still cast by doing something like
Apple *myApple = (Apple *)myObject;
Anyways, knowing the type of class it is should be enough for you to take appropriate action, since it's my understanding that you're showing both types in the same table, all you really need to do is appropriately display their different properties.
Don't mix types of classes in an NSArray.
You can do it, you can run checks for the type - but it's a really bad idea, UNLESS they are both part of the same subclass tree (say, both derivatives of Fruit). Then at least something looking in there can assume what kind of Fruit it might be, and check for particulars.
Basically you will save yourself a lot of headaches if you don't mix types in container classes, when somewhere down the road some bit of code figures for some reason there are only Apples in there but someone throws in a Pear. Then, BOOM!
I am implementing a class that has to store arbitrary objects together with a string. i.e.
myUIViewObject, #"that's a nice view"
myUIViewController, #"not really special"
myOtherObject, #"very important one"
this list can be extended and modified at any time, so I thought about using NSMutableDictionary here. But I am not really sure...
The object should be the key, i.e. I want to find easily the matching string for myUIViewController or myOtherObject when I ask for it like so:
- (NSString*)checkObjNoteStringForObject:(id)anyObjectInList;
The other problem is, that when an object gets added to that "list", I don't want it to be retained because of that. NSMutableDictionary retains it's contents, right? Could I just send a -release afterwards to undo this unwanted behaviour, and when removing from the list just sending -retain before doing so? Or is there a more elegant way?
What do you suggest? Thanks # all!
If your dictionary key is not retained, once it is deallocated accesses to the dictionary will lead to undefined behaviour (in practice, they'll crash if a lookup happens to hit that dictionary element). To do what you want, you need a strategy to remove the objects from the dictionary when necessary.
If you do have one – for instance, overriding the objects’ -dealloc and removing them from there – you can do what you want using +[NSValue valueWithNonretainedObject:]. The NSValue will refer to your object without retaining it, and the dictionary will copy the NSValue (keys are copied, not retained). Just remember to create an NSValue for each time you want to look something up in the dictionary; a helper function or method is a good idea.