Ну, я бы действительно сказал, что лучше всего было бы наследовать ваши UITabBarController
s от MasterController
.
Внутри этой MasterController
viewDidLoad
или viewWillLoad
вы можете написать общий макети настройки, которые позже будут использоваться вашими подклассами.
Это также намного удобнее, потому что вы можете в своих MasterController
реализовать методы для соответствующего обновления ваших представлений.
Это также может бытьПриятно иметь один базовый NIB-файл, загруженный через этот MasterController
, и для которого пользовательский макет может быть выполнен в дочерних контроллерах (например, в методе initWithNibName:bundle:
.
Я думаю, создание подкласса UITableView
не очень хорошая идея, потому что вы не настраиваете поведение табличного представления как таковое, но настраиваете контроллер, который его использует вместо этого.
Надеюсь, это поможет.
EDIT : Способ NIBЕсли вы решили использовать файл NIB, вы все равно можете использовать один MasterController, выполнив следующие действия:
- В вашем MasterController создайте необходимые выходы (здесь я думаю, что вам нужен только TableView, но это может бытьболее сложный)
- В InterfaceBuilder настройте свои соединения, как обычно
- В своем коде при создании
UITabViewController
s вы будете использовать [[YourTabBarController alloc]
initWithNibName:@"YourMasterNIBFile.xib" bundle:nil]
Поскольку выходы будут наследоваться, ваш класс YourTabBarController
, который будет наследовать YourTabBarController
, будет иметь всю необходимую информацию для правильного построения вашего представления.
Надеюсь, это достаточно ясно, я использовалэтот метод для одного из моих приложений и время, потраченное на создание этого MasterController
, определенно стоило боли за всю гибкость, которую он обеспечивает.