iOS HOw many times this blocks of code in table view gets executed?

[bluehill]

HOw many times this blocks of code in table view gets executed and Why?

(Cell height is 60)

I did print the Orange text in nslog and found that it executes maximum 7 times when i have 20 records in table and 8 times when i have 100 records

(I know it executes 6 times for 6 records which fits in screen)

	if(cell == nil){
		[COLOR="DarkOrange"]NSLog(@"getcellcontent");[/COLOR]
		UITableViewCell *cell = [[[UITableViewCell alloc] initWithFrame:CellFrame reuseIdentifier:cellIdentifier] autorelease];
		[cell setSelectionStyle:UITableViewCellSelectionStyleNone];
	}

It has 5 records which fits in screen and some part of 6th record, so it should execute 6 time.. Then why does it executes 7 or 8 time when it can use already created cell.

 

[robbieduncan]

Do you not think the method that the code is in might be important?

 

[bluehill]

Do you not think the method that the code is in might be important?

ofcus this comes under tableviewcellforrowatindexpath

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *MyIdentifier = @"MyIdentifier";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:MyIdentifier];
	
	if(cell == nil){
		NSLog(@"getcellcontent");
		UITableViewCell *cell = [[[UITableViewCell alloc] initWithFrame:CellFrame reuseIdentifier:cellIdentifier] autorelease];
		[cell setSelectionStyle:UITableViewCellSelectionStyleNone];
	}
......
.....
.....
// other code

}

 

[PhoneyDeveloper]

HOw many times this blocks of code in table view gets executed and Why?

Why do you ask? The table view has its own rules and it doesn't tell what they are. You shouldn't need to know.

 

[bluehill]

Why do you ask? The table view has its own rules and it doesn't tell what they are. You shouldn't need to know.

For knowledge... to fill the gap..

i debugggggged lot of time but was not able to reveal ...

 

[seepel]

For tableviews I've found that as I'm scrolling sometimes it will decide that it should look a bit further ahead than just the next cell, so if 6 cells fit the screen, it looks ahead one then you create 7 cells. If you scroll faster, maybe it needs to look ahead 2 cells and thus you have to create 8 cells in total, etc...

 

[PhoneyDeveloper]

The design of the tableview is such that you really don't have to know how many times it will be called.

You have an idea of when it will be called but only a general idea. It's called whenever a cell is to be put on screen or when a cell is refreshed. This means reloadData, reloadRowsAtIndexPaths cause it to be called. Also user scrolling. Probably also deleting rows if that makes a new row scroll in from the bottom.

There are probably other times that you can't clearly determine.

In most cases there will only be a few more cells in existence than can fit on the screen.

 

[bluehill]

The design of the tableview is such that you really don't have to know how many times it will be called.

You have an idea of when it will be called but only a general idea. It's called whenever a cell is to be put on screen or when a cell is refreshed. This means reloadData, reloadRowsAtIndexPaths cause it to be called. Also user scrolling. Probably also deleting rows if that makes a new row scroll in from the bottom.

There are probably other times that you can't clearly determine.

In most cases there will only be a few more cells in existence than can fit on the screen.

Thanks for replying....
i need to explain what i understood but have a pending project so will post later...thanks

 

[bluehill]

The design of the tableview is such that you really don't have to know how many times it will be called.

You have an idea of when it will be called but only a general idea. It's called whenever a cell is to be put on screen or when a cell is refreshed. This means reloadData, reloadRowsAtIndexPaths cause it to be called. Also user scrolling. Probably also deleting rows if that makes a new row scroll in from the bottom.

There are probably other times that you can't clearly determine.

In most cases there will only be a few more cells in existence than can fit on the screen.

Thanks for replying...
But i discovered that it allocates memory to cells only visible on screen or as "seepel" said "it looks ahead 1 or 2 cells more which doesn't fit screen and allocate memory to those" (so total of maxmimum 8 cells gets memory with cell height 60)...

And when table is reloaded it never calls the block (1st thread in this post) again and mainpulates with the existing cells with alloctated memory...

So if i want to make any changes with a particular cell(assume 3rd cell only) of the table like i have to show DisclosureIndicator then this gets applied to some of the other cells too once i scroll through the table.

From which i concluded that when we scroll the tabelview, new values sets to one of the cell with allocated memory, but it doesn't releases the already set property (in our case DisclosureIndicator ) for that cell unless forced.

Here is sample code it is edited if any syntax mistake ignore it..

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *MyIdentifier = @"MyIdentifier";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:MyIdentifier];
	if (cell == nil) {

		cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleValue2 reuseIdentifier:MyIdentifier] autorelease];
		[cell setSelectionStyle:UITableViewCellSelectionStyleNone];
	}
	
    NSString *txt = [arraySample objectAtIndex:indexPath.row];
	cell.textLabel.text = txt;
	if ([txt isEqualToString:@"Sample"]) {
		[cell setAccessoryType:UITableViewCellAccessoryDisclosureIndicator];
		}
	}									 
    return cell;
}

 

[amorya]

So if i want to make any changes with a particular cell(assume 3rd cell only) of the table like i have to show DisclosureIndicator then this gets applied to some of the other cells too once i scroll through the table.

From which i concluded that when we scroll the tabelview, new values sets to one of the cell with allocated memory, but it doesn't releases the already set property (in our case DisclosureIndicator ) for that cell unless forced.

That's correct. That's what the dequeueReusableCell… call is all about: it allocates enough cells to display at once, and as one gets scrolled off the top it reuses it to scroll on the bottom.

Your code looks nearly right. You just need to change this:

if ([txt isEqualToString:@"Sample"]) 
{
	[cell setAccessoryType:UITableViewCellAccessoryDisclosureIndicator];
}

to this:

if ([txt isEqualToString:@"Sample"]) 
{
	[cell setAccessoryType:UITableViewCellAccessoryDisclosureIndicator];
}
else
{
	[cell setAccessoryType:UITableViewCellAccessoryNone];
}

Basically if there's anything you change in your cells (accessory view, text label), that has to be set every time a cell is displayed, even if it's supposed to be empty: you can't assume the cell will arrive empty.

 

[bluehill]

That's correct. That's what the dequeueReusableCell… call is all about: it allocates enough cells to display at once

So have u got how dequeueReusableCell works... it takes same Identifier (string) and generates multiple instance of cell..
and when table is scrolled it just reuses those without creating new cell..

 

[hayesk]

To answer the original question, because it may be possible to scroll faster than the device can create cells and it doesn't know which direction you are going to scroll next. Basically, it has a couple extra made to improve scrolling performance.

But as the others have said, you don't really need to know.