これは少し異なる別のソリューションです。
私はいくつかのビュー階層の問題のためにそれを使用する必要がありました:ビュー階層のさまざまな場所にビューを渡す必要があるいくつかの機能を作成していましたが、UITableViewControllerのテーブルビューを使用すると壊れてしまいました。 self.view)は、通常のビューだけでなく、一貫性のないコントローラー/ビュー階層を作成し、クラッシュを引き起こしました。
基本的に、UITableViewControllerの独自のサブクラスを作成し、loadViewをオーバーライドしてself.viewに別のビューを割り当て、tableViewプロパティをオーバーライドして別のテーブルビューを返します。
例えば:
@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
ケラーのソリューションと組み合わせると、tableViewがVCのルートビューではなく通常のビューになり、ビュー階層の変更に対してより堅牢になるという意味で、これはより堅牢になります。このように使用する例:
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;
これには別の使用方法があります:
この方法でサブクラス化すると、self.viewがself.tableViewから分離されるため、このUITableViewControllerを通常のコントローラーのように使用し、他のサブビューをself.viewに追加することができます。ビューコントローラーは、UITableViewControllerの子を持つ代わりに、UITableViewControllerのサブクラスを直接使用します。
注意すべきいくつかのこと:
superを呼び出さずにtableViewプロパティをオーバーライドしているため、注意が必要な場合があり、必要に応じて処理する必要があります。たとえば、上記の例でテーブルビューを設定しても、テーブルビューがself.viewに追加されず、必要なフレームが設定されません。また、この実装では、クラスがインスタンス化されるときにデフォルトのtableViewは提供されません。これは、追加することも検討できます。それはケースバイケースであり、このソリューションは実際にはケラーのソリューションとうまく適合しているため、ここには含めません。