Selecting multiple rows of a UITableView - iphone

This page
http://networkpx.blogspot.com/2009/07/multiple-row-selection-with-uitableview.html
mentions a way to implement table views that can allow multiple selections of rows.
At the time of this article, it seems that it was not a blessed way of doing this.
Now, apparently, Apple is allowing this kind of tableViews.
The article mentions this
NSArray* selectedRows = [tableView indexPathsForSelectedRows];
as a way of getting a list of all rows selected but this is not a legal functionality of the SDK.
The big question is: how do I get a list of all rows selected, so I can perform an action with them?
thanks
EDIT
To answer some questions... this is the code I am using to discover if a row is selected, but this is giving me zero entries.
NSMutableArray *selectedRows = [[NSMutableArray alloc] init];
for (int i=0; i<[list count]; i++) {
NSIndexPath *indexPath = [NSIndexPath indexPathForRow:i inSection:0];
UITableViewCell *aCell = (UITableViewCell*) [myTable cellForRowAtIndexPath:indexPath];
if (aCell.accessoryType == UITableViewCellAccessoryCheckmark) {
[selectedRows addObject:indexPath];
}
}
// selectedRows has always 0 entries... all cells give me their type as UITableViewCellAccessoryNone even those with checkmark

Apple will reject your app for for iOS 4 and below.
We found the following non-public API/s in your app:
indexPathsForSelectedRows

Create a NSMutableArray.
Whenever a table cell is selected insert the current indexpath in the array. whenever he deselects the cell remove it from the array. Final array will have everything you selected.
MultipleCheck in Table – UITableView Example with Demo
http://sugartin.info/2011/08/19/multiplecheck-in-table-uitableview/

Are you looking to have the user select multiple rows at the same time? If not you could create an array that holds each row that is selected as the user selects them.
Also for the check mark you could just subclass UITableViewCell.
How to subClass UITableViewCell and use it to not clear UILabel background color on UITabeViewCell selected?

Related

Iterate all cells in s UITableView

I want to iterate all uitablewview cells and display the text of a uitextview contained in each cell.
My table can have many rows and to reach all you must scroll. I made an implementation, but it displays the text only for current visible cells in scroll, for the others gives me null.
for (int i = 0; i < [propertiesTableView numberOfRowsInSection:0]; i++) {
UITableViewCell* cell = [propertiesTableView cellForRowAtIndexPath:[NSIndexPath indexPathForRow:i inSection:0]];
UITextView* tx = (UITextView*)[cell viewWithTag:2];
NSString* temp = tx.text;
NSLog(#"%#", temp);
}
How to fix this?
This happens because only the visible cells are instantiated (remember the dequeueReusableCellWithIdentifier: function?). You should extract the needed information from the table data source.
Yes this behavior is expected, because of performance considerations the table view does not holds all cells initialized all the time. Your solution is just to update your data source - if it's an array for example, iterate though it and change the values accordingly - this is the power of MVC (fast UI, separate model)

Referencing UISwitches within UITableCells

I have a table view which I'm using for some settings in my app. The tables cells are all default (no customisation at all), and simply contain some text for their label and a UISwitch for the accessory view.
My problem is that I need a reference to the switch so that I know when it has been switched on and off.
Currently I am setting the 'tag' property of the switch to be that of the cell's index within the table (grabbed from [indexPath row] in tableView:cellForRowAtIndexpath:).
This is fine when you only have one Section in your table, but I am now adding a new section. The problem is that they are both 0 based indexed so the switches in each section will end up reusing the tags - which isn't good.
Any suggestions on a better way to achieve this?
Thanks.
If you know roughly how many sections and rows you will have, like oh, say, not more than 1 million rows per section, just hash the section and row like this:
const int oneMillion = 1000000;
int tag = (section * oneMillion) + row;
slider.tag = tag;
Then, to figure out the section and row, reverse the logic:
int tag = slider.tag;
int row = tag % oneMillion;
int section = tag / oneMillion;
NSIndexPath *indexPath = [NSIndexPath indexPathForRow: row inSection: section];
Now get the slider that is in the cell in that section,row of the table
UITableViewCell *sliderCell = [tableView cellForRowAtIndexPath: indexPath];
UISlider *slider = [[sliderCell.contentView subviews] objectAtIndex: 0];
This assumes the slider is always the only view in the contents of the cell.
This method is a bit longer than some of the other suggestions above, but it keeps you from having to cache references off to the side.
For each cell, set a delegate link back to the table view controller, and also some kind of row reference ID - then wire the switch to a cell IBAction method, that calls back to the delegate with the reference ID for that cell.
What you can do is either have an Array of arrays or a dictionary, key it by the section number (or in case of the array they will be in order of the section numbers), now to retreive a switch all you do assuming you know the section and the row number
UISwitch *switch=[[switchArray objectAtIndex:section] objectAtIndex:row];
or if you have a dictionary
UISwitch *switch=[[switchDictionary objectForKey:section] objectAtIndex:row];

How can a UITableViewCell know of its own indexPath?

The standard Grouped UITableView style allows UITableViewCells to be drawn with rounded corners at the top and bottom of each section. How is this accomplished? How does the cell know its own location within its section, and how does it know when to change its rounded edges?
I want to make my own rounded cells, and I have images to use, but don't know when to show which image
Note: I already know how the UITableView works, and I know how to use it. I just thought that since a UITableView is able to automatically draw rounded corners at the correct places, I should be able to as well, without needing to add anything to my data source or delegate.
NSIndexPath *indexPath = [(UITableView *)self.superview indexPathForCell: self];
int rows = [(UITableView *)self.superview numberOfRowsInSection:indexPath.section];
if (indexPath.row == 0 && rows == 1) {
// the one and only cell in the section
}
else if (indexPath.row == 0) {
//top
}
else if (indexPath.row != rows - 1) {
//middle
}
else {
//bottom
}
It's very simple. suppose cell is the object, whose position is to be found out.
UITableView* table = (UITableView *)[cell superview];
NSIndexPath* pathOfTheCell = [table indexPathForCell:cell];
NSInteger sectionOfTheCell = [pathOfTheCell section];
NSInteger rowOfTheCell = [pathOfTheCell row];
There is sectionLocation method of UITableViewCell that returns integer telling you what you need:
1 - middle cell
2 - top cell
3 - bottom cell
4 - single cell
I had no issues using this in several production apps since 2010.
UPDATE: one of our binaries was automatically rejected recently (end of 2018) because we were using 'sectionLocation' property, so it's not a good option anymore.
Add something like this into your header files and you can use it:
typedef NS_ENUM(NSInteger, MMMTableViewCellLocation) {
MMMTableViewCellLocationUndefined = 0,
MMMTableViewCellLocationMiddle = 1,
MMMTableViewCellLocationTop = 2,
MMMTableViewCellLocationBottom = 3,
MMMTableViewCellLocationSingle = 4
};
#interface UITableViewCell ()
/** Undocumented method of UITableViewCell which allows to know where within section the cell is located,
* so the cell can draw its borders properly. */
- (MMMTableViewCellLocation)sectionLocation;
/** Override this one to know when the value of sectionLocation changes. */
- (void)setSectionLocation:(MMMTableViewCellLocation)sectionLocation animated:(BOOL)animated;
#end
You can use
- (NSIndexPath *)indexPathForCell:(UITableViewCell *)cell
for this issue. In my example I am using this to scroll the cell (with custom content) to the top of the view.
If you need more robust and general stuff, take a look at http://cocoawithlove.com/2009/04/easy-custom-uitableview-drawing.html - Matt Gallagher shows what you need, pretty effectively. He basically recreates UITableViewController from UIViewController, while adding ability to use your own custom graphics. I'm just working on applying this to one my projects, so far it looks it would do the job.
Unfortunately, I have found no solution to this problem, and have resorted to subclassing UITableViewController and UITableViewCell into a generic solution that I can extend as necessary.
You don't do this in cell. Rounded corners are drawn in [tableView viewForHeaderInSection] and viewForFooterInSection.
The way I do it is to use Plain tableview style, then use these two views for roundness and cells are normal, no rounds.
Without getting into who draws what, you can know which cell is the last cell in its section inside of cellForRowAtIndexPath very easily.
You're passed in the indexPath of the cell you need to provide, right? You're also passed the tableView.
call [tableView numberofRowsInSection:indexPath.section] and if it's == ([indexPath.row]-1) you know you're being asked to supply the last cell in that section.
At the time that cellForRowAtIndexPath is being called, the cell is guaranteed to be at the indexPath passed in.
To expand upon Darren's answer (which I found most useful, thanks Darren!), what you can do is to iterate through all of the superviews' until you find the parent UITableView. This should be future proof since you do not rely on a fixed hierarchy of views.
I use a recursive method that will return the UITableView if it finds one or return nil if there is none.
- (UITableView *)parentTableViewOf:(UIView *)view {
Class class = [view.superview class];
NSLog(#"Class : %#", NSStringFromClass(class));
if([view.superview isKindOfClass:[UITableView class]]) {
return (UITableView *)view.superview;
} else {
return [self parentTableViewOf:view.superview];
}
return nil;
}
So far I've used this one and it seems to work without hiccups. Hope it helps! :)
The cells dont know where they go...The table view has cells, You are the one telling the table view WHAT goes in the cell. You do this in the DataSource where you implement cellForRowAtIndexPath...The way this works :
An index path has a row and a section
For a grouped table view
A section pertains to a group, and a row pertains to 1 entry in that section,
the way UITableView knows how many rows are in a section and how many sections there are is the DataSources methods numberOfSectionInTableView and the method numberOfRowsInSection, this will make the right calls to cellForRowAtIndexPath, it is up to you to recognize which section and row is being queried and you need to build your cell according to these specifications.
A good way to do this i s you can have a Dictionary with keys of section names and values of NSArray with the values that go in that section.
So you implementation for numberOfSectionsInRows would look like
return [[dictionary allKeys] count]
And the implmentation of numberOfRowsInSection would look like
NSString* key=[[dictionary allKeys] objectAtIndex:sectionNumber]
return [[dictionary objectForKey:key] count]
You can always refer to the UITableView programming guide at http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/Introduction/Introduction.html
Hope that helps
Simply add a property to your custom UITableViewCell (depending on implementation) class that contains an int, NSNumber, or an NSIndexPath specifying which one it is. In you're using a data structure instead, then put it in you element in that data structure. Then you simply set the property when you create the data structure, something like elt.id=i, and then you access it in the cellForRowAtIndexPath, something like if (elt.id == 0 || elt.id == n-1) where n is the number of rows in your section.
I might have totally missed your question, but if I did, just comment and I'll post again.

UITableView: deleting sections with animation

Update
I have posted my solution to this problem as an answer below. It takes a different approach from my first revision.
Original Question
I previously asked a question on SO that I thought solved my issues:
How to deal with non-visible rows during row deletion. (UITableViews)
However, I now have similar problems again when removing sections from a UITableView.
(they resurfaced when I varied the number of sections/rows in the table).
Before I lose you because of the shear length of my post, let me state the problem clearly, and you can read as much as you require to provide an answer.
Problem:
If batch deleting rows AND sections from a UITableView, the application crashes, sometimes. It depends on the configuration of the table and the combination of rows and sections I choose to remove.
The log says I crashed because it says I have not updated the datasource and the table properly:
Invalid update: invalid number of rows in section 5. The number of rows contained in an existing section after the update (2) must be equal to the number of rows contained in that section before the update (1), plus or minus the number of rows inserted or deleted from that section (0 inserted, 0 deleted).
Now quickly, before you write the obvious answer, I assure you I have indeed added and deleted the rows and sections properly from the dataSource. The explanation is lengthy, but you will find it below, following the method.
So with that, if you are still interested…
Method that handles removal of sections and rows:
- (void)createFilteredTableGroups{
//index set to hold sections to remove for deletion animation
NSMutableIndexSet *sectionsToDelete = [NSMutableIndexSet indexSet];
[sectionsToDelete removeIndex:0];
//array to track cells for deletion animation
NSMutableArray *cellsToDelete = [NSMutableArray array];
//array to track controllers to delete from presentation model
NSMutableArray *controllersToDelete = [NSMutableArray array];
//for each section
for(NSUInteger i=0; i<[tableGroups count];i++){
NSMutableArray *section = [tableGroups objectAtIndex:i];
//controllers to remove
NSMutableIndexSet *controllersToDeleteInCurrentSection = [NSMutableIndexSet indexSet];
[controllersToDeleteInCurrentSection removeIndex:0];
NSUInteger indexOfController = 0;
//for each cell controller
for(ScheduleCellController *cellController in section){
//bool indicating whether the cell controller's cell should be removed
NSString *shouldDisplayString = (NSString*)[[cellController model] objectForKey:#"filteredDataSet"];
BOOL shouldDisplay = [shouldDisplayString boolValue];
//if it should be removed
if(!shouldDisplay){
NSIndexPath *cellPath = [self indexPathOfCellWithCellController:cellController];
//if cell is on screen, mark for animated deletion
if(cellPath!=nil)
[cellsToDelete addObject:cellPath];
//marking controller for deleting from presentation model
[controllersToDeleteInCurrentSection addIndex:indexOfController];
}
indexOfController++;
}
//if removing all items in section, add section to removed in animation
if([controllersToDeleteInCurrentSection count]==[section count])
[sectionsToDelete addIndex:i];
[controllersToDelete addObject:controllersToDeleteInCurrentSection];
}
//copy the unfiltered data so we can remove the data that we want to filter out
NSMutableArray *newHeaders = [tableHeaders mutableCopy];
NSMutableArray *newTableGroups = [[allTableGroups mutableCopy] autorelease];
//removing controllers
int i = 0;
for(NSMutableArray *section in newTableGroups){
NSIndexSet *indexesToDelete = [controllersToDelete objectAtIndex:i];
[section removeObjectsAtIndexes:indexesToDelete];
i++;
}
//removing empty sections and cooresponding headers
[newHeaders removeObjectsAtIndexes:sectionsToDelete];
[newTableGroups removeObjectsAtIndexes:sectionsToDelete];
//update headers
[tableHeaders release];
tableHeaders = newHeaders;
//storing filtered table groups
self.filteredTableGroups = newTableGroups;
//filtering animation and presentation model update
[self.tableView beginUpdates];
tableGroups = self.filteredTableGroups;
[self.tableView deleteSections:sectionsToDelete withRowAnimation:UITableViewRowAnimationTop];
[self.tableView deleteRowsAtIndexPaths:cellsToDelete withRowAnimation:UITableViewRowAnimationTop];
[self.tableView endUpdates];
//marking table as filtered
self.tableIsFiltered = YES;
}
My guess:
The problem seems to be this: If you look above where I list the number of cells in each section, you will see that section 5 appears to increase by 1. However, this is not true. The original section 5 has actually been deleted and another section has taken its place (specifically, it is old section 10).
So why does the table view seem not to realize this? It should KNOW that I removed the old section and should not expect a new section that is now located at the old section's index to be bound by the deleted section's number of rows.
Hopefully this makes sense, it is a little complicate to write this out.
(note this code worked before with a different number of rows/sections. this particular configuration seems to give it issues)
I’ve run into this problem before. You are trying to delete all rows from a section and then, in addition, that now empty section. However, it is sufficient (and proper) to remove that section only. All rows within it will be removed as well. Here is some sample code from my project that handles deletion of one row. It needs to determine whether it should remove only this row from a section or delete the entire section if it is the last remaining row in that section:
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
if (editingStyle == UITableViewCellEditingStyleDelete)
{
// modelForSection is a custom model object that holds items for this section.
[modelForSection removeItem:[self itemForRowAtIndexPath:indexPath]];
[tableView beginUpdates];
// Either delete some rows within a section (leaving at least one) or the entire section.
if ([modelForSection.items count] > 0)
{
// Section is not yet empty, so delete only the current row.
[tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath]
withRowAnimation:UITableViewRowAnimationFade];
}
else
{
// Section is now completely empty, so delete the entire section.
[tableView deleteSections:[NSIndexSet indexSetWithIndex:indexPath.section]
withRowAnimation:UITableViewRowAnimationFade];
}
[tableView endUpdates];
}
}
I notice that you're deleting the sections from the table first, and then deleting rows.
I know there's a complicated discussion of batch insertion and deletion for UITableViews in the Table View Programming Guide, but it doesn't specifically cover this.
I think what's happening is that deleting the sections is causing the row deletions to refer to the wrong row.
i.e. you want to delete section #2 and row #1 from section #4... but after you've deleted section #2, the old section #4 is now the third section, so you when you delete with the old NSIndexPath of (4, 1) you're deleting some random different row that may not exist.
So I think the fix might be as simple as swapping those two lines of code, so you're deleting the rows first, then the sections.
So finally here is my solution to this issue.
This method can be applied to tables of any size, any number of sections (as far as I can tell)
As before I have modified Matt Gallagher's tableview Code which places cell-specific logic in a separate cell controller. However, you can easily adapt this method to a different model
I have added the following (relevant) ivars to Matt's code:
NSArray *allTableGroups; //always has a copy of every cell controller, even if filtered
NSArray *filteredTableGroups; //always has a copy of the filtered table groups
Matt's original ivar:
NSArray *allTableGroups
…always points to one of the above arrays.
This can probably be refactored and improved significantly, but I haven't had the need. Also, if you use Core Data, NSFetchedResultsController makes this easier.
Now on to the method (I am trying to comment as much as I can):
- (void)createFilteredTableGroups{
//Checking for the usual suspects. all which may through an exception
if(model==nil)
return;
if(tableGroups==nil)
return;
if([tableGroups count]==0)
return;
//lets make a new array to work with
NSMutableArray *newTableGroups = [[allTableGroups mutableCopy] autorelease];
//telling the table what we are about to do
[self.tableView beginUpdates];
//array to track cells for deletion animation
NSMutableArray *indexesToRemove = [NSMutableArray array];
//loop through each section
for(NSMutableArray *eachSection in tableGroups){
//keeping track of the indexes to delete for each section
NSMutableIndexSet *indexesForSection = [NSMutableIndexSet indexSet];
[indexesForSection removeAllIndexes];
//increment though cell indexes
int rowIndex = 0;
//loop through each cellController in the section
for(ScheduleCellController *eachCellController in eachSection){
//Ah ha! A little magic. the cell controller must know if it should be displayed.
//This you must calculate in your business logic
if(![eachCellController shouldDisplay]){
//add non-displayed cell indexes
[indexesForSection addIndex:rowIndex];
}
rowIndex++;
}
//adding each array of section indexes, EVEN if it is empty (no indexes to delete)
[indexesToRemove addObject:indexesForSection];
}
//Now we remove cell controllers in newTableGroups and cells from the table
//Also, each subarray of newTableGroups is mutable as well
if([indexesToRemove count]>0){
int sectionIndex = 0;
for(NSMutableIndexSet *eachSectionIndexes in indexesToRemove){
//Now you know why we stuck the indexes into individual arrays, easy array method
[[newTableGroups objectAtIndex:sectionIndex] removeObjectsAtIndexes:eachSectionIndexes];
//tracking which cell indexPaths to remove for each section
NSMutableArray *indexPathsToRemove = [NSMutableArray array];
int numberOfIndexes = [eachSectionIndexes count];
//create array of indexPaths to remove
NSUInteger index = [eachSectionIndexes firstIndex];
for(int i = 0; i< numberOfIndexes; i++){
NSIndexPath *indexPath = [NSIndexPath indexPathForRow:index inSection:sectionIndex];
[indexPathsToRemove addObject:indexPath];
index = [eachSectionIndexes indexGreaterThanIndex:index];
}
//delete the rows for this section
[self.tableView deleteRowsAtIndexPaths:indexPathsToRemove withRowAnimation:UITableViewRowAnimationTop];
//next section please
sectionIndex++;
}
}
//now we figure out if we need to remove any sections
NSMutableIndexSet *sectionsToRemove = [NSMutableIndexSet indexSet];
[sectionsToRemove removeAllIndexes];
int sectionsIndex = 0;
for(NSArray *eachSection in newTableGroups){
//checking for empty sections
if([eachSection count]==0)
[sectionsToRemove addIndex:sectionsIndex];
sectionsIndex++;
}
//updating the table groups
[newTableGroups removeObjectsAtIndexes:sectionsToRemove];
//removing the empty sections
[self.tableView deleteSections:sectionsToRemove withRowAnimation:UITableViewRowAnimationTop];
//updating filteredTableGroups to the newTableGroups we just created
self.filteredTableGroups = newTableGroups;
//pointing tableGroups at the filteredGroups
tableGroups = filteredTableGroups;
//invokes the animation
[self.tableView endUpdates];
}
I saw this same exact error as the result of prematurely releasing the background view of my custom tableview cell.
With NSZombieEnabled I got a an exception being thrown way down below an internal call to a function to prepare the cell for reuse. Without NSZombieEnabled, I was getting the Internal consistency error.
Incidentally when I fixed the retain/release issue on the background view of the cell, I was able to delete the last row of the section without having to delete the section explicitly.
Moral of the story: This error just means something bad is happening when you try to delete, and one of the things that happens when you delete is the cell gets prepared for reuse, so if you are doing anything custom with your tableview cells, look for a possible error there.
I suspect that you are forgetting to remove the object representing the section from your internal storage, so that the -numberOfSectionsInTableView: method is still returning 1 after all sections are deleted.
That's exactly what I was doing wrong when I had the same crash!
A much simpler way to address this is to update your data source, then call reloadSections
[self.tableView reloadSections:[NSIndexSet indexSetWithIndex:0] withRowAnimation:UITableViewRowAnimationFade];
This will reload a single section. Alternatively you could use indexSetWithIndexesInRange: to reload multiple sections simultaneously.
or just do this
- (void)tableView:(UITableView *)tv
commitEditingStyle:(UITableViewCellEditingStyle)editingStyle
forRowAtIndexPath:(NSIndexPath *)indexPath {
if(editingStyle == UITableViewCellEditingStyleDelete) {
//Delete the object from the table.
[directoriesOfFolder removeObjectAtIndex:indexPath.row];
[tv deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath]
withRowAnimation:UITableViewRowAnimationFade];
}
}
directories of folder being your Array! Thats is all above codes didnt work for me! This is less expensive to do and just makes sense!

iPhone SDK: Inserting and updating a UITableView with a new row

I have a tableView that needs to be updated after information has been inserted from another view. If I perform a
[self.tableView reloadData];
The very next time I insert more information in another view and try to reload the table, all the currently visible rows are duplicated.
In other words, when I start up the app I have:
tableView:
Row 1
Row 2
Then I submit some information that will also show up in the table and suddenly I have:
tableView
Row 1
Row 2
Row 3 <- info I just added
Row 1
Row 2
My numberOfRowsInSection implementation looks like this:
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
return [ItemsController sharedItemsController].count;
}
My cellForRowAtIndexPath implementation looks like this:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
ItemsController* controller = [ItemsController sharedItemsController];
NSMutableArray* recentItems = controller.listOfRecentItems;
CustomCell *cell = nil;
NSUInteger row = [indexPath row];
if( row < recentItems.count )
{
Items* item = [recentItems objectAtIndex:row];
if( recentCellData == nil )
recentCellData = [[NSMutableDictionary alloc] initWithCapacity:[indexPath length]];
if( [recentCellData count] > 0 )
cell = [recentCellData objectForKey:[NSString stringWithFormat:#"%d", row]];
if (cell == nil) {
UIViewController * view1 = [[UIViewController alloc] initWithNibName:#"CustomCell" bundle:nil];
cell = (CustomCell*)[view1 view];
[recentCellData setObject:cell forKey:[NSString stringWithFormat:#"%d",row]];
}
// do some other stuff here
}
// Set up the cell
return cell;
}
What's the best way to update the table and avoid duplicating the currently visible rows.
Thank in advance for all the help!
The error isn't in how you're reloading the table, it's in how you're providing data to it. Set a breakpoint in the data source methods and the method that adds new rows to see where you're going wrong.
You'll only end up with five items if tableView:numberOfRowsinSection: returns 5. Thats the simple answer to your question, but I see other problems here. I'm wondering why you have this test: row < recentItems.count. Is that array the same thing as [ItemsController sharedItemsController].count? You really need to be using the same array for both methods.
(Also, it's not a syntax error, but you shouldn't use the property syntax for things that aren't declared as properties. You should write [recentItems count] instead.)
I'm also confused by the code you use to set up the cell. Cells are meant to be reusable. That is, you create one cell, then reconfigure it every time in your implementation of tableView:cellForRowAtIndexPath:. Your code creates a cell for each item in your list. This is very memory-inefficient, and will likely crash your program due to insufficient memory on the iPhone if you keep lots of cells in memory like this.
The recommended approach is to call dequeueReusableCellWithIdentifier:. If that returns nil, then you set up a cell using the initWithFrame:reuseIdentifier: initializer. The table view is very smart, and will only ask you to redraw the cell when it needs you to.
Your recentCellData dictionary looks really shaky to me, too. What if you insert an item after the item with key #"2"? All the items with key #"3" onward will need to be shifted one element to the right to work the way you expect. That's a ton of bookkeeping that seems rather unnecessary to me. If you really needed something like this -- and to be clear, I don't think you do -- why wouldn't you use an NSMutableArray, which is much easier to use?
I added a bit more info above.