I've rumbled through new UI info from apple - didn't help.
Now let the code and the screenshots show you the problem i've ran into. To ensure that is not my buggy code, i've created a new project, with a single file - a UIViewController that has a tableView inside id. the delegates are set.
I do the following:
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
// Return the number of sections.
return 3;
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return 3;
}
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"UITableViewCell";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier];
}
cell.textLabel.text = [NSString stringWithFormat:@"%d",indexPath.row];
// Configure the cell...
UIView * redView = [[UIView alloc] initWithFrame:CGRectMake(0, -10, 100, 20)];
redView.backgroundColor = [UIColor redColor];
[cell addSubview:redView];
return cell;
}
The table view is set on Grouped. Lets run it on iOS 6:
Duh ofcourse, the Y origin is negative! Yes, it is, and this is the result I am trying to achieve. Lets see what it shows on iOS 7:
Hint: that doesn't occur if we add redView to a normal UIView.
Another hint: if i set tableView's background color blue, the gray lines between sections would be blue, not gray (as a demonstration that the gray is not a set header). Another hint: same goes for ipad.
Why in iOS 7 it cuts everything that goes out of bounds? Please help!
It's because iOS 7 introduced some changes to the view hierarchy of UITableViewCells.
It used to be UITableViewCell view -> contentView
.
Now it's more like UITableViewCell view -> scrollView -> contentView
.
The solution is to set clipsToBounds = NO
on the scrollView (which is set to YES by default). And the way to achieve that is through the superview
property.
So basically in iOS6 and prior, to allow content to spill out of the cell bounds, you would do:
self.clipsToBounds = NO; //cell's view
self.contentView.clipsToBounds = NO; //contentView
In iOS7 you have to also prevent the scrollview from not clipping so you'd do something like:
self.clipsToBounds = NO; //cell's view
self.contentView.clipsToBounds = NO; //contentView
self.contentView.superview.clipsToBounds = NO; //scrollView
And the backwards compatible solution I use is:
self.clipsToBounds = NO;
self.contentView.clipsToBounds = NO;
if ([self.contentView.superview isKindOfClass:[NSClassFromString(@"UITableViewCellScrollView") class]]) self.contentView.superview.clipsToBounds = NO;
Keep in mind this is Hacky™ and if the view hierarchy changes again in iOS 8, you might be in trouble. Unfortunately it seems Apple doesn't want us to spill content out of UITableViewCells so AFAIK this is the only workable solution.
The following will fix it:
cell.layer.masksToBounds = NO
However, it will probably break something else, e.g. cell animations.
The problem you are having is caused by the fact that cells just don't support drawing content out of their bounds (actually, using subviews that extend the bounds of their superview is always a hacky solution).
The best advice is to redesign and avoid such funcionality at all.
Another solution could be to add the same view to the bottom of the previous cell or just add them as a subview of UITableView
directly.
I don't think that the contents are actually trimmed in a masksToBounds
-sense, but instead that the views are covered by the other (opaque) cells. You could try to fix it by changing the order ("z-Index") of the UITableView
's subviews, using bringSubviewToFront:
and similar methods whenever a cell appears to ensure that the cell closest to the bottom edge of the screen is the frontmost view of all the cells.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With