Yes, it could work that way too. In this scenario where you just need
to call #update, if the game controller keeps an array/set of child
items, you could just call
[gameItems makeObjectsPerformSelector:@selector(update)];
You would use KVO in the following hypothetical scenario, which is
adopte
The project is a simple demo game using the same approach explained by Brian
where game items listen for notifications and update themselves based on the
notification.
For some reasons, I think it would be easier for the game controller to know
about the game items and call #update on each of them
I am also not sure that I fully understand this scenario, but it
doesn't appear that you would need KVO. Do the "tasks" or the "Brain"
have any properties to observe?
As Ben points out, KVO really shines when you need to keep a UI in
sync with the state of a model.
If "tasks" just need to know wh
Coming from a Ruby background, I try to understand and pick the
best from Obj-C/Cococa and learn how to use brilliant ideas to
improve my coding.
Tonight I was working on a simple demo app to learn how things are
done in the Obj-C world and see how they would transpose to the
MacRuby wor
