UIEdgeInsetsMake creating a weird band on the cell, and I don't know how to fix it

Question

I\'m trying to use UIEdgeInsetsMake to make set the background of my cell to a gradient. I\'ve tried multiple things to get it to work, but no matter what I use

Answer 1

Update

As it turns out, I was wrong about the background, see the approved response.

On the other hand, adding a separator doesn't "solve" the issue, but it hides it pretty darn well, so my answer might still be valid in that sense.

Original post

My guess is that since you are trying to draw your own separator, the background that the tableView uses as "selected" background is already scaled considering the default separator style, I replicated the issue by putting UITableViewCellSeparatorStyleNone, and painted to cells with different colors:

Notice the tiny red line in between of the cells. Try setting the color of the separator (tableView.separatorColor) to match your style, and remove the bottom line from the asset.

Also, since we're talking about an stretchable asset, you should consider that the stretchable-image takes the insets as "this sides should be fixed" and the center region, gets copy-pasted all around, so, to have a truly stretchable graphic, you should do something like:

// For the top one
UIEdgeInsetsMake(38.0, 5.0, 5.0, 5.0)

// For the bottom one
UIEdgeInsetsMake(5.0, 5.0, 38.0, 5.0)

The key here, is that this leaves just one pixel tall of repeating pattern, which would be a solid color, and then the borders have the proper fade.

Here's the graphical explanation of the later, (I reused one file I made for the company designers and applied your dimensions):

(Notice the tiny red line in between of the cells)

Answer 2

Great news: you're not going crazy. Your stretchable image code is likely perfect. The problem is that UITableView with a grouped style adds extra points to the height of your cells in addition to the value you return in heightForRowAtIndexPath:

So the solution to your problem is to return an adjusted cell height in heightForRowAtIndexPath: based on the total number of rows in the section:

- (CGFloat)heightForRow:(NSIndexPath *)indexPath {
    CGFloat standardHeight = 44.0f;
    NSInteger numberOfRowsInSection = [self numberOfRowsInSection:indexPath.section];

    if (numberOfRowsInSection == 1) {
        standardHeight -= 2;
    }
    else if (indexPath.row == 0 || indexPath.row == numberOfRowsInSection-1) {
        standardHeight -= 1;
    }

    return standardHeight;
}

Here's a sample image showing how UITableView does this:

As far as I know, only the grouped style table views are affected, and even then the effect changes based on the total number of rows in a given section:

1. One Row Adds two points to the cell height (defaults height is 92 pixels on retina).
2. Two Rows Adds one point to the height of the first and last rows (90 pixels high each by default on retina).
3. Three Rows Adds one point to the height of the first and last rows (90 pixels high each on retina by default). The middle rows are unaffected.

This is so frustrating and has never been documented as far as I know. :-)

Update

The calculations above are for a grouped style table view using the default separator style of UITableViewCellSeparatorStyleSingleLineEtched. Here's what to do in the other cases (i.e. UITableViewCellSeparatorStyleSingleLine and UITableViewCellSeparatorStyleNone):

- (CGFloat)tableView:(UITableView *)tableView 
   heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    CGFloat rowHeight = 44.0f;
    if (indexPath.row == 0) {
        rowHeight -=1;
    }
    return rowHeight;
}

Answer 3

In your debugger output, the height of the second SettingsCell is 45 points, not 44 as expected. Note that this is the second one in the output, but it's actually shown in reverse order and this is actually the first table cell (you can see that from the frame values of the cells, this one being at y=46 while the other one is at y=91).

I believe that this causes your first cell's background misalignment in the second screenshot (and the stretching responsible for the white band you describe on the first screenshot, although I personally can't notice it) and that you can fix this by ensuring that your UITableViewCell is set to the correct frame height (44 points). This isn't in the code snippet you included in your question, but this is most likely in your – tableView:heightForRowAtIndexPath: method.

Once you have fixed this, edge insets of (5.0, 5.0, 1.0, 5.0) are probably what you intended since you don't wish to stretch the one-point bottom line. But (5.0, 5.0, 5.0, 5.0) and (5.0, 5.0, 0.0, 5.0) should look the same since there is no vertical stretching at all when the height of the bitmap and the height of the frame are exact matches.