12
votes

Déclarant iboutlet à l'intérieur ou à l'extérieur @interface?

Désolé si suis-je trop difficile sur celui-ci mais j'apprends une programmation iOS maintenant et je paraisse certaines personnes qui déclarent le iboutlet comme ceci:

iboutlet attaché à la propriété xxx

et certains déclarant comme ceci:

iboutlet attaché à la déclaration à l'intérieur de l'interface xxx

qui L'une est la bonne façon de le déclarer? Sont des différences entre eux? Si quelqu'un sache à expliquer pourquoi ils le mettent-ils sur différents endroits qu'il serait génial d'apprendre.

Merci beaucoup :)


1 commentaires

3 Réponses :


0
votes

Vous pouvez déclarer les deux manières, il n'y a aucune différence en réalité.

mais, voici la chose:

Si vous avez besoin de votre classe pour avoir une ivar avec un comportement spécial ou qu'il doit être accessible de l'extérieur, etc., et il doit s'agir d'une propriété, alors je dirai que vous avez 2 options à choisir (ci-jointes à la propriété et à l'intérieur de l'interface de classe).

Si ce n'est pas votre cas, ne créez pas de propriété, n'est pas nécessaire, faites-le simplement dans votre interface de classe.

espère qu'il aide;)


0 commentaires

12
votes

Ces deux sont encore « à l'intérieur de l'interface » de sorte que votre titre un peu confus, mais je vois ce que vous demandez.

Dans de nombreux cas, le résultat de l'une ou l'autre approche sera la même chose, mais ils sont différents. Une propriété IBOutlet sera la méthode appel setter de la propriété qui vous donne l'occasion de passer outre que si la mise en setter cette propriété devrait avoir un effet secondaire.

Je préfère utiliser les prises sur les propriétés parce que je pense que cela rend la gestion de la mémoire des objets chargés de la pointe beaucoup plus claire. Jetez un oeil à gestion mémoire des objets nib et je pense que vous verrez ce que je veux dire.

Objets dans le fichier nib sont créés avec un retain compter de 1, puis autoreleased. Comme il reconstruit la hiérarchie d'objets, UIKit rétablit les connexions entre les objets à l'aide setValue: forKey :, qui utilise la méthode de définition disponibles ou conserve l'objet par défaut si aucune méthode de définition est disponible. Cela signifie que (si vous suivez le schéma indiqué dans « points de vente ») tout objet pour lequel vous avez une prise reste valable. S'il y a des objets de niveau supérieur vous ne stockez pas dans les magasins, cependant, vous devez conserver soit le tableau retourné par le loadNibNamed: propriétaire: Options:. Méthode ou les objets à l'intérieur du tableau pour empêcher ces objets d'être libérés prématurément

IBOutlet Ivars appellera setters pour les Ivars si elles existent et conserver directement l'objet chargé de la plume si aucun poseur se trouve.

La publicité la propriété comme IBOutlet au moins il est clair que sera toujours utilisé setter de la propriété et de suivre tout ce qui règle la gestion de la mémoire a été établie pour cette propriété.

Enfin, je soutiens que IBOutlets font partie de l'interface publique d'une classe et il est donc préférable d'exposer les méthodes (via une propriété) pour travailler avec eux désireux que d'utiliser -setValue: forKey: pour manipuler les Ivars d'accompagnement qui devraient être un détail de mise en œuvre.


0 commentaires

1
votes

Les deux styles sont interchangeables, il n'ya pas de différence dans le code généré ou la manière dont les objets seront chargés à partir d'une nib. Vraiment.

Cependant, les deux styles ont une ligne redondante. Laissez simplement sortir la déclaration d'ivar. Juste la ligne xxx

est suffisante dans le temps d'exécution moderne.

Si vous avez un projet complexe, je suggère de déplacer toutes les sorties de l'interface publique dans un fichier d'en-tête séparé. La plupart des points de vente sont une interface privée, la seule raison de les avoir dans une en-tête est donc un constructeur d'interface peut les trouver.


0 commentaires