UITableViewCell AccessoryView 显示不正确

Question

I have a UITableviewCell with a UISwitch in the accessoryView and it is displayed properly at runtime, but as soon as I rotate the device, the switch isn't anymore at the right place.

I could use constraints and not use the accessoryView, but I thought I could use this field.. Does anyone have an idea ?

Thanks !

EDIT : here is the configuration in Interface Builder :

EDIT 2 : I used a Custom cell :

with initialization on the default properties :

self.textLabel.font = [UIFont preferredDynamicFontForTextStyle:UIFontTextStyleBody fontSize:16.0];
self.backgroundColor = self.contentView.backgroundColor;

self.textLabel.text = item.title;
self.selectedImage = item.imageSelected;
self.unselectedImage = item.image;
self.imageView.image = self.unselectedImage;
// if I do it programmatically
self.accessoryView = [[UISwitch alloc] init];

I don't set constraints at all, because I use the default properties..

Answer 1

I'm just having the same issue as you.

Here are my observations:

• If you set the accessoryView by code, it's always OK, whether the cell is selected or not, on both iOS 7 and iOS 8.
• If you set the accessoryView by IB, the accessoryView moves to the top left corner after the first selection of the cell, and only on iOS 8 .

I don't know if the issue is from IB or the way cells layout the accessory view on iOS 8 but so far the workaround is simple: always set the accessoryView by code to avoid unexpected behavior.

Answer 2

I can say with some certainty that your constraints are not properly set up. But without seeing the storyboard's constraints, there's no way to say what is broken for sure.

Answer 3

如果您正在使用autolayout（可能），则应首先设置约束 。

Answer 4

Looks like if you create the accessoryView and the editingAccessoryView in code and set it, everything works great!

If you try to set them in the UIStoryBoard , the UITableViewCell will remove the constraints after they fade away the first time, and it won't add them back. It's a shame, but hopefully they change it in a later version.

Hope that Helps!

Answer 5

For anyone finding this issue currently, I think I have an explanation of what might be happening here:

This is an issue with the translatesAutoresizingMaskIntoConstraints property on the view. From Apple's documentation, particularly relevant bits in bold:

If this property's value is YES, the system creates a set of constraints that duplicate the behavior specified by the view's autoresizing mask. This also lets you modify the view's size and location using the view's frame, bounds, or center properties, allowing you to create a static, frame-based layout within Auto Layout. Note that the autoresizing mask constraints fully specify the view's size and position; therefore, you cannot add additional constraints to modify this size or position without introducing conflicts. If you want to use Auto Layout to dynamically calculate the size and position of your view, you must set this property to NO, and then provide a non ambiguous, nonconflicting set of constraints for the view. By default, the property is set to YES for any view you programmatically create. If you add views in Interface Builder, the system automatically sets this property to NO .

So, when I came across this issue it was when I was changing the tableview from the contents being a stack view with label and switch into being a label with a UISwitch as the accessory view. The switch was being programmatically created earlier on view load for the container view the table was sitting in and the translatesAutoresizingMaskIntoConstraints was being set to NO - essentially the same situation that happens when you create the switch in interface builder. The code I was changing then tried to set up constraints but the switch would always bug out and be floating over to the wrong side when you rotated the screen. The solution for me was changing the translatesAutoresizingMaskIntoConstraints property to YES and letting the constraints be created by the view itself. It looks to me like this is a conflicting issue between what this property does on most views and what the accessory view itself tries to handle and if a programmer tries to go in and set things up themselves there seems to not be a good indication of what has gone wrong here. Hope this helps someone in the future!