Quel est le but de faire Je n'ai trouvé aucune information définitive à ce sujet dans les documents.
Je comprends que si quelque chose est fait un uiviewcontroller une sous-classe de uireponder ? Était-ce fait uniquement de passer les événements de rotation?
Mise à jour
uireponder , ce quelque chose est supposé être inclus dans la chaîne du répondeur et les événements de processus. Mais j'ai deux doutes rongeants.
uiviewcontroller est mis dans la chaîne de répondeur juste après son Voir . Pourquoi avons-nous besoin d'un contrôleur d'affichage dans la chaîne du répondeur du tout ? Sa vue est déjà là, alors pourquoi ne laissez-nous pas que l'opinion traite les événements qui n'ont pas été traités par ses sous-visions?
4 Réponses :
Cela va ressembler à une réponse de la glib, mais ce n'est vraiment pas. Si une vue ne répond pas à un événement, il est transmis la chaîne répondeur donnant des objets de niveau supérieur une chance de le gérer. Par conséquent, les contrôleurs d'affichage et la classe d'application sont toutes sous-classes de Vous pouvez trouver des informations plus détaillées sur la chaîne du répondeur dans Compétences d'applications de cacao pour iOS: Objet du répondeur sur le site de développeur d'Apple. UIVIEWCONTROLLER est une sous-classe de uirePonder afin que cela puisse réagir aux actions des utilisateurs (par exemple, touche, mouvement, etc.).
uireponder
C'est très bien. Mais pourriez-vous donner des exemples béton lorsque UIViewController réponses réellement aux actions, touche par exemple?
OK, un exemple totalement artificiel: Supposons que vous ayez un certain nombre d'entrevues UIImage, chacun affichant un animal. Lorsque l'utilisateur touche un, vous voulez jouer au son de l'animal. Plutôt que d'avoir chaque vue jouer au son, vous pouvez avoir le contrôleur d'affichage réagir aux événements et jouer le son approprié. Cela lui permettrait d'arrêter le son qui joue avant de commencer un nouveau.
Meilleur exemple: si vous souhaitez mettre en œuvre glisser-déposer entre deux sous-espions.
Avec le cas animal, je suggérerais un design différent, lorsque toutes les informations sur un animal (l'apparence et le son) sont encapsulées à l'intérieur d'un objet modèle et présentées dans un objet d'affichage, avec un objet de contrôleur qui passe simplement les données. (Cependant, le animalview peut avoir une méthode comme shottuptheanimalnow ). En ce qui concerne le glisser-déposer, veuillez vous reporter à la question mise à jour. Pourquoi l'uiviewiewontroller ne peut pas utiliser gérer cela?
Plus sur les animaux: peut être une sous-visVIEW AntinsoundPlayer serait encore mieux :)
@ADUBR vrai, mais ce serait un très mauvais exemple de la raison pour laquelle vous pourrait vouloir un contrôleur d'affichage pour traiter les événements qui étaient toute l'idée de l'exemple maintenant, n'est-ce pas?
UIViewController est dans la chaîne du répondeur pour permettre à il de traiter tout événement. Il y a plus que des événements que vous pensez (touches) qui passent à travers cette chaîne. Les événements de mouvement sont passés à travers la chaîne, touchent des événements qu'une vue spécifique ne gérait pas, vous pouvez également forcer les choses à travers la chaîne de répondeur à l'aide de L'autre chose que vous pouvez remarquer, c'est que UIAPPLication est également une sous-classe d'uiresponder. Tous les événements qui ne sont pas manipulés se retrouveront là-bas. [uiapplication SendEvent: ...] avec une cible nulle. < / p>
Je pense pas aux touches mais de rotation - est-ce la seulement la raison? En ce qui concerne UIAPPLICTION - c'est l'objet de contrôle principal de l'application, donc je n'ai aucune question à ce qu'elle soit un répondeur. S'il vous plaît vérifier la question mise à jour.
Dans la gestion de la conception MVC de l'événement s'est produite dans la vue devrait effectuer un contrôleur.
Il existe une fonctionnalité, pour définir "nil" sur "cible" de - [Uicontrol AddTarget: action: ForControlvents:] Dans le cas où la chaîne du répondeur est recherchée sur un objet disposé à répondre à l'action.
C'est-à-dire en raison de l'option de recherche, UIViewController est la sous-classe d'UIREPONDER.
Ainsi, vous pouvez envoyer vos événements de contrôle personnalisés de la même manière pour obtenir des avantages de la "recherche".
Je pense que votre problème peut simplement être un échec de la pensée orientée objet.
par les documents:
La chaîne du répondeur est une série liée d'objets de répondeur auxquels Un événement ou un message d'action est appliqué.
En Uikit, le contrôleur d'affichage se trouve dans la chaîne de répondeur entre sa vue et la vue sur laquelle le contrôleur a été poussé. Il est donc offert de tout événement ou action que ses vues ne gèrent pas.
Le prochain répondeur du contrôleur de visualisation la plus haute est la fenêtre, le prochain répondeur de la fenêtre est l'application, le prochain répondeur de l'application est le délégué de l'application et le délégué de l'application est l'endroit où l'argent s'arrête.
Votre question "a-t-il été fait uniquement de transmettre les événements de rotation?" applique le test incorrect; Cela implique qu'à un moment donné, la chaîne du répondeur avait été entièrement conçue et quelqu'un pensa 'Oh, attendez, qu'en est-il de la rotation? Mieux choisir les contrôleurs d'affichage dans la chaîne '.
La question initiale aura été: est-elle utile si des événements ou des actions peuvent être traités par le contrôleur d'affichage si aucun des vues ne les gère? La réponse devrait évidemment être «oui» comme - même sur un appareil à écran tactile - il y aura des événements ou des actions qui ne sont pas intrinsèquement liées à une vue.
Les exemples les plus évidents sont ceux liés aux entrées physiques autres que l'écran. La rotation de l'appareil est donc une. Les touches presses sur un clavier Bluetooth sont une autre. Les télécommandes sont une troisième. L'accéléromètre est un quatrième.
L'exemple le plus évident suivant est des événements ou des actions générées par le système qui devraient aller au même acteur local plutôt qu'à tout le monde. Dans IOS, il est généralement demandé à un acteur plus spécifique, comme le gestionnaire d'annulation le plus local ou l'identité de la vue d'entrée de la vue indiquée si la mise au point vous vient.
Un exemple légèrement moins évident est celui illustré par
uimenucontroller - une vue contextuelle qui publie un événement d'entrée d'utilisateur qui peut avoir besoin de traverser plusieurs contrôleurs d'affichage pour accéder à celui qui devrait agir sur ce. Les contrôleurs de la vue enfant de IOS 5 augmentent énormément le nombre de possibilités ici; Très souvent, vous allez avoir un contrôleur de vue parent avec la logique de faire un tas de choses et des enfants qui souhaitent passer des messages jusqu'à CULDUI SHAIT comment les gérer, sans codage dur de la hiérarchie.Donc, non, les contrôleurs d'affichage n'étaient pas ajoutés à la chaîne du répondeur pour gérer les événements de rotation. Ils ont été ajoutés car logiquement, ils appartiennent à être là sur la base de la définition initiale de la chaîne de répondeur.