Meilleures pratiques pour les UIView et UIViewController personnalisés ?

Question

J'ai actuellement une application iPhone simple qui charge une sous-classe personnalisée de UIView. Il n'y a pour l'instant qu'un seul contrôleur pour toute l'application, bien qu'il y ait plusieurs UIViews pour séparer le programme logiquement.

Ma structure actuelle ressemble à quelque chose comme ceci :

mainView : UIScrollView
    \__ has one subView : myCustomUIView : UIView
            \__ has many subSubView : myOtherCustomUIView : UIView

J'espère que c'est clair ; les deux points, bien sûr, représentent l'héritage.

Mon problème est le suivant : J'ai besoin d'intercepter les événements au niveau le plus bas, le subSubView. Je peux probablement le faire dans le contrôleur d'application si nécessaire, mais devrais-je plutôt avoir un subSubViewController ? Devrais-je aussi avoir un subViewController ?

Si oui, quelqu'un peut-il m'indiquer des références pour faire cela à la main ? Je peux bien sûr créer les classes, mais les connecter à des vues personnalisées ne semble pas être une mince affaire. Je n'utilise pas du tout le constructeur d'interface à part la nib principale qui contient l'objet fenêtre.

Ma principale confusion vient de ce qui se passe lorsque j'ai une vue imbriquée dans une vue avec un contrôleur différent. Disons que j'ai un subSubViewController, mais que mainView a toujours son mainViewController. Puisque la subSubView est contenue dans la mainView, cela ne poserait-il pas un problème ?

Et dois-je utiliser des délégués pour tout cela ?

Tout coup de pouce dans la bonne direction serait apprécié.

Answer 1

Les vues et les contrôleurs de vues existent par paires. Chaque contrôleur de vue contrôle une vue et les sous-vues de la vue. Cela est nécessaire car les contrôleurs de vue se trouvent dans la chaîne de réponse aux événements. Si plusieurs contrôleurs de vue sont actifs dans la même vue, la chaîne de réponse est brouillée.

Les contrôleurs de vue standard ne disposent pas d'un subController et ne comprennent pas si un autre contrôleur est actif dans la même chaîne. Les contrôleurs de navigation et de barre de tabulation existent précisément pour gérer les contrôleurs hiérarchiques. Cependant, ils le font en remplaçant une paire vue/contrôleur par une autre. Vous ne pouvez pas utiliser les contrôleurs de navigation ou de barre d'onglets pour fournir des contrôleurs différents aux sous-vues.

Ainsi, quel que soit le nombre de sous-vues que vous pouvez avoir pour chaque vue, vous vous retrouvez avec un seul contrôleur par écran.

Vous pourriez vouloir reconsidérer votre conception. Si les vues secondaires doivent toutes avoir un comportement hautement personnalisable, vous pouvez les déplacer vers des vues individuelles dans une hiérarchie de contrôleurs, comme dans le modèle de conception maître-détail.

Si vous devez avoir toutes les vues secondaires sur le même écran, je vous suggère d'examiner la façon dont UITableView et UITableViewController gèrent les choses. (Vous pouvez peut-être vous contenter d'utiliser un tableview modifié). Un tableview est un scrollview qui contient plusieurs subviews pour les cellules, les titres de section, les en-têtes et les pieds de page. Il gère cela en piégeant les touches du tableau et en déterminant quelle vue de cellule a été touchée, puis en prenant les mesures appropriées.

Si vous avez besoin d'un comportement hautement personnalisé pour chaque sous-vue, vous pouvez utiliser le modèle de délégué et attribuer à chaque sous-vue un objet de délégué différent. La vue pourrait piéger ses propres touches et appeler son propre délégué.

Les vues défilantes peuvent être délicates à mettre en œuvre pour personnaliser le comportement tactile, car elles captent les touchers à un niveau plus élevé que les autres vues afin de pouvoir déterminer si elles doivent défiler ou non.