Voir le contrôleur / architecture NIB pour une application non-navigation avec des transitions?

Question

Je suis bricoler avec une application iPad qui (comme beaucoup d'applications iPad) ne pas utiliser le système de contrôle de la vue racine de UINavigation, donc je n'ai pas la propriété naturelle pour chaque application « vue ». J'ai essentiellement deux vues de base: une liste de documents vue, et une vue de modifier des documents

.

Je joue avec animation UIView pour obtenir à partir d'un document sélectionné à la vue de modifier.

J'ai aussi une barre d'outils sur le dessus qui existe (avec différents boutons) dans les deux « vues ».

Parce que je n'ai pas UINavigation le spectacle en cours d'exécution pour moi, je tendance à simplement jeter de plus en plus de choses dans un NIB et un contrôleur de vue qui est propriétaire du conteneur entier. Mais maintenant, je suis en train de comprendre comment dans la liste segue de documents en vue de la vue modifier si la vue de modifier vit dans une autre NIB, la préservation de la barre d'outils aussi.

Quelqu'un a des pensées ou des expériences sur les structures d'applications comme celle-ci? Je trouve que les documents manquent sur les meilleures pratiques autour de code / structure de l'interface utilisateur pour tout sauf des applications triviales d'un écran ou plein sur les applications de navigation.

Vous n'êtes pas « censé » avoir contrôleurs de vue parent / enfant possédant les sous-composants du même « écran », selon les documents, mais cela implique un contrôleur de vue klaxonnant massif qui contient essentiellement l'application entière, et qui ne peuvent pas raison.

Je ne sais pas s'il y a une « bonne réponse » à cela; Je cherche quelques exemples intelligents ou suggestions. Personne ne touche cette question dans les mois, donc j'ajouter une prime pour générer un bon bavardage. :)

Merci!

UPDATE : Je ne parle pas d'une vue partagée, qui est clairement bien gérée par un contrôleur de vue partagé. Au lieu de cela, jetez un oeil à des applications iWork d'Apple (par exemple Pages) qui ont une liste de documents vue et une vue de modifier indépendant, mais ceux-ci sont liés par l'animation.

Peut-être la vraie question ici est: comment voulez-vous (? Ou pourriez-vous même) construire un contrôleur de vue « conteneur » comme la vue partagé ou contrôleur de navigation, vous? Devez-vous de construire toute la fichue chose à partir de zéro? Je sens que vous êtes, parce que semble se cacher le câblage dans l'interaction entre les contrôleurs de vue. Si oui, pensées à ce sujet?

Answer 1

Je pense que le seul câblage caché dans les contrôleurs de vue est mise parentViewController, qui est nécessaire pour soutenir les catégories déclarées pour Split et navigation.

Voir les contrôleurs sont conçus pour être imbriqués, chaque contrôleur propriétaire d'une partie de la hiérarchie de la vue. Le seul objectif de conception est que pas de vue contrôleur atteindre dans la hiérarchie de la vue d'un autre contrôleur. Un contrôleur de vue parent aura généralement un appel pour ajouter des contrôleurs de l'enfant afin qu'il puisse fixer le cadre de la vue dans la hiérarchie de vue, il est propriétaire. Un contrôleur de vue de l'enfant ne doit pas faire quoi que ce soit à l'superview estime qu'il contrôle, comme qui appartient à un autre contrôleur. Non devrait-il définir le centre ou le cadre de la vue qu'il contrôle.

Par exemple, un contrôleur de navigation a une méthode de poussée, dans laquelle il supprime le point de vue du contrôleur précédent, ajoute la nouvelle vue du contrôleur, et définit le cadre de la vue nouvellement ajouté. En général, un contrôleur de vue parent est libre de fixer le cadre de la vue d'un contrôleur de l'enfant, mais pas les limites.

Si vous voulez changer l'animation d'un contrôleur de navigation, je pense que vous commencez par mettre en œuvre toutes les méthodes avec une animation: argument. Configurez votre animation puis appelez super avec le drapeau d'animation avant de commettre l'animation.

Answer 2

Je ne l'ai pas essayé le multi-vue-contrôleurs chose en dehors de ceux fournis UIKit (navigation / tab-bar / modales / etc) mais je ne vois pas pourquoi il ne devrait pas fonctionner. Sous le capot, tout est une vue, bien que je vais noter que UIKit offre des vues spéciales pour les contrôleurs de vue qui ont sans doute une sorte de traitement spécial par le système (UIViewController a une vue wrapper, UINavigationController a un UINavigationTransitionView ou quelque chose, .. .).

Je vous conseille de ne pas se soucier trop sur les « meilleures pratiques » - juste quelque chose de code qui fait ce que vous voulez. Un couple d'options:

• logique bâton dans les classes de vue (ewwww!). L'une de nos applications Est-ce qu'il peut gérer si la rotation d'une manière personnalisée (vues glisser / arrière au lieu de tourner). Nous devrions avons probablement mis en œuvre notre propre point de vue logique du contrôleur à la place.
• Briser le modèle en composants qui correspondent à des vues. Faire de chaque point de vue savoir comment charger son composant et récursive charge des sous-composants. Ensuite, le contrôleur de vue n'a qu'à se soucier de choses « grande image ».

Notez également que vous pouvez charger plusieurs grué dans le même contrôleur de vue par exemple il se connecter à une prise appelée editView.The grande différence est qu'il ne se fait pas automatiquement - [UIViewController loadview] de sorte que vous devez faire quelque chose comme

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

Vous aurez également à vous soucier de l'ajouter à votre hiérarchie de la vue, le déchargement sur - (void) viewDidUnload (iPhone OS 3.0+), mise en place en - (void) viewDidLoad au cas où il était un avertissement de mémoire pendant mode d'édition, etc ...

Il est pas facile, mais l'interface utilisateur ne l'est jamais.

Answer 3

Vous avez besoin d'une vue maître-détail mis en œuvre avec une scission vue / popover vue et contrôlée avec un UISplitViewController.

La vue principale est la liste des documents et la vue détaillée est la vue de modifier. Chacun a son propre contrôleur. Les deux contrôleurs sont eux-mêmes gérés par le UISplitViewController.

Si vous n'utilisez le contrôleur SPLITVIEW vous finir par la main de codage quelque chose qui fonctionne très bien comme ça. C'est vraiment la seule façon de faire ce que vous voulez facilement dans l'API et il est la mise en page que les utilisateurs iPad attendront.

Voir Création d'une interface Scinder dans le guide de programmation iPad pour plus de détails.