Strategies for Accessing Other Cocos2D Nodes In The Scene Hierarchy

On September 20, 2012, in idevblogaday, by Steffen Itterheim

A question I see frequently asked by Cocos2D developers, in simplified form:

"I have this node A, how can I access this other node B?"

Whether it’s executing a message or getting the node itself as a reference, developers have a problem accessing nodes in other parts of the scene. Or the scene itself.

The most obvious is also a potentially dangerous solution: initialize the node with the references to the other nodes it needs. The danger lies in retain cycles, when node A has a retaining reference to node B and vice versa - then neither of them will let go, memory is leaked, strange bugs appear.

From the Cocos2D questions on stackoverflow.com it’s obvious how prevalent retain cycles issues are among Cocos2D developers. Therefore this article with strategies for accessing other nodes in various situations with their benefits and drawbacks.

And an explanation why self.parent.parent.parent… is really terrible practice.

Essential Cocos2D: Free Sample

Today’s iDevBlogADay article is a sample article from the upcoming Essential Cocos2D online documentation. That’s why it’s on a separate page.

More about Essential Cocos2D soon. It’s growing fast. And not to forget: Learn cocos2d 2 is now available!


This article was brought to you by ...

I very much enjoy the learning process, the pushing of boundaries (mine and yours and that of technology), having the freedom to pursue whatever is on my mind, to boldly program what no one has programmed before, and to write about what I've learned. Help me help you by browsing the products in the Learn Cocos2D Store.


Tagged with:  

2 Responses to “Strategies for Accessing Other Cocos2D Nodes In The Scene Hierarchy”

  1. Grillaface says:
    September 21, 2012 at 02:07

    Great article Steffen. Question though - like you mentioned, the first thing that comes to mind is passing a reference to the node in init. Assuming the node to be referenced is always stored in a weak property, is there ever any risk of a retain cycle?

    • Steffen Itterheim says:
      September 21, 2012 at 15:02

      No. But in ARC it should be a zeroing weak reference. Otherwise, and under MRC, you run the risk of a crash. It’s fine though if the referenced node is a parent or grandparent because the lifetime of the node will end before that of the parent. But if the node is a sibling (parallel) node or from a different branch of the node hierarchy, you can’t really be 100% sure about the referenced node’s lifetime.