Скользящие меню: как справиться с изменением контроллеров представления

Похоже, что в наши дни 50% всех приложений для iPhone используют скользящие меню в стиле Facebook. Я также создал несколько приложений с этим пользовательским интерфейсом, используя библиотеку ViewDeck (https://github.com/Inferis/ViewDeck). Левое представление — это UITableView, щелчок по элементу изменяет центральное представление.

Однако я боролся с хорошим «управлением меню». Вы создаете NSArray со всеми контроллерами представления? Лучше лениво загружать по одному? Как вы относитесь к памяти? Не совсем уверен, как лучше всего сохранить использование памяти как можно меньше.

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


ios cocoa-touch objective-c viewdeck
person Kevin Renskers    schedule 08.01.2013    source источник
comment
Для общей реализации я бы выбрал ответ @Mert. Некоторые примеры, когда вам нужны конкретные реализации: если у вас действительно много этих ViewController, вы можете время от времени выпускать их (устанавливайте предельное число или освобождайте их все при предупреждении памяти, как было предложено). Также, если есть одна основная ВК и пользователь переключается не очень часто, вы можете загружать их по требованию и освобождать потом при переключении на другую. Возможно, вы также можете повторно использовать VC того же класса и просто перенастроить их при переключении, что уменьшит количество.   -  person Julien    schedule 08.01.2013

Ответы (3)


arrow_upward
3
arrow_downward

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

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

person Mert    schedule 08.01.2013
comment
Но вы выделяете и инициализируете все контроллеры представления с самого начала, верно? Разве это не требует больших затрат? И как только вы поместите контроллер представления в массив, как вы вообще сможете его освободить? - person Kevin Renskers; 08.01.2013
comment
Это зависит от того, что у вас есть в init mehtod. У меня в основном ничего нет, и я выполняю UI-задачи в viewDidLoad. Он будет вызываться до того, как представление появится, а не во время инициализации контроллера представления, если только вы не вызовете представление контроллера представления где-то еще (viewcontroller.view). Вы можете установить точку останова и проверить себя. Как я уже сказал, мне никогда не нужно было выпускать контроллер представления, если он вам нужен, просто удалите его из этого массива. Если вы используете ARC и нет ссылок на этот массив, он будет выпущен iOS. Когда вам это нужно, создайте новый. Конечно, вам нужно довести представление до последнего состояния. - person Mert; 08.01.2013
comment
Может быть, это также полезно. Я удаляю просмотры (removeFromSuperView), которые не нужны. Таким образом, iOS не пытается обновить пользовательский интерфейс. Затем добавьте снова, когда мне нужно. - person Mert; 08.01.2013
comment
Спасибо за ваши Коментарии. У меня редко что-то есть в методах инициализации, так что это должно быть безопасно. В основном это то, чем я занимался до сих пор, приятно знать, что я не делал безумных вещей :) - person Kevin Renskers; 08.01.2013

arrow_upward
1
arrow_downward

Прежде всего, обратите внимание, что я никогда не использовал приложение Facebook или ViewDeck, по демонстрационному видео понятно, для чего используется библиотека.

Я могу предложить вам искать разные шаблоны, например. есть книга Pro Objective-C Design Patterns for iOS, в ней описывается довольно простой шаблон посредника, который по сути является контроллером контроллеров.

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

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

person A-Live    schedule 08.01.2013

arrow_upward
0
arrow_downward

Что я сделал, так это создал контроллер представления контейнера с боковым меню в нижней части представления, что означает, что он не виден. Вдобавок ко всему, у меня есть contentView (который является просто UIView), у меня есть UINavigationController, который управляет UIViewControllers, со скрытой панелью навигации. Затем я передаю ссылку на этот UINavigationController в боковое меню, которое является просто подклассом UIView с UITableView, и именно здесь загружаются UIViewControllers. Когда пользователь выбирает строку, я выделяю/инициирую контроллер представления. Поэтому, когда новый UIViewController помещается в стек, он помещается в UINavigationController в представлении содержимого.

person Chandler De Angelis    schedule 06.06.2013