Timelines & Triggers - Learn SpriteBuilder for iOS Game Development - page 157

Caution Notice that onEnter requires calling its [super onEnter] im-
plementation. The compiler will warn you if you omit calling [super
onEnter] . If you don't call the super implementation, scheduling and input
events will not work or won't work correctly. Always heed compiler warnings!
Warnings are there to improve your code quality and to make you aware of po-
tential issues. Search for the exact warning or error text if you want to find out
more about a specific warning and how to fix it.
The first order of business in Listing 5-8 is to set the visible status of the trigger node
to NO . Actually, it's setting the trigger's parent node. That's because the color node repres-
enting the trigger area visually is the node with the custom class Trigger . But the color
node is a child node of the TriggerOnce.ccb root node. I prefer to hide the root node
in case I want to design more complex triggers with multiple color nodes, for instance.
Next the node takes over its parent's name. That is because in Level1.ccb the Name prop-
erty is assigned to the Sub File node instance that references the Trigger-
Once.ccb . That ends up assigning this name to the TriggerOnce.ccb root node, the
color node's parent. Assigning self.name from _parent.name is merely a conveni-
ence because it allows you to use the _name ivar declared in the CCNode class.
Tip Since forgetting to give a trigger a name can be a common mistake, I de-
cided to add an assertion here that warns you if the _parent.name.length
is 0—meaning the parent's name is either nil or an empty string. This asser-
tion will fail in both cases: if _parent.name is nil , the entire test will also
return nil (aka 0) because messages sent to nil objects return 0 by default.
You may be wondering why I did not assign directly to the _name ivar or why I got the
name via _parent.name rather than self.parent.name .
As a rule of thumb, you should prefer to use an ivar, where available, when merely read-
ing its value. It makes the code shorter and, as a side-effect, slightly faster. However,
when assigning a value to a property, it is best practice to assign to the property via
self.name rather than assigning to the _name ivar directly. The rationale here is that
self.name = @".." internally runs the property setter method [self
setName:@".."] , which may perform additional code. Bypassing the property setter
can result in all kinds of issues. If you have the slightest doubt about possible side-effects