Aqui está outra solução que é um pouco diferente.
Eu tive que usá-lo devido a alguns problemas de hierarquia de exibição que eu tinha: eu estava criando algumas funcionalidades que exigiam a passagem de visualizações para lugares diferentes na hierarquia de exibições, que eram quebradas ao usar a visualização de tabela de um UITableViewController porque a tableView é a visualização raiz do UITableViewController ( self.view) e não apenas uma visão regular, ele criou hierarquias inconsistentes de controlador / visão e causou uma falha.
Crie basicamente sua própria subclasse de UITableViewController e substitua o loadView para atribuir self.view a uma exibição diferente e substitua a propriedade tableView para retornar uma visualização de tabela separada.
por exemplo:
@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
Quando combinado com a solução da Keller, isso será mais robusto no sentido de que o tableView agora é uma visualização regular, não uma visualização raiz do VC, e será mais robusto contra alterações nas hierarquias de visualização. Exemplo de uso desta maneira:
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;
Há outro uso possível para isso:
Como a subclassificação dessa maneira separa self.view de self.tableView, agora é possível usar esse UITableViewController como um controlador comum e adicionar outras subviews ao self.view sem as peculiaridades de adicionar subviews ao UITableView, portanto, pode-se considerar fazer suas visualize controladores diretamente uma subclasse de UITableViewController em vez de ter filhos UITableViewController.
Algumas coisas a observar:
Como estamos substituindo a propriedade tableView sem chamar super, pode haver algumas coisas a serem observadas e que devem ser tratadas sempre que necessário. Por exemplo, configurar a tableview no exemplo acima não adicionará a tableview a self.view e não definirá o quadro que você deseja fazer. Além disso, nesta implementação, não é fornecido tableView padrão quando a classe é instanciada, o que também é algo que você pode considerar adicionar. Não o incluo aqui porque é caso a caso, e essa solução realmente se encaixa bem na solução de Keller.