This question already has answers here:
What's the difference between a dictionary and an array?
(6 answers)
Closed 10 years ago.
I'm in a dilemma in terms of which of the two I should use. I will be retrieving a group of data via a restful API (returns json) and I'm not sure how I should store them before I display it on my UI View Table.
eg.
{"Events":[{"Id":5,"Name":"Event 1 2013"},{"Id":6,"Name":"Event 2 2013"}]}
I've been reading tutorials and some would use NSMutableArrays while some would use NSMutableDictionary.
How should I go about it?
BTW: I'm displaying the data on UI View table that will redirect the user to another page when tapped and if they decide to go back will have to show the previous view without reloading (uses UinavigationController)
Thanks!
EDIT:
Also, just to give you an idea on what I'm trying to do. I'm trying to follow this tutorial on splitting the data I get into section headers. On this tutorial it's using NSDictionary.
http://www.icodeblog.com/2010/12/10/implementing-uitableview-sections-from-an-nsarray-of-nsdictionary-objects/
If I use NSArray, would that affect the performance?
In NSArray - every item in the collection has an integer index, so there is an explicit order to the items. When you're retrieving/replacing/removing the stored object from the NSARRY,you need to specify the corresponding object index of that stored object.
NSDictionary - derived from the word called entry. Each entry consists of one object that represents the key and a second object that is that key’s value. Within a dictionary, the keys are unique. That is, no two keys in a single dictionary are equal (as determined by isEqual:).When you're retrieving the object from the dictionary you need to specify the key value for the objectForKey
Whenever if you're parsing the plist then NSDictionary would be ideal.You can refer apple's document here for more explanation about NSDictionary.Happy coding :)
The lookup times on NSDictionaries are faster than on NSArrays. That's one of the main advantages. Here's a link to the Apple documentation.
Generally, if you need to access data in an indexed fashion (like you need to for rows in a table) then you should use an array because you can access any specific index using indexOfObject:
Now, if you have a lot of information for each row then you should have an array of either custom objects or an array of dictionaries.
Dictionary are always faster than Arrays. Dictionary maps keys to objects, just like a hash table. It's an associative array.
For searching some value you need to iterate for arrays, in dictionary you retrieve it by key.
If you want the collection to be in some sorted order or arrival order then Array is the proper type for you.
Dictionary lacks when you end up getting two same keys.
And I feel good to use arrays for tableViews as I can directly associate row to index.
Related
I have 4 values coming from json (name, ratings, reviews and Qualifications). I want to sort this data using name, reviews and qualifications one by one. But when I sort this data then remaining values are not changing in array.
Here is my code.
_arrOfDoc_name = [_arrOfDoc_name sortedArrayUsingSelector:#selector(localizedCaseInsensitiveCompare:)];
From comments:
I have to show four values on my screen which are coming from 4 different arrays. but when i sort one array then values of another arrays are not gng to sort and it displays wrong data on screen. how can i sort data of remaining arrays using its index path.
Ok, your comments explain what you're trying to do.
The best answer is to NOT use 4 different arrays. Restructure your data to have a single array that contains dictionaries. Then sort the array of dictionaries.
Failing that, you'll have to be clever. You might be able to create an array of indexes and sort that, or hand-write a sort routine that sorts all 4 arrays at once.
I've run into the same problem as found in this question. However, I have a follow-up question. I seem to be in the same situation as the original asker: I have a plist with a hierarchy of dictionaries that define a configuration screen. These are not mutable and will stay the same throughout the application. Since the original discussion seems to focus on problems arising from mutating the dictionary, I must ask for comfirmation: is the order of a dictionary guaranteed the same as they are in the plist, i.e. as it is read (with initWithContentsOfFile)? Can I use allKeys on it in this case to get a correct-order array of keys if the dictionary never changes?
No, the keys are not likely to appear in the same order as your plist file. I can't look under the hood, but I would guess that the keys are ordered in whatever way that provides an efficient look-up. The documentation for allKeys says that the order of the elements in the array is not defined.
If you need an NSDictionary that maintains order, take a look at CHDataStructure's CHOrderedDictionary, which does exactly that. I use it all the time.
I would not assume that the keys will be in any kind of order because allKeys does not guarantee order.
Internally, NSDictionary uses a hash table.
From allKeys description:
The order of the elements in the array
is not defined.
If you want to display values in some order then get the keys, sort the keys array and then get the value for each key.
Nothing at all is guaranteed about order. It’s not even guaranteed that iterating over a dictionary twice will give you the keys in the same order.
I've got a value like so: #"2329300" and I've got a NSDictionary like so :{#"John Appleseed":[#"2329300",#"2342322",#"32i249"]}
How do I find the index of the key/value pair in the NSDictionary when I've only got a string value of the entire list that's known as the value. I'm assuming there's no duplicates in the dict.
I know that there's indexForObject on a NSArray but is there a similar thing for a dict?
I imagine it would look something like this:
[NSDictionary indexForValue:value]; // returns index number.
And even then the NSString doesn't match the value, so I'd need a workaround for that too.
You have a basic misunderstanding. Dictionaries are unordered collections. They do not have any particular order for their key/value pairs. You can't have indexes to the key/value pairs because that implies a fixed order.
Think of a dictionary as a bunch of kids milling around on a playground. You can call out a kid's name "Johnny, come here!" and fetch that kid (use a key to find an object) but what does order mean for kids that won't sit still?
You can create an array of the keys from a dictionary and sort that into a particular order (an alphabetical list of the kids on the playground) if that's what you want, or you can create an array of dictionaries, or an array of a custom data object that contains any arbitrary properties that you want.
EDIT:
For a table view, an array of dictionaries is probably a good choice. Each entry in the array contains a dictionary with all the settings for a cell in the dictionary. If you have a sectioned table view then you want an outer array for sections, containing inner arrays for the rows, and each entry in the inner array containing a dictionary.
I tend to prefer custom data objects to dictionaries though. (An object that just has properties for each setting I want.) That way the list of values and their types is crystal-clear and fairly self-documenting.
I'm making a plist to hold genre synonyms. The list of synonyms for a given genre doesn't have any inherent order to it.
Should I use an array (which implies an order that doesn't exist) or a dictionary (which implies there's a corresponding value for each key, which doesn't exist).
Simply put--to store an unordered set in a plist, how should I represent it and why?
(To clarify: If there were a Set data structure in the plist editor, I would use that, but I only have Array and Dictionary to choose from.)
More details: I'm going to be looking up by the primary representation of the genre, thus the outer data structure in the plist has to be a dictionary.
But then for the synonyms, the only operation necessary is to enumerate them using a block.
So either an array or a dictionary will do. However, I'm concerned that using an array will imply an order that doesn't have any semantic meaning. On the other hand, is it a common occurrence to have dictionaries in plists that don't have a corresponding value?
Editing again to respond to Josh's comments:
I like your idea of converting into an NSSet after reading in the plist. However, I could still do that with a dictionary, right? So not sure why an array is the obvious choice.
If someone else edits the plist, they might think there's a meaning to the order, when in reality, the ordering is arbitrary.
Surprised no-one has defended using a dictionary instead of an array. Is there a reason a dictionary shouldn't be used in a plist for this purpose?
If you don't care about order, then the arbitrary order you get from building an array is equivalent to the arbitrary order you'd get by using a set. You can also very easily convert an array in a plist to an NSSet after reading it back: +[NSSet setWithArray:]
So use an array.
I would just use an array, since you say there's no corresponding key for a dictionary entry.
At the same time, if you're typing in a large number of entries into plist files (www), your fingers may get tired from dealing with the raw XML or plist editor stuff. You might want to consider a different way to save your synonyms?
Use an NSArray if lookup by item is not needed. If lookup is needed use an NSDictionary.
Is there a way to sum the values entered into a table view cell without using Core Data? I am currently using Parse. I guess a better question would be how can I get the sum using Parse? I'm really scratching my head on this one. Hand holding may be required.
You can probably use the Key-Value Coding collection operators. Suppose the row data for the table are a bunch of instances of class Entry and are collected in an NSArray named data. Further suppose each Entry object has an NSNumber property named cost and this is what you want to sum. Then you can do so as follows:
NSNumber *sum = [data valueForKeyPath:#"#sum.cost"];
Just to be clear: this does require that the values you wish to sum are properties of the objects that are backing each row.