2010-12-12 19 views
1

Disons que j'ai un objet avec un certain nombre de propriétés, l'une d'entre elles étant une CALayer.Retourne l'objet dont quelque chose est une propriété?

Tout au long de ma vue, je dois frapper les couches de test. Après avoir obtenu la couche, je dois alors obtenir l'objet dont la couche est une propriété, ou "auquel elle appartient". Est-il de toute façon de retourner le propriétaire d'une propriété?

Merci!

Répondre

2

Une approche consiste à itérer vos objets, en comparant la propriété de couche à l'CALayer récupéré par hit-test:

MyObject *theObject = nil; 
for (MyObject *obj in self.objects) { 
    if (obj.layer == theLayer) { 
     theObject = obj; 
     break; 
    } 
} 

Une autre approche consiste à sous-classe CALayer et ajouter Ivar/propriété pointant vers l'objet qu'elle représente . Pour éviter les cycles de retenue, il doit être @property(assign) MyObject* representedObject. Cela rend l'objet trivial, mais nécessite de sous-classer CALayer.

+0

Sous-classe CALayer semble définitivement résoudre ce problème, mais j'avais quelques problèmes avec hitTesting :. Disons que je sous-classe CALayer (l'appelant spriteLayer) et lui donne deux propriétés BOOL, quand j'appelle hitTest sur le calque racine de la vue et que j'obtiens un de ces spriteLayers, il le retourne comme calayer, donc quand j'essaie d'accéder à BOOL propriétés, je ne peux pas: '(... Du point de vue de la conception, il est vraiment plus propre d'avoir ces BOOLS comme propriétés de la couche, donc j'aimerais savoir ce qu'il faut faire ici. –

+1

Vous pouvez vérifier la classe de la couche obtenue par le test d'impact et si c'est, disons, SpriteLayer, vous pouvez lancer le pointeur vers (SpriteLayer *) et accéder en toute sécurité aux propriétés spécifiques de SpriteLayer. C'est parfaitement OK du point de vue du design et du langage. N'oubliez pas qu'avant de lancer un pointeur d'objet, vous devriez toujours vérifier sa classe: 'if ([classeobjectif] == [classe SpriteLayer])', car si vous ne le faites pas, vous risquez de tomber en panne si vous envoyez un message. à. – Costique

+0

Merci mon pote. Aide à grande échelle! –

4

Nous avons trois choses différentes:

  1. La propriété
  2. La variable d'instance derrière la propriété
  3. Le CALayer

Ce sont trois choses distinctes. La propriété appartient à la classe de l'objet et indique au compilateur comment accéder à la variable d'instance (si je peux être un peu ondulé). La variable d'instance appartient à l'objet et pointe vers le CALayer. Et le CALayer fait juste sa propre petite chose CALayer.

Plusieurs variables d'instance différentes utilisées par un nombre quelconque de propriétés provenant du même objet ou de nombreux objets différents peuvent toutes pointer vers ce même objet CALayer. Par conséquent, la question devient: un objet conserve-t-il une liste de toutes les variables qui pointent dessus?

Et la réponse est: Malheureusement, non.

2

Je vous suggère de passer les parents des CALayer s au lieu des couches réelles lorsque vous effectuez le test d'accès, de sorte que vous n'avez jamais besoin de sauvegarder sur le parent.

Vous ne trouvez pas le parent d'un objet de propriété, sauf si vous avez implémenté une relation bidirectionnelle. Les relations bidirectionnelles sont généralement mauvaises, car elles peuvent facilement introduire des cycles de retenue.

La solution générale à ceci dans Cocoa est d'utiliser des délégués, s'avère que le délégué pour un CALayer est le UIView qu'il soutient. Ainsi, dans le cas de la plupart des instances, vous pouvez sauvegarder jusqu'à son parent via le délégué. Je remarque que je dis la plupart, pas tous, donc ce n'est pas une balle d'argent.