Quand utiliser UIView ou UIViewController sur l'iPhone?
Je me suis toujours demandé comment utiliser un UIView par rapport à un UIViewController sur l'iPhone.
Je comprends que vous ne devriez pas utiliser UIViewController à moins d’afficher en plein écran, mais quelles sont les autres consignes?
Par exemple, je souhaite créer une superposition modale - un écran qui se glissera sur l'écran actuel. Si cette superposition modale est en plein écran, faut-il utiliser UIViewController? La dernière fois que j'ai construit quelque chose comme cela, j'ai sous-classé UIViewController, mais je me demande maintenant si cela était correct.
De Apple View Controller Guide de programmation pour iOS :
"Le rôle le plus important d'un contrôleur de vue est de gérer une hiérarchie de vues. Chaque contrôleur de vue a une vue racine unique qui englobe tout le contenu du contrôleur. Vous ajoutez à cette vue la vue dont vous avez besoin pour afficher votre contenu. "
Également:
"Il existe deux types de contrôleurs de vue:
- Les contrôleurs de vue de contenu gèrent un élément distinct du contenu de votre application et constituent le principal type de contrôleur de vue que vous créez.
- Les contrôleurs de vue par conteneur collectent des informations provenant d'autres contrôleurs de vue (appelés contrôleurs de vue enfant) et les présentent de manière à faciliter la navigation ou à présenter le contenu de ces contrôleurs différemment.
La plupart des applications sont un mélange des deux types de contrôleurs de vue. "
C'est une excellente question.
Ma règle de base. Est-ce que chaque 'page' majeure d'une application obtient son propre contrôleur de vue. Ce que je veux dire par là, c'est que lors de la phase de câblage de la conception de l'application, tout ce qui existe en tant que propre entité sera éventuellement géré par son propre contrôleur de vue. S'il existe un écran modal qui glisse sur un écran existant, je considérerai qu'il s'agit d'une page distincte et lui attribuerai son propre contrôleur de vue. S'il existe une vue qui se superpose et une page existante (telle qu'un écran de chargement ou une fenêtre d'aide.), Je les traiterais différemment, les implémenter en tant que sous-classes UIView et conserver la logique dans le contrôleur de vue de cette page. Si la fenêtre contextuelle a un comportement, je communiquerai de nouveau à ce contrôleur de pages en utilisant le modèle de délégué.
J'espère que ça aide. C'est vraiment une question philosophique et architecturale et on pourrait écrire beaucoup à ce sujet.
J'utilise UIViewController chaque fois qu'une vue est en plein écran et comporte des sorties/actions et/ou des sous-vues.
J'ai une approche quelque peu différente:
Remplacez UIView si vous prévoyez de réaliser un dessin personnalisé dans drawRect. Sinon, utilisez la sous-classe UIViewController et utilisez [self.view addSubview: blah] pour ajouter les composants de la page.
Il existe quelques autres cas particuliers, mais cela gère environ 95% des situations.
(Vous aurez toujours souvent besoin d'un UIViewController avec un UIView personnalisé. Mais il est courant d'avoir un UIViewController personnalisé sans UIView personnalisé.)
Est-ce que la chose qui glisse dans un écran autonome? Je veux dire, interagit-il directement avec le parent? Si tel est le cas, définissez-la comme suit UIView, sinon recommandez probablement une UIViewController
Si vous connaissez le modèle MVC, vous devriez être capable de comprendre la différence entre UIVIew et UIViewController. Pour faire une simple déclaration, UIView sert à rendre les éléments de l'interface utilisateur à l'écran. UIView est la super-classe de pratiquement tous les éléments de l'interface utilisateur Cocoa Touch. Ces éléments ne savent pas quelles informations ils sont censés afficher, ce qu’ils doivent faire quand un utilisateur clique sur un bouton, ce qui se passe lorsqu’une demande réseau async est terminée, etc. UIViewController est pour tout cela et plus encore. Il est de la responsabilité du contrôleur de vue de placer les éléments d'interface utilisateur aux emplacements appropriés à l'écran, de définir le contenu des éléments d'interface utilisateur, de gérer les pressions sur les boutons et autres entrées utilisateur, de mettre à jour le modèle si nécessaire, etc.
Conceptuellement, un seul UIViewController contrôle le contenu de tout l'écran dans une application iPhone. C'est pourquoi il est souvent facile de penser aux choses en termes de contrôleurs de vue. Si vous avez besoin d’une vue permettant à l’utilisateur de sélectionner les ingrédients d’une recette, vous aurez besoin d’un contrôleur UIViewController. J'ai fait cette distinction pour moi-même parce que je venais d'un contexte Java et que je n'étais pas habitué à la structure appliquant MVC. Je penserais à UIViews, je commencerais à les mettre en œuvre de cette façon, puis à toutes sortes de problèmes à cause de cela. Si vous souhaitez vous en tenir à UIKit pour votre application, le flux de travail créé par Apple est le suivant: pour chaque vue distincte de votre application, créez une sous-classe UIViewController, puis utilisez Interface Builder pour placer les éléments de l'interface utilisateur et créer des connexions pour les boutons etc. Cela fonctionne à merveille, vous fait gagner beaucoup de temps et vous permet de vous concentrer sur le bon fonctionnement de votre application.
UIView fait partie de UIViewController, voir la propriété view de UIViewController à cet effet. Comme vous l'avez souligné correctement, UIViewController gère un écran complet et il ne devrait y avoir qu'un seul UIViewController visible à la fois. Mais dans la plupart des cas, vous aurez plus d'UIViews ou de sous-classes d'UIView visibles à l'écran.
L'exemple que vous avez donné serait une utilisation correcte dans la plupart des cas. Comme vous l'avez peut-être remarqué, vous obtiendrez de nombreuses fonctionnalités lors de la sous-classification de UIViewController. L’animation de l’apparition et du renvoi de UIViewController en fait partie.
Comme l'a souligné marcc, si vous souhaitez faire glisser un élément dans lequel vous souhaitez glisser n'est pas un écran autonome, vous feriez mieux d'utiliser une vue UIV.
En conclusion, je dirais que si vous souhaitez utiliser la fonctionnalité fournie avec UIViewController, vous devez en faire un UIViewController. Sinon, UIView pourrait être mieux.
La classe iTunes U Standford propose une excellente conférence sur UIViewControllers. Je vous recommande de la regarder car elle contient de nombreuses informations sur UIViewControllers en général.
Placez tout sur un écran dans un UIViewController jusqu'à ce que le contrôleur de vue commence à avoir trop de code, puis divisez l'écran en plusieurs UIViewControllers contenus par un seul contrôleur de vue principal ...
Pour placer cela dans le contexte de votre réponse, créez un contrôleur de vue pour cette superposition modale. Il en aura un de toute façon si vous utilisez un contrôleur de navigation pour le présenter (et vous devriez probablement le faire).
J'utilise UIViewController pour afficher View en plein écran.
Pour un meilleur contrôle sur l'affichage personnalisé, je préfère la sous-classe d'UIViewController à la place d'UIView. J'utilisais auparavant UIView pour créer des sous-classes personnalisées.