another why: NSDictionary or NSArray (mutable or not)

[tawpie]

OK, I think I understand the key-value part of NSDictionary... NSDictionary at its simplistic core to be another way to deal with an NSArray, which is of course an objectified C array. Is it a matter of programming style/preference to choose NSDictionary over NSArray, or are there specific situations or desired end goals that would influence one to chose one over the other? For instance, when dealing with external "files" or application preferences, the Apple example code likes to have things saved as dictionaries rather than say, character arrays or NSStrings. info.plist contains dictionary objects true, but is this because it's "better", or just because "that's the way it is". Would I be crazy to save non-plist data as an NSArray directly (not info.plist data, but something else like the type of wireless connection in operation during each of the last 10 visits to a particular website -- something for which I don't need the key-value pairing)?

Perhaps it would help me most for your ideas on a list of "dictionaries are good for this, that and this other thing" but if you want to do things like "thisListOfOtherStuff" then NSArray is better... BECAUSE:

[Delirium]

I've been using dictionaries when I want to have a list of associations of one object to another. For instance, if you wanted to keep track of which touch activated which subview on the screen, you'd have a dictionary list of UITouch and UIView objects, where one is the key and one is the value.

[tawpie]

so perhaps I should think of a dictionary as an array of objects and think of the dictionary's "key" in the same way as I think of an array's "index"'? And then an NSArray (which holds objects too) is...???

[BuschyBoy]

The main distinction that often picks why I pick each one is that you can name items inside of a dictionary (Give them a key) where as an array simply has an index.

[Delirium]

I would use an NSArray when you don't need direct access to a specific item, and are just interested in having a list of same typed objects to loop through.

[tawpie]

thank you to all, this is quite helpful!

[smasher]

NSArray is more appropriate when you have a bunch of objects that are all the same type, and you're likely to loop through them in order. For example, a list of books could be put in an NSArray- book[0] is one book, book[1] is another book.

NSDictionary is more appropriate when you have objects (sometimes of different types) that you want to access by keys; often out of order. For example, an individual book could be represented as a Dictionary, where the key "sold" refers to a NSNumber for the number sold, and the key "Title" points to an NSString for the title of the book.

Note that I said "most appropriate," not "only used." You could "abuse" NSArray by putting objects of different types in it, and remember that index 0=number sold and index 1=title, but when you try to add a title without adding the number sold first, you'll see the wisdom.

In my own application a list of workouts is an NSMutableArray, each workout in the array is an NSDictionary, and and the key "exList" in that dictionary points to an NSArray full of exercises.

[Chris Stewart]

I find it helpful to understand the details of the respective data structures in determining which to use for a problem. A dictionary is essentially a hashtable. The benefits of a hashtable is in the insertion, deletion, and search. The Big O notation for a hashtable is described as O(1), which is constant time and is the fastest. Because of the hashing nature of the keys, it's a 1 to 1 mapping between a key and a memory location. So there's no searching up and down segments of memory. Hence, the O(1) constant time evaluation. The drawback to a hashtable is the random nature in which the data stored is distributed in memory. The various nodes are not stored contiguously in memory. To the developer, that means it's not a data structure that benefits from looping through the nodes one by one.

An array, at it's core, is a very inefficient data structure because most people use a data structure by adding nodes to it. It's major benefit is that the nodes are stored contiguously in memory, so going from node to node in sequence is easy and fast. Adding elements to an array is a seriously expensive process because essentially the memory is allocated for the array each time a new node is added. As an example, if you start with 0 nodes, your array is empty and using "no" memory. Add a node and a new array is created, the old array is copied in, and your new node is added to the end. Repeat this process for all nodes added. You can quickly see this problem grows exponentially, which drastically effects it's Big O notation, and describes the structure as being slow.

Of course, this is the fundamental stuff. Real world scenarios determine which structures are used. Use which is best for your needs.

[tawpie]

bingo! I get hash tables and all the complexity and beauty they bring, thank you for equating the dictionary as such. Makes things very clear as to "why".

It also appears that with mutable dictionaries, one can be pretty casual when adding entries... I need to look again carefully but it looks a lot like you just setObject:forKey and you're off and running. (more care must be taken when removing entries though!) It also appears that the ability to write a dictionary easily is kind of nice, although there is a warning that the plist format isn't for general persistent storage -- do plists get clobbered somehow?