Скользящие меню: как справиться с фактически меняющимися контроллерами представления
Похоже, что в наши дни 50% всех приложений для iPhone используют скользящие меню, подобные Facebook. Я также создал несколько приложений с этим пользовательским интерфейсом, используя библиотеку ViewDeck (https://github.com/Inferis/ViewDeck). Левый вид - это UITableView, нажатие на элемент меняет центральное представление.
Я боролся с хорошим "управлением меню", хотя. Вы создаете NSArray со всеми контроллерами представления? Лучше ленивую загрузку по одному? Как вы справляетесь с памятью? Не совсем уверен, что лучший способ при минимальном использовании памяти.
Когда я смотрю на эти библиотеки скользящего меню, никогда не бывает полноценного примера приложения с рабочим меню и несколькими контроллерами. Как я уже сказал, я создал пару приложений, использующих ViewDeck, но фактическое изменение контроллеров представления всегда кажется неуклюжим и совсем не оптимальным (массив со всеми созданными экземплярами контроллеров представления).
3 ответа
Я использую массив для контроллеров представления не для представлений. Представления загружаются, когда пользователь выбирает ячейку, на которую указывает данный контроллер представления. Так что это ленивая загрузка. Если вы думаете, что вам нужно быть осторожным с памятью, то по предупреждению памяти вы можете освободить контроллеры представления, которые вам пока не нужны.
Конечно, это зависит от того, что у вас есть в этих контроллерах, но обычно (стандартный пользовательский интерфейс) вам не нужно их выпускать. Я никогда не нуждался.
Прежде всего, обратите внимание, что я никогда не использовал приложение Facebook или ViewDeck, основываясь на демонстрационном видео, ясно, для чего используется библиотека.
Я могу порекомендовать вам искать разные модели, например, есть книга Pro Objective-C Design Patterns for iOSОн описывает довольно простой шаблон посредника, который в основном является контроллером контроллеров.
Управление памятью полностью зависит от задачи, я не вижу никакой причины инициализировать все контроллеры представления одновременно, поскольку их представления могут быть загружены, но не отображены. Также представления не всегда являются наиболее ресурсоемкой частью контроллера. Такой подход потребует очень строгой и тщательной разработки контроллеров, вам также придется сделать их многократно используемыми, что не так просто.
Вместо этого я бы попытался сделать его максимально гибким и простым: массив используемых контроллеров представления, следующий загружается и добавляется туда по требованию. Это должно быть что-то очень похожее на UINavigationController стек контроллеров. UINavigationController Сам по себе хороший пример для исследования, у вас не будет исходного кода, но у вас будут все заголовки, и внутренняя логика не так сложна.
Что я сделал, так это создал контроллер представления контейнера с меню боковой панели внизу представления, что означает, что он не виден. Кроме того, у меня есть contentView (который является просто UIView), у меня есть UINavigationController, который управляет UIViewControllers, с панелью навигации, установленной на скрытый. Затем я передаю ссылку на этот UINavigationController в меню боковой панели, которое является просто подклассом UIView с UITableView, и именно здесь загружаются UIViewControllers. Когда пользователь выбирает строку, я выделяю / инициализирую контроллер представления. Поэтому, когда новый UIViewController помещается в стек, он помещается в UINavigationController в представлении содержимого.