Utilisation des contrôleurs affichage personnalisé pour gérer les différentes parties de la même vue hiérarchique

Question

Les états d'affichage de guide de programmation du contrôleur de l'utilisation de ce point de vue au sujet de contrôleur:

Chaque objet contrôleur de vue personnalisée créer est responsable de la gestion de tous du vues dans une seule vue hiérarchie. Dans les applications iPhone, les vues dans une hiérarchie de vues couvrent généralement l'intégralité de l'écran, mais dans les applications iPad, elles peuvent couvrir seulement une partie de l'écran. La correspondance un-à-un entre un contrôleur de vue et les vues dans sa hiérarchie de vue est le facteur de conception clé . Vous ne devez pas utiliser plusieurs contrôleurs de vue personnalisée à gérer différentes parties de la même vue hiérarchie. De même, ne doit pas utiliser un seul objet contrôleur pour gérer plusieurs écrans ayant une valeur de contenu de .

Je comprends que si nous utilisons avec plusieurs contrôleurs de vue personnalisée de contrôler les parties d'une vue (par exemple un contrôleur de vue de gérer les sous-vues d'une vue principale qui à son tour est géré par un contrôleur de vue) les méthodes par défaut comme:

didReceiveMemoryWarnings 
viewWillAppear 
viewWillDisappear 
viewDidUnload 

etc etc. ne seront pas appelés. En dehors de cela, existe-t-il une autre raison solide pour laquelle nous ne devrions pas utiliser plusieurs contrôleurs de vue pour gérer les sous-vues respectives d'une vue?

La documentation a également fournir une solution de rechange qui se lit comme:

Note: Si vous voulez diviser une vue hiérarchie en plusieurs sous-zones et gérer chacun séparément, utilisez objets contrôleur générique ( sur mesure objets descendant de NSObject) au lieu de voir les objets de contrôleur à gérer chaque sous-zone. Utilisez ensuite un seul objet contrôleur de vue pour gérer les objets de contrôleur générique .

Mais il n'y a aucune mention à pourquoi plusieurs contrôleurs de vue ne doivent pas être préférés. Ma question est la suivante:

Pourquoi ne le préférerions-nous pas? Je m'inquiète parce que je préfère utiliser la sous-classe de UIViewController pour gérer mes vues car je les charge depuis la plume à chaque fois et je sépare les plumes pour chaque contrôleur de vue. Il devient facile de répondre aux changements dans les étapes ultérieures du projet. Est-ce mal? Dois-je nécessairement changer mon style de programmation, ou est-ce que je suis d'accord avec cette approche?

Merci,

Raj

Answer 1

Eh bien, je dirais « aussi longtemps que cela fonctionne », vous pouvez continuer à faire comme vous le faites! Mais pour garder les choses "plus propres", j'utiliserais mes propres objets. Puisque ViewControllers est conçu avec d'autres caractéristiques générales à l'esprit (comme travailler avec des contrôleurs de navigation et des contrôleurs de barre d'onglets), ce qui le rend un peu "lourd" pour un usage simple, comme vous le faites. De plus, comme vous l'avez mentionné, certains événements ne sont appelés que lorsque la vue de viewController est ajoutée à la fenêtre principale. Est-ce que vous ne pouvez pas utiliser vos propres objets avec Interface Builder?

Si vous créez un (ou plusieurs) IBOutlets UIView, cela devrait fonctionner de la même manière.

Answer 2

J'ai une application qui utilise deux UIViewControllers sur un seul écran. Le fils est un UITableViewController. Je ne compte pas sur le comportement UIViewController de l'enfant - seulement les méthodes UITableViewController. Ceci est pratique car il existe d'autres cas où l'enfant UITableViewController gère l'intégralité de l'écran. Et dans ce cas, il utilise les méthodes UIViewController. Conception discutable? Peut être. Cela fonctionne bien depuis deux ans maintenant. Mais je ne suis pas sûr que je recommanderais le modèle.