Solution de travail à partir d'iOS 9

Dans votre sous-class UITableViewHeaderFooterView, placez le code suivant.

 - (void)setFrame:(CGRect)frame { if (frame.size.width == 0) { return; } [super setFrame:frame]; } 

Explication:

La vue de table gère la disposition des vues d'en-tête et elle le fait en manipulant manuellement les frameworks (oui même avec l'autolayout activé).

Si vous inspectez les contraintes de largeur qui figurent sur les vues en-tête / pied de page, il y en a deux, l'une contenue dans la vue supérieure (la vue tabulaire) et l'autre dans la vue en-tête / pied de page.

La contrainte contenue dans la super vue est un NSAutoresizingMaskLayoutConstraint qui est le cadeau que la tableview dépend des frameworks pour manipuler les en-têtes. Passer le translatesAutoresizingMaskIntoConstraints à NO sur la vue d'en-tête brise son apparence, ce qui est un autre don.

Il semble que dans certaines circonstances ces vues d'en-tête / bas de page auront leurs frameworks changer à une largeur de zéro, pour moi c'était quand des rangées ont été insérées et les vues d'en-tête ont été réutilisées. Je suppose que quelque part dans le code UITableView une préparation pour une animation est faite en commençant le cadre à la largeur zéro, même si vous n'utilisez pas une animation.

Cette solution devrait fonctionner correctement et ne devrait pas avoir d'impact sur les performances du défilement.

J'ai couru à ça la semaine dernière.

La façon dont j'ai éliminé les avertissements est de changer mes contraintes requirejses pour avoir une priorité de 999 . C'est un travail plutôt qu'un correctif, mais il contourne les exceptions qui sont lancées, interceptées et enregistrées pendant la layout.

Les choses qui n'ont pas fonctionné pour moi.

Une suggestion consiste à définir estimatedRowHeight . J'ai essayé de définir le estimatedSectionHeaderHeight , mais cela n'a pas aidé. Définir un estimatedSectionFooterHeight créé des pieds de page vides là où je ne les voulais pas, ce qui était un peu étrange.

J'ai également essayé de placer translatesAutoresizingMaskIntoConstraints = NO; sur la vue de pied d'en-tête et sur sa vue de contenu. Ni l'un ni l'autre ne s'est débarrassé de l'avertissement et l'un d'entre eux a complètement détruit la disposition.

J'ai eu un problème similaire avec juste une label supplémentaire dans contentView. Essayez d'insert

 static void MBTableDetailStyleFooterViewCommonSetup(MBTableDetailStyleFooterView *_self) { _self.contentView.translatesAutoresizingMaskIntoConstraints = NO [...] } 

à la première ligne de votre fonction MBTableDetailStyleFooterViewCommonSetup . Pour moi, cela fonctionne en conjonction avec reloadSections:withRowAnimations:

Mettre à jour:

J'ai également ajouté une nouvelle contrainte pour que contentView utilise toute la largeur:

 NSArray *horizontalConstraints = [NSLayoutConstraint constraintsWithVisualFormat:@"H:|[contentView]|" options:0 mesortingcs:nil views:@{@"contentView" : _self.contentView}]; [_self.contentView.superview addConstraints:horizontalConstraints]; 

Je ne vois pas où vous appelez translatesAutoresizingMaskIntoConstraints = NO sur le pied de page lui-même. Devriez-vous le faire lorsque vous le créez?

 - (id)initWithReuseIdentifier:(NSSsortingng *)reuseIdentifier { self = [super initWithReuseIdentifier:reuseIdentifier]; self.translatesAutoresizingMaskIntoConstraints = NO; MBTableDetailStyleFooterViewCommonSetup(self); return self; } 

J'ai eu un problème similaire, un seul UILabel dans contentView, et j'ai utilisé maçonnerie:

 _titleLabel = ({ UILabel *label = [MLBUIFactory labelWithType:MALabelTypeB]; [self.contentView addSubview:label]; [label mas_makeConstraints:^(MASConstraintMaker */make) { make.centerY.equalTo(self.contentView); make.left.equalTo(self.contentView).offset(8); make.right.equalTo(self.contentView).offset(-8); }]; label; }); 

alors j'ai eu l'avertissement:

 ( "<MASLayoutConstraint:0x1742b2c60 UILabel:0x124557ee0.left == _UITableViewHeaderFooterContentView:0x12454c640.left + 8>", "<MASLayoutConstraint:0x1742b3080 UILabel:0x124557ee0.right == _UITableViewHeaderFooterContentView:0x12454c640.right - 8>", "<NSLayoutConstraint:0x174280780 _UITableViewHeaderFooterContentView:0x12454c640.width == 0>" ) Will attempt to recover by breaking constraint <MASLayoutConstraint:0x1742b3080 UILabel:0x124557ee0.right == _UITableViewHeaderFooterContentView:0x12454c640.right - 8> 

donc j'ai essayé de mettre self.translatesAutoresizingMaskIntoConstraints = NO; , mais cela n'a pas fonctionné pour moi, donc je me suis concentré sur le message d'avertissement, et je suis confus, pourquoi la contrainte de gauche fonctionne mais juste, quand j'ai vu _UITableViewHeaderFooterContentView:0x12454c640.width == 0 , j'ai compris, peut-être c'est pourquoi la bonne contrainte est la contrainte de rupture, alors j'ai changé de code:

 _titleLabel = ({ UILabel *label = [MLBUIFactory labelWithType:MALabelTypeB]; [self.contentView addSubview:label]; [label mas_makeConstraints:^(MASConstraintMaker */make) { make.centerY.equalTo(self.contentView); make.left.equalTo(self.contentView).offset(8); make.width.equalTo(@(SCREEN_WIDTH - 16)); }]; label; }); 

J'ai remplacé la contrainte de droite par une contrainte de largeur, et l'avertissement a disparu.

Il y a un autre moyen de laisser partir l'avertissement: self.contentView.translatesAutoresizingMaskIntoConstraints = NO; , MAIS le cadre de l'label est faux.

De manière gênante, il semble que UITableViewHeaderFooterView n'aime pas les contraintes constantes, par exemple

| -10- [voir] -10- |

Je suppose que, à la création, la vue a une largeur nulle et ne peut pas satisfaire la contrainte, ce qui nécessiterait au less une largeur de 20 pixels dans ce cas.

Pour moi, le moyen de contourner cela était de changer mes contraintes constantes en quelque chose comme

| – (<= 10) – [voir] – (<= 10) – |

Ce qui devrait satisfaire un contenu de largeur nulle et devrait donner la marge désirée lors du redimensionnement.

Besoin de mettre à jour le contentView frame , et les avertissements ont disparu. Cela peut être similaire au problème de contraintes de disposition automatique sur iOS7 dans UITableViewCell

 public class MyHeaderview: UITableViewHeaderFooterView { // Add views to contentView public override func layoutSubviews() { super.layoutSubviews() contentView.frame = bounds } } 

Dans iOS 11, je n'ai pas UITableViewHeaderFooterView à afficher UITableViewHeaderFooterView correctement.

Le problème était que je UITableViewHeaderFooterView mes contraintes quand le UITableViewHeaderFooterView pensait que ses limites étaient vides, donc cela causerait toujours des conflits.

Voici la solution

 override func layoutSubviews() { super.layoutSubviews() guard bounds != CGRect.zero else { return } makeConstraints() }