UITableViewCell标记不需要的缩进

Question

I've just updated an Objective-C iOS app to use the "new" iOS 8 storyboard. After updating all constrains, I noticed that while scrolling, some title labels (customs cells) seem to indent, what is not what I want them to do. It seems to always happen when I change the scrolling direction, but I'm not entirely sure about how to reproduce it. I have no idea where to search for a solution, but I'm pretty sure it doesn't have anything to do with the constrains. Below is a picture of some cells. The first two are properly indented, the last two not.

What can I do to prevent this indentation?

Answer 1

In your cellForRowAtIndexPath method, you could instead add a label onto your cell as a subview with your custom text.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

    cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        cell = [[UITableViewCell alloc] init];
    }

    UILabel *title = [[UILabel alloc] init];
    title.text = @"my text";
    title.frame = CGRectMake(0,0,desiredWidth,rowHeight); // setting the origin at (0,0) should position the label over that indentation you don't want
    [titleview addSubview:title];

    return cell;
}

Answer 2

I ran into this issue as well and did some research.

To reproduce it, it seems like you need a custom table view cell that uses auto layout to lay out its subviews. The indentation occurs when the table view is scrolled AND the scroll direction is changed AND the affected cell moves outside the visible screen AND subsequently back in view again WHILE the finger is not lifted off the screen during the change of direction.

The obvious first suspect was cell reuse. Overriding prepareForReuse in the custom cell implementation like this seems to solve the problem:

-(void)prepareForReuse{
    [super prepareForReuse];
    [self layoutSubviews];
}

The question is whether or not this is a bug. It does seem like something happens that invalidates the auto layout constraints when a cell is queued for reuse. Further research (breakpoints, NSLog etc) shows that all the layout constraints remain in place with correct values. From there comes the conclusion that layoutSubviews could probably solve the problem, which turned out to be the case.

Is it a bug? Maybe not. The docs for prepareForReuse say:

For performance reasons, you should only reset attributes of the cell that are not related to content, for example, alpha, editing, and selection state. The table view's delegate in tableView:cellForRowAtIndexPath: should always reset all content when reusing a cell.

So a strict interpretation of that would be that when auto layout is involved you probably have to re-leyout in tableView:cellForRowAtIndexPath: by calling layoutSubviews on the cell from there, since the auto layout constraints are part of the content. This also seems to indicate that prepareForReuse might not be the intended place to re-layout. Anyway, both ways seem to do the job, if someone knows more details as to which way is better, please feel free to comment.

Answer 3

Are you changing view frames or some other UI programatically?

Sometimes this happens if you are using auto layout and also changing views programatically.