Просмотреть архитектуру контроллера / NIB для не навигационного приложения с переходами?

Question

Я работаю с приложением для iPad, которое (как и многие приложения для iPad) не использует систему управления корневыми представлениями UINavigation, поэтому у меня нет естественного права собственности на каждое представление приложения. По сути, у меня есть два основных представления: представление списка документов и представление редактирования документа.

Я играю с анимацией UIView для перехода от выбранного документа к представлению редактирования.

У меня также есть панель инструментов сверху, которая существует (с разными кнопками) в обоих «видах».

Поскольку у меня нет UINavigation, которое запускает шоу для меня, я склонен просто добавлять все больше и больше материала в один NIB и один контроллер представления, который владеет всем контейнером. Но теперь я пытаюсь понять, как перейти от представления списка документов к представлению редактирования, если представление редактирования находится в другом NIB, сохраняя при этом панель инструментов.

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

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

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

Спасибо!

ОБНОВЛЕНИЕ : Я не говорю о разделенном представлении, которое явно хорошо обрабатывается контроллером разделенного представления. Вместо этого взгляните на приложения Apple iWork (например, Pages), которые имеют представление списка документов и независимое представление редактирования, но они связаны анимацией.

Может быть, реальный вопрос здесь заключается в следующем: как бы вы (или могли бы вы вообще?) Самостоятельно построить контроллер представления «контейнер», такой как разделенное представление или контроллер навигации? Вы должны построить всю эту чертову вещь с нуля? Я чувствую, что вы, потому что, кажется, скрытая проводка во взаимодействии между контроллерами представления. Если так, мысли по этому поводу?

Answer 1

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

Контроллеры представления спроектированы так, чтобы быть вложенными, причем каждый контроллер имеет частьиерархия представления.Единственная цель разработки состоит в том, чтобы ни один контроллер представления не достиг иерархии представлений другого контроллера.У родительского контроллера представления обычно есть некоторый вызов для добавления дочерних контроллеров, чтобы он мог установить фрейм представления в пределах иерархии представления, которой он владеет.Контроллер дочернего представления не должен ничего делать с суперпредставлением представления, которым он управляет, поскольку оно принадлежит другому контроллеру.Не следует устанавливать центр или фрейм вида, которым он управляет.

Например, у контроллера навигации есть метод push, при котором он удаляет предыдущий вид контроллера, добавляет новый вид контроллера и устанавливает кадрнедавно добавленного представления.В общем, родительский контроллер представления может устанавливать рамку представления дочернего контроллера, но не границы.

Если вы хотите изменить анимацию контроллера навигации, я думаю, вы бы начали среализация каждого метода с аргументом animated :.Настройте анимацию, затем вызовите super с отключенным анимированным флагом, прежде чем начинать анимацию.

Answer 2

Я не пробовал использовать несколько контроллеров представления за пределами предоставленных UIKit (навигация / tab-bar / modal / и т. Д.), Но я не понимаю, почему это не должно работать. Под капотом все является представлением, хотя я отмечу, что UIKit имеет специальные представления для контроллеров представлений, которые, без сомнения, имеют какую-то особую обработку системой (UIViewController имеет представление-обертку, UINavigationController имеет UINavigationTransitionView или что-то в этом роде, .. .).

Я бы посоветовал не слишком беспокоиться о «наилучшей практике» - просто кодируйте то, что делает то, что вы хотите. Пара вариантов:

• Вставьте логику в классы представления (ewwww!). Это делает одно из наших приложений, поэтому оно может обрабатывать вращение по своему усмотрению (представления вращаются, а не вращаются). Возможно, нам следовало бы реализовать собственную логику контроллера представления.
• Разбейте модель на компоненты, которые соответствуют представлениям. Заставьте каждое представление знать, как загрузить свой компонент и рекурсивно загрузить подкомпоненты. Тогда контроллеру представления нужно только беспокоиться о вещах "большой картинки".

Также обратите внимание, что вы можете загрузить несколько перьев в один контроллер вида, например, подключив его к выходу с именем editView. Большая разница в том, что это не делается автоматически с помощью [UIViewController loadView], поэтому вам нужно сделать что-то вроде

-(EditView*)editView {
  if (!editView) {
    // Loads EditView into the outlet editView
    [NSBundle loadNibNamed:@"EditView" owner:self];
  }
  return editView;
}

Вам также нужно будет позаботиться о том, чтобы добавить его в иерархию представлений, выгрузить его в - (void) viewDidUnload (iPhone OS 3.0+), настроить его в - (void) viewDidLoad на случай, если во время предупреждения о наличии памяти режим редактирования и т.д ...

Это не легко, но пользовательский интерфейс никогда не бывает.

Answer 3

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

Главный вид - это список документов, а подробный вид - это вид редактирования. У каждого свой контроллер. Сами два контроллера управляются UISplitViewController.

Если вы не используете контроллер splitview, вы в конечном итоге просто закодируете что-то, что работает очень похоже на это. Это действительно единственный способ легко делать то, что вы хотите в API, и это тот макет, который ожидают пользователи iPad.

Подробнее см. Создание интерфейса Split View в руководстве по программированию iPad.