Почему UITableViewController не должен управлять частью окна в Cocoa Touch?

Question

У меня есть представление, содержащее UITableView и UILabel, которое, насколько я могу судить, работает идеально. Я действительно не хочу управлять UIView и UITableView с тем же контроллером, что и UITableViewController, выполняющим большую домашнюю работу и согласно документации :

Если управляемое представление является составной вид, в котором вид таблицы является одним из нескольких подпредставлений, вы должны использовать пользовательский подкласс UIViewController для управления таблицей вид (и другие виды). Не используйте UITableViewController объект, потому что этот класс контроллера определяет размеры таблицы вид, чтобы заполнить экран между панель навигации и панель вкладок (если либо присутствуют).

Почему Apple предупреждает против его использования и что произойдет, если я проигнорирую это предупреждение?

Обновление : Первоначально я цитировал следующее из Документации Apple :

Вы не должны использовать вид контроллеры для управления представлениями, которые заполняют только часть их окна, то есть только часть области, определяемой прямоугольник содержимого приложения. если ты хочу иметь интерфейс, состоящий из несколько меньших просмотров, вставьте их все в едином корневом представлении и управлять этим просматривать с помощью контроллера просмотра.

Хотя эта проблема, вероятно, связана с тем, почему UITableViewController была разработана для полноэкранного режима, это не совсем та же проблема.

Answer 1

Основная практическая причина использования только одного контроллера представления на экран заключается в том, что это единственный способ управлять навигацией.

Например, предположим, что у вас есть экран с двумя отдельными контроллерами представления, и вы загружаете его с помощью контроллера навигации. На какой из двух контроллеров представления вы нажимаете и как загружаете и ссылаетесь на второй? (Не говоря уже о необходимости одновременной координации двух отдельных контроллеров.)

Я не думаю, что использование одного настраиваемого контроллера является большой проблемой, как вы думаете.

Помните, нет необходимости, чтобы TableviewDataSource и TableViewDelegate были в реальном контроллере. Шаблоны Apple просто делают это для удобства. Вы можете поместить методы, реализующие оба протокола, в один класс или разделить их каждый в свой собственный класс. Затем вы просто связываете их с таблицей в своем пользовательском контроллере. Таким образом, все, что нужно сделать пользовательскому контроллеру - это управлять фреймом самого tableview. Вся конфигурация и управление данными будут в отдельных и автономных объектах. Пользовательский элемент управления может легко отправлять им сообщения, если вам нужны данные из других элементов пользовательского интерфейса.

Этот тип гибкости, настройки и инкапсуляции - вот почему шаблон проектирования делегата используется в первую очередь. Вы можете настроить черт из чего угодно, не создавая один класс монстров, который делает все. Вместо этого вы просто вставляете делегатский модуль и уходите.

Edit01: Ответ на комментарий

Если я правильно понимаю ваш макет, ваша проблема в том, что UITableViewController жестко настроен для установки таблицы для заполнения доступного представления. В большинстве случаев табличное представление является самим видом сверху, и это работает. Основная функция UITableViewController состоит в том, чтобы расположить таблицу, поэтому, если вы используете нестандартный макет, он вам не нужен. Вы можете просто использовать универсальный контроллер представления и позволить перо установить рамку таблицы (или сделать это программно). Как я уже сказал, легко представить, что методы делегата и источника данных должны быть в контроллере, но это не так. Вам просто нужно избавиться от tableViewController, потому что он бесполезен в вашем конкретном проекте.

Answer 2

Для меня важной деталью в документации Apple является то, что они советуют вам не использовать " контроллеры представлений [т.е. экземпляры UIViewController или его подклассов] для управления представлениями, которые заполняют только часть их окна ». Нет ничего плохого в использовании нескольких (пользовательских) контроллеров для не полноэкранных представлений, они просто не должны быть объектами UIViewController.

UIViewController ожидает, что его представление занимает весь экран, и если это не так, вы можете получить странные результаты. Контроллер представления изменяет размер представления, чтобы соответствовать окну (за исключением панелей навигации и панелей инструментов), когда он появляется, он управляет ориентацией устройства (что трудно применить правильно, если его представление не занимает весь экран) и т. Д. Так, учитывая, как работает UIViewController Я думаю, что есть смысл в советах Apple.

Однако это не значит, что вы не можете написать свои собственные классы контроллеров для управления вашими подпредставлениями. Помимо вещей, которые я упомянул выше, взаимодействия с панелью вкладок и контроллерами навигации и получения предупреждений о памяти, UIViewController не так уж много делает. Вы можете просто написать свой собственный класс контроллера (подкласс из NSObject), создать его экземпляр в вашем «обычном» полноэкранном контроллере представления и позволить ему обрабатывать взаимодействие с вашим представлением.

Единственная проблема, которую я вижу, - цепочка респондента. Контроллер представления является частью цепочки респондента, поэтому сенсорные события, которые не обрабатываются вашими представлениями, передаются в контроллер представления. На мой взгляд, не существует простого способа поместить ваш пользовательский контроллер в цепочку респондента. Я не знаю, относится ли это к вам. Если вы сможете управлять взаимодействием со своим представлением с помощью механизма целевого действия, это не имеет значения.

Answer 3

У меня есть приложение, в котором я использовал 2 отдельных подкласса UIViewController ниже другого контроллера представления для управления представлением таблицы и панелью инструментов. Это «отчасти» работает, но в результате я попал в массовое рассол и теперь понимаю, что не должен использовать подклассы UIViewController для субконтроллеров, потому что они содержат поведение, которое мне не нужно и которое мешает.

Что-то пошло не так, как правило:

• Странное изменение размеров видов при возврате из вспомогательной навигации и геометрических расчетов, различающихся между viewWillLoad и viewDidLoad и т. Д.

• Сложность в обработке предупреждений о нехватке памяти, когда я освобождаю контроллеры подпредставления, когда я не должен был это делать.

Предполагается, что подклассы UIViewController не будут использоваться подобным образом, и то, как они обрабатывают события, используя контроллер навигации и т. Д., Что сделало попытку использовать более одного подкласса UIViewController для одной и той же страницы непросто, поскольку в итоге вы тратите больше время обойти их поведение в этом контексте.

Answer 4

На мой взгляд, Apple Way предлагает вам «одно» решение. Это очень хорошо послужило конечным пользователям. Нет выбора, нет головной боли.

Мы программисты, и мы хотим и должны настраивать их. Однако в некоторых случаях Apple все еще не хочет, чтобы мы делали слишком много изменений. Например, высота панели вкладок, панели инструментов и панели навигации, некоторые размеры компонентов пользовательского интерфейса по умолчанию (представление таблицы), некоторые поведения по умолчанию и т. Д. А при разработке каркаса и набора API-интерфейсов их необходимо закрепить некоторые решения. Даже если это очень хороший и гибкий дизайн, в мире всегда найдется один программист, который хочет сделать что-то другое, и ему трудно достичь такого дизайна.

Короче говоря, вам нужны табличное представление и метка на одном экране, но они так не думают. :)