What's the difference?
In my context, I need to be able to dynamically add to and remove objects. The user clicks on rows of a table that check on and off and thus add or remove the referenced object from the list.
A wild guess is that array has indexed items while set has no indexes?
An NSSet/NSMutableSet doesn't keep items in any particular order. An NSArray/NSMutableArray does store the items in a particular order. If you're building a table view, you should definitely use an array as your data source of choice.
Also, NSMutableSet makes sure that all objects are unique.
NSMutableArray goes well with UITableView since elements have index, so you can return [array count] to get number of table rows, or [array objectAtIndex:rowNumber] to easily associate element with row.
Also, according to the documentation, testing for object membership is faster with NSSets.
You can use sets as an alternative to arrays when the order of
elements isn’t important and performance in testing whether an object
is contained in the set is a consideration—while arrays are ordered,
testing for membership is slower than with sets.
Well there are 3 main differences. 1) Sets are unordered 2)Don't have an index & 3)Cannot have duplicate values where Arrays are ordered, indexed & can store duplicate values.
Related
I am using an NSFetchedResultsController in my UITableViewController.
Is it possible to specify a predicate that will not retrieve items which have duplicate fields in x number of fields that I specify.
For example, I want to search all results for items but if the itemName AND itemDescription AND itemQuantity are the same, I want only one of these items.
Option 1
When the page loads do a single run through the data and keep a list of objectID that are duplicate. For duplicate object set the row height of the cell to be 0. So they are technically still there, but you can't see it. This make dealing with the NSFetchedResultsControllerDelegate calls easy because no indexPaths have changed
Option 2
If the dataset is always selected in the same way and an object that is a duplicate is always a duplicate you can set an 'isDuplicate' in the object and filter it out in the predicate. Or you can not store at all in the first place. If objects are displayed in different sets and in different way and sometime should be displayed and sometime not be displayed this is not a good solution
Option 3
If you are sorting by the same criteria that make an object duplicate (that is duplicates always appear right next to a non-duplicate) and you are NOT using sections, then you can use sectionKeyPath. SectionKeyPath groups items together into sections. Group the duplicate and non duplicate together and then display every section as a single row (use the first item in each section). The indexPaths of the fetchedResultsController will not match the indexPaths of the tableview so you have to careful to convert them.
Option 4
Instead of accessing the objects from a fetchedResultsController do a fetch and and filter the array. Then use the array to display the objects. The downside is that you don't get updates on when objects change. This can be especially problematic is objects are deleted, as accessing a managedObject that's entity was delete can lead to a crash.
I recommend option 1
I have an NSMutableArray and I change the order of the contents of it. How can I save the order of it in core data without using a relation ship, or should I use NSUserDefaults?
Why not have a second array that is a copy of the first one at the time that you want to preserve its order? It need not be a mutable array - use [myArray immutableCopy]
If you don't want to copy all the items in the array for memory reasons, perhaps store the location as an NSInteger? Have the first array contain the items, and the second array contains indexes for the first array.
I have an array of simple objects. I wish to display these in a sectioned table view sorted alphabetically, the first section being "A", the second being "B", etc. The data-source of this table, i.e. the simple array, may be updated frequently (same every ten minutes).
I'm trying to figure out if its better to have an two dimensional array with each sub-array corresponding to a character in the alphabet / populating a section. Or use predicates to get the objects for each section & sort them alphabetically?
I'm leaning towards the multi-dimensional array approach as it might be less resource intensive than doing a search & sort predicate computation for each section?
Look at the UILocalizedIndexedCollation class and its associated sample codes. It is designed especially for this purpose.
You may be interested in this doc too.
I'm using a dictionary and an array to store the section title for a table view, along with the number of rows in each. I'm adding to the array and the dictionary in a loop of the records from my database in mu populateDataSource method.
I've got two dates from three records in my database. 2010-11-05 and 2010-11-07
I'm not sure if its because the table view events need to start at zero and the dictionary / array start at one ?
Or maybe my sectionTitles addObject, is added values each time, rather than adding unique dates. If so how i can search or only allow unique values ?
Any ideas ?
Arrays have a starting index of 0, but dictionaries don't essentially work that way. What is the purpose of the dictionary in this case? To get an object from the dictionary you give it a key. If you're going through a loop and not getting the expected result, maybe the dictionary isn't getting the key that it should be.
I thought that would be very common and easy iPhone App. In the main app I connect to database, retrieve values from database (NSDate converted to NSString)n and put into single array. Then in one of the views I populate UITableView with elements from the array. UITableView is grouped (sections). I step through array to discover number of sections (change section if new day). How do I retrieve correct element of array in cellForRowAtIndexPath? IndexPath.section and IndexPath.row seem useless as row starts count from zero for each section. If number of rows in each section was the same it would have been easy:
[arryData objectAtIndex:(indexPath.row)+indexPath.section*[tblMatchesView numberOfRowsInSection:indexPath.section]];
But number of rows in each section varies... :-)
Separate your data into arrays of arrays (based on the number of different days) once you get it from the database, that'd be the simplest solution...
How about storing different date sections in different arrays? For example, you can have an array A of array. You can loop through the original arrays yourself, if you found a new day, you just create a new array and put it into the array A. And then, when you loop over the cell, you can get the section number to get the correct array and based on the row number to get the correct elemenet in the array
It doesn't have absolute cursor but you can try utilizing
UILocalizedIndexedCollation class which is used to ease the "sectioning" of your data and proving the tableView delegate functions the required data such as the index titles, etc
Here's apple documentation link for it:
https://developer.apple.com/library/ios/#documentation/iPhone/Reference/UILocalizedIndexedCollation_Class/UILocalizedIndexedCollation.html#//apple_ref/occ/cl/UILocalizedIndexedCollation