Question

La référence UIKit indique que UIView est une super-classe de UIWindow, mais malgré cette filiation, UIWindow gère réellement UIViews. Cela me semble si inhabituel.

Est-ce que quelqu'un sait ce que cela signifie en termes de conception de logiciel?

Merci beaucoup.

EDIT:
J'ai lu le paragraphe correspondant dans le guide de programmation iPhone. Pourtant, je ne pouvais pas comprendre pourquoi ils faisaient l'inverse: laissez UIWindow être le parent d'UIView. Quelque chose a forcé Apple à concevoir cette hiérarchie de cette façon.

Était-ce utile?

La solution

from http: // développeur. apple.com/iPhone/library/documentation/iPhone/Conceptual/iPhoneOSGuide de programmation/WindowsandViews/WindowsandViews.html

  

L’héritage est une chose que les développeurs expérimentés de Mac OS X ont peut-être trouvé inhabituelle dans la classe UIWindow. Sous Mac OS X, la classe parente de NSWindow est NSResponder. Dans iPhone OS, la classe parente de UIWindow est UIView. Ainsi, dans iPhone OS, une fenêtre est aussi un objet de vue. Malgré sa parenté, vous considérez généralement Windows sous iPhone OS comme vous le feriez sous Mac OS X. En d'autres termes, vous ne manipulez généralement pas les propriétés associées à la vue d'un objet UIWindow.

EDIT:

UIView est quelque chose de générique (fournit les méthodes courantes que vous utilisez pour créer tous les types de vues et accéder à leurs propriétés.) tandis que UIWindow est plus concret (la classe définit les objets qui gèrent et coordonnent les fenêtres qu'une application affiche à l'écran.)

Je sais que c'est un peu vague et je pense que seule pomme saurait la raison exacte de cette hiérarchie.

http://developer.apple.com/iPhone/library/documentation/UIKit/Reference/UIWindow_Class/UIWindowClassReference/UIWindowClassReference.html#//apple_ref/occ/cl/UIWindowClass .

  

La classe UIWindow définit des objets (appelés fenêtres) qui gèrent et coordonnent les fenêtres qu’une application affiche à l’écran. Les deux fonctions principales d’une fenêtre sont de fournir une zone d’affichage de ses vues et de distribuer des événements à ces vues.

et http://developer.apple.com/iPhone/library/documentation/UIKit/Reference/UIView_Class/UIView/UIView.html#//apple_ref/occ/cl/UIView

  

La classe UIView fournit des méthodes courantes que vous utilisez pour créer tous les types de vues et accéder à leurs propriétés. Par exemple, sauf si une sous-classe a son propre initialiseur désigné, vous utilisez la méthode initWithFrame: pour créer une vue. La propriété frame spécifie l'origine et la taille d'une vue en coordonnées superview. L'origine du système de coordonnées pour toutes les vues se trouve dans le coin supérieur gauche.

     

Les objets UIView sont disposés dans un objet UIWindow, dans une hiérarchie imbriquée de sous-vues. Les objets parents dans la hiérarchie des vues sont appelés superviews et les enfants, des sous-vues. Un objet de vue revendique une région rectangulaire de sa vue d'ensemble englobante, est responsable de tous les dessins dans cette région et peut également recevoir des événements s'y produisant. Les vues jumelles peuvent se chevaucher sans problème, ce qui permet un placement complexe des vues.

Autres conseils

Parce qu'ensuite, UIView aurait des propriétés (héritées) et un comportement qui n’a de sens que pour les fenêtres. C'est tout simplement faux.

L’inverse est plus logique: une fenêtre ajoute un comportement au-dessus des vues. Ainsi, il peut dessiner, avoir des limites, contenir d'autres vues, etc. Mais il étend cela avec, par exemple, le rendu à l'écran.

Sous MacOS X, NSWindows ne sont pas des vues. Ils contiennent une "vue racine", appelée contentView. Les fenêtres iOS sont une composition de NSWindow + sa vue racine.

Chaque vue UIView normale, y compris la vue racine de la fenêtre principale, doit avoir une vue parent. UIWindow hérite de UIView pour effectuer les tâches d'une vue parent dans une hiérarchie de vues. UIWindow n’est pas une vue normale et a ses propres implémentations de méthodes de l’interface d’UIView.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top