Suis-je en train d'abuser de la sous-classe UIViewController?

Question

En essayant de comprendre pourquoi viewWillAppear n'a pas été appelé dans mon application, je suis tombé sur ce que peut être une brute malentendu, je tiens à propos de l'utilisation prévue de UIViewController sous-classes.

Selon le post suivant viewWillAppear ne fonctionne pas lors de l'utilisation de addSubView!!! et le lien vers ce blog: http://blog.carbonfive.com/2011/03/09/abusing-uiviewcontrollers/ UIViewController sous-classement ne devrait se produire que dans des situations très spécifiques. Notamment lorsqu'il est ajouté directement à la UIWindow, ou d'autres Apple a créé la coutume des contrôleurs comme UINavigationControllers.

Je suis certainement coupable d'ajouter le point de vue de UIViewController sous-classes les avis d'autres UIViewController sous-classes.

En fait, je pensais que c'était plus ou moins l'idée de la Pomme de mise en œuvre de la MVC en général... Un CR, avec d'autres VCs-dessous, tous les heureux de l'obtention de leur déléguer les méthodes appelées.

Si il y a beaucoup de points de vue (qui, par définition, besoin de contrôle) qui vont et viennent dans une application, et beaucoup d'écrans entiers, dans le modèle décrit dans ce post, chaque écran rempli doit avoir qu'un seul maître VC sous-classe, avec tous les sous-vues contrôlé par la coutume, des contrôleurs (qui arrive à contrôler les points de vue) qui sont des sous-classes de simple NSObject.

Dans ce cas, UIViewControllers ne doit être directement à la Fenêtre ou UINavigationController, UITabBarController etc?

Vous êtes assuré d'obtenir l'UIVC Délégué méthodes appelées dans ce cas? Comment est-ce différent de l'appel de la délégué méthodes manuellement lorsqu'un viewcontroller de vue est une sous-vue de l'autre VC?

Honnêtement, cela semble être un énorme gaspillage de temps. Des implémentations personnalisées de ViewDidLoad, viewDidLoad, viewDidUnload, viewWillAppear, viewWillDisappear pour ne pas mentionner les choses aussi simples que des propriétés comme, disons, la "vue"...

Donc en gros, soit j'ai été complètement faux, ou je suis sur une oie sauvage chasse. Si UIViewController sous-classes ne peut pas compter sur lui pour appeler viewWillAppear, pourquoi ne pas simplement appeler la méthode manuelle, et être fait avec elle?

Pourquoi reproduire l'ensemble de la fonctionnalité perçue de UIViewController?

Answer 1

La réponse à la question titre: Oui.

Donc en gros, soit j'ai été complètement faux, ou je suis un sauvage poursuite de l'oie.

Il semble que vous avez été complètement faux. Le terme "vue" a un peu différents, mais liés significations:

• D'un point de vue est, bien sûr, tout objet est une instance de UIView ou une sous-classe UIView.
• Dans le contexte de la MVC, "vue" est utilisé collectivement, et nous parler de ce sujet ou que d'être "le point de vue de la responsabilité", même si "la vue" est vraiment un groupe d'objets.
• Quand on parle d'un point de vue contrôleur, la "vue" que le contrôleur gère est le UIView exemple que le contrôleur des points de vue pour et la hiérarchie des sous-vues qu'il contient.

Il semble que votre incompréhension est sur ce dernier point. Une-vue-contrôleur doit gérer une seule "page-écran" de contenu. Si vous utilisez une vue unique de l'objet contrôleur pour gérer plus d'un point de vue de la hiérarchie, ou si vous utilisez plusieurs contrôleurs de vue de gérer les différentes parties de la même vue de la hiérarchie, vous êtes à l'aide de UIViewController d'une manière qui n'a jamais été prévu et ce qui est susceptible de conduire à des problèmes.

Les méthodes que vous avez mentionné (-viewDidLoad, -viewWillAppear, etc.) sont censés dire le point de vue contrôleur de son point de vue de la hiérarchie était juste chargé de, est sur le point d'être affiché, et ainsi de suite. Ils ne sont vraiment pas voulu faire référence à une personne physique sous-vue, et il serait inhabituel pour un view controller besoin d'être étant donné que des informations pour les sous-vues. Si le point de vue de la hiérarchie était chargé, puis la vue contrôleur sait que tout dans cette hiérarchie a été chargé.

Vous semblez être l'interprétation de ces méthodes en tant que délégué de méthodes, mais ils ne sont pas. Un délégué est un objet distinct qui permet la personnalisation de la délégataire, sans la nécessité pour le sous-classement. -viewDidLoad et -viewWillAppear sont deux exemples de remplacer les points de UIViewController, une classe qui est prévu pour le sous-classement. Le point de vue de l'objet contrôleur appelle ces méthodes lui-même pour donner des sous-classes, une chance de prendre un peu d'action, à un point intéressant dans le cycle de vie du contrôleur.

Si UIViewController les sous-classes peuvent pas compter sur lui pour appeler viewWillAppear, pourquoi ne pas simplement appeler cette méthode manuellement, et être fait avec elle?

Prendre un bon coup d'oeil à UIViewController et vous verrez que la plupart des fonctionnalités fournies a à voir avec l'affichage de la vue (qui est, le point de vue de la hiérarchie) sur l'écran, ou avec l'intégration du contrôleur avec "conteneur" afficher les contrôleurs, tels que UINavigationController et UITabBarController. Rien de tout ce qui est utile pour les objets qui ne sont pas de la gestion de l'ensemble de la page-écran de contenu.

Il arrive parfois qu'un groupe de points de vue seront répliquées sur plusieurs écrans, et dans certains de ces cas, il est utile de gérer ces points de vue avec un objet qui est séparé de la vue-contrôleur lui-même. Je peux voir comment vous pouvez être tenté d'utiliser UIViewController en raison de sa -viewDidLoad et des méthodes similaires, mais ceux qui sont vraiment seulement une petite partie de ce UIViewController n'. Que signifie l'appel -presentModalViewController: sur l'un de ces objets? Ou pour accéder à ses navigationController ou parentViewController propriétés?

Si vous voulez vraiment gérer des sous-vues de votre point de vue du contrôleur de vue de la hiérarchie à l'aide de ces méthodes, créer une sous-classe NSObject qu'a -viewDid[Charger|Décharger|Apparaître|Disparaître] et -viewWill[Apparaître|Disparaître] les méthodes. Vous pouvez créer une classe une fois et puis une sous-classe aussi souvent que vous en avez besoin, et aucun de vos "subcontroller" les classes ont toutes supplémentaires, inutiles contrôleur de gestion truc qui vient avec UIViewController.

Edit: je veux ajouter un pointeur ici pour Apple-Vue-Contrôleur Guide de Programmation pour iOS, qui fournit un grand soutien pour ce que j'ai énoncées ci-dessus. Voici un passage de la sous-section intitulée "Afficher les Contrôleurs de Gérer un point de Vue de la Hiérarchie":

Afficher les contrôleurs sont directement associé avec une vue unique de l'objet mais cet objet n'est souvent qu'une racine vue d'une vision beaucoup plus large de la hiérarchie qui est également géré par la vue le contrôleur. Le point de vue du contrôleur des actes comme la centrale de coordination de l'agent pour le point de vue de la hiérarchie, de la manipulation des échanges entre son point de vue et tout contrôleur ou d'objets de données. Un seul - vue-contrôleur gère en général le les vues associées avec un seul l'écran de contenu, bien que dans applications iPad ce n'est pas toujours être le cas.

- Vue-Contrôleur Guide de Programmation est une lecture obligatoire pour toute personne à penser à l'écriture d'une application iOS. Il est utile de vérifier si vous ne l'avez pas lu dans un certain temps (ou jamais).

Mise à jour: à Partir de l'iOS 5, il est maintenant possible de définir votre propre conteneur de vue des contrôleurs, c'est à dire afficher les contrôleurs de gérer autre point de vue, les contrôleurs et potentiellement afficher les vues de vue multiples sur les contrôleurs en même temps. Vous pouvez en lire plus à ce sujet dans le guide ci-dessus dans la section Création de Conteneur Affichage des Contrôleurs. Rien de tout cela change vraiment les points essentiels ci-dessus: une vue unique contrôleur doit encore gérer une hiérarchie de vues et de méthodes comme -viewDidLoad toujours se référer à la totalité de la vue graphique, plutôt qu'aux sous-vues. Les conseils d'une vue contrôleur gère un "ensemble de la page-écran" de contenu n'est plus tout à fait précis, un peu comme UISplitViewController a affiché le contenu de deux contrôleurs simultanément depuis le lancement de l'iPad, vos propres contenants peut maintenant montrer le point de vue de plusieurs enfants de vue des contrôleurs. L'écriture d'un conteneur de-vue-contrôleur est un peu avancé -- vous devez être très familier avec l'utilisation de contrôleurs de vue général, et la façon dont la condition conteneur affichage des contrôleurs de travaux avant de vous prendre un coup de couteau à la création de votre propre.