Voici une autre solution qui est un peu différente.
J'ai dû l'utiliser à cause de certains problèmes de hiérarchie de vues que j'avais: je créais des fonctionnalités qui nécessitaient de passer des vues à différents endroits de la hiérarchie de vues, qui se cassaient lors de l'utilisation d'une tableview UITableViewController b / c la tableView est la vue racine de UITableViewController ( self.view) et pas seulement une vue régulière, elle a créé des hiérarchies contrôleur / vue incohérentes et a provoqué un plantage.
Fondamentalement, créez votre propre sous-classe de UITableViewController et redéfinissez loadView pour affecter self.view une autre vue, et redéfinissez la propriété tableView pour renvoyer une autre table.
par exemple:
@interface MyTableVC : UITableViewController
@end
@interface MyTableVC ()
@property (nonatomic, strong) UITableView *separateTableView;
@end
@implementation MyTableVC
- (void)loadView {
self.view = [[UIView alloc] initWithFrame:CGRectZero];
}
- (UITableView *)tableView {
return self.separateTableView;
}
- (void)setTableView:(UITableView *)tableView {
self.separateTableView = tableView;
}
@end
Lorsqu'il est combiné avec la solution de Keller, cela sera plus robuste dans le sens où la tableView est maintenant une vue régulière, et non une vue racine de VC, et sera plus robuste contre les hiérarchies de vue changeantes. Exemple d'utilisation de cette façon:
MyTableVC *tableViewController = [[MyTableVC alloc] init];
tableViewController.tableView = self.myTableView;
self.refreshControl = [[UIRefreshControl alloc] init];
[self.refreshControl addTarget:self action:@selector(getConnections) forControlEvents:UIControlEventValueChanged];
tableViewController.refreshControl = self.refreshControl;
Il existe une autre utilisation possible pour cela:
Étant donné que le sous-classement de cette façon sépare self.view de self.tableView, il est maintenant possible d'utiliser ce UITableViewController comme un contrôleur plus régulier et d'ajouter d'autres sous-vues à self.view sans les bizarreries d'ajouter des sous-vues à UITableView, donc on peut envisager de faire leur afficher les contrôleurs directement une sous-classe de UITableViewController au lieu d'avoir des enfants UITableViewController.
Quelques points à surveiller:
Étant donné que nous remplaçons la propriété tableView sans appeler super, il peut y avoir des choses à surveiller et à gérer si nécessaire. Par exemple, définir la table dans mon exemple ci-dessus n'ajoutera pas la table à self.view et ne définira pas le cadre que vous voudrez peut-être faire. De plus, dans cette implémentation, aucune tableView par défaut ne vous est donnée lorsque la classe est instanciée, ce que vous pouvez également envisager d'ajouter. Je ne l'inclus pas ici car c'est au cas par cas, et cette solution correspond en fait bien à la solution de Keller.