iOS 7 didSelectRowAtIndexPath in UITableView Returning Wrong Index

1,170 views
Skip to first unread message

Jerry John Jacob

unread,
Nov 19, 2013, 11:00:39 PM11/19/13
to rubym...@googlegroups.com
We were developing an app and ran into a small problem.

We have a tableview inside another tableview (Pulse-like UI) and have implemented the didSelectRowAtIndexPath callback in our app to detect selections. Until iOS 6, it worked just fine. But after upgrading our test device to iOS 7, we realised that we are getting wrong values for indexPath.row on click of a cell. What could be the problem?

Here’s a little information we found when we tried to debug:
– We logged the value of indexPath.row on clicking and found that the value was actually corresponding to the cell that was in the same place as the cell we clicked before scrolling.
– For instance, we have 6 items in our inner tableview, showing 3 at a time. The indices of the items are 0, 1, 2 … 5. Initially, we will be able to see 0, 1 and 2. Upon scrolling to the very end, we will be seeing 3, 4 and 5. But when we click on 5, we sometimes get indexPath.row is 2. Similarly on scrolling backwards from this state, when we click on item 0, we get indexPath.row is 3.

We realised that our environment is not updated (OSX 10.8.2, RubyMotion 2.6, Xcode 4.6). Could this be the problem? Do you think upgrading to OSX 10.9 and Xcode 5 will fix the issue?

Thank you.

Michael Hayes

unread,
Nov 19, 2013, 11:26:17 PM11/19/13
to rubym...@googlegroups.com
Are you using `dequeueReusableCellWithIdentifier`? It sounds like a dequeuing problem.

Jerry John Jacob

unread,
Dec 2, 2013, 6:41:38 AM12/2/13
to rubym...@googlegroups.com
Apologies for the delayed reply.

Yes, we are using dequeueReusableCellWithIdentifier.

What is puzzling is that iOS 6 seems to be handling it well.

Hjalmar Ståhlberg Nordegren

unread,
Feb 4, 2014, 3:43:37 AM2/4/14
to rubym...@googlegroups.com
Hi! Did you find a solution to this problem? I seem to have it as well!

Jerry John Jacob

unread,
Feb 18, 2014, 12:43:17 AM2/18/14
to rubym...@googlegroups.com
No, I haven't been able to find a fix yet.

Md Aftabuddin

unread,
Mar 5, 2014, 5:39:38 AM3/5/14
to rubym...@googlegroups.com
Hi

 I have solved & used following code, You will try .....

  NSMutableArray *visibleCells; //  private declear
  BOOL isCellRefresh;   //  private declear

  visibleCells = [NSMutableArray array];   // In viewDidLoad

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
     int iSelectedRow = 0;
    if([[[UIDevice currentDevice] systemVersion] floatValue] >= 7.0 )
    {
        [visibleCells removeAllObjects];
        [visibleCells addObjectsFromArray:[tableView indexPathsForVisibleRows]];
 
       if([visibleCells containsObject:indexPath] && (isCellRefresh || [visibleCells indexOfObject:indexPath] > 0))
       {  
            isCellRefresh = NO;
            iSelectedRow = indexPath.row;
      }
      else if([visibleCells count] > indexPath.row)
      {
          isCellRefresh = NO;
           iSelectedRow =  [(NSIndexPath *)[visibleCells objectAtIndex:indexPath.row] row];
      } 
    else
    {
        [self.tableResturant scrollToRowAtIndexPath:[visibleCells objectAtIndex:0] atScrollPosition:UITableViewScrollPositionNone animated:YES];
        isCellRefresh = YES;

Jerry John Jacob

unread,
Mar 11, 2014, 8:58:53 AM3/11/14
to rubym...@googlegroups.com
I'll definitely try this solution out! Thanks!

One question - will there be any performance issues as a result of adding and removing the cells in the mentioned manner?

Md Aftabuddin

unread,
Mar 11, 2014, 2:16:17 PM3/11/14
to rubym...@googlegroups.com
Thanks, Yes ! It will be effect on performance but very very minor.
Reply all
Reply to author
Forward
0 new messages