Although iOS7 has encouraged less chrome in our user interfaces, some of us still find background views on table cells relevant. A bug in iOS7 (present at the time this post was written) inadvertently covers up the stock Delete button on a table cell if you have a backgroundView set on the table cell.
Initially, you see the Delete button and then the backgroundView slides over to the right to completely cover it!
Many have reported this problem, such as this example from stackoverflow.com.
A Fix From cyphers72
On the Apple Developer Forum, user cyphers72 explained how he managed to solve the problem: during layoutSubviews the backgroundView frame origin x-coordinate needed to be reset to zero.
Why the backgroundView is moving relative to its parent view is a bit of a mystery, but this override beautifully solved the problem.
A More Robust Fix
I’ve expanded on the fix from cyphers72 to handle both the backgroundView and selectedBackgroundView properties.
Drop the following code into your custom UITableViewCell subclass in order to keep your table cells resilient against this bug.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
- (void)layoutSubviews { [super layoutSubviews]; [self applyEditingModeBackgroundViewPositionCorrections]; } /** When using a backgroundView or selectedBackgroundView on a custom UITableViewCell subclass, iOS7 currently has a bug where tapping the Delete access control reveals the Delete button, only to have the background cover it up again! Radar 14940393 has been filed for this. Until solved, use this method in your Table Cell's layoutSubviews to correct the behavior. This solution courtesy of cyphers72 on the Apple Developer Forum, who posted the working solution here: https://devforums.apple.com/message/873484#873484 */ - (void)applyEditingModeBackgroundViewPositionCorrections { if (!self.editing) { return; } // BAIL. This fix is not needed. // Assertion: we are in editing mode. // Do we have a regular background view? if (self.backgroundView) { // YES: So adjust the frame for that: CGRect backgroundViewFrame = self.backgroundView.frame; backgroundViewFrame.origin.x = 0; self.backgroundView.frame = backgroundViewFrame; } // Do we have a selected background view? if (self.selectedBackgroundView) { // YES: So adjust the frame for that: CGRect selectedBackgroundViewFrame = self.selectedBackgroundView.frame; selectedBackgroundViewFrame.origin.x = 0; self.selectedBackgroundView.frame = selectedBackgroundViewFrame; } } |
What we’re basically doing here, is resetting the x-origin of these background views to zero at table cell layout time, if they are in editing mode. Why they are translated incorrectly, and why they are above the Apple provided ‘Delete’ button view is presumably, part of the known issue (radar #14940393) that Apple is working to fix.