Summary:
What it says on the tin. This allows Nodes to effectively participate in the responder chain.
Caveat: see note in implementation below. Would have been nice to use `-targetForAction:withSender:` the way the docs imply you can, but alas.
Test Plan: Observe a node in the responder chain get invoked to handle an action it implements.
Reviewers: bcunning, zsh, sma, jpasqualini, suv, nyn531, b3ll, aaronpang, kimon, grp, jonathan, rnystrom, nadi
Reviewed By: nadi
Subscribers: trunkagent, rnystrom
Differential Revision: https://phabricator.fb.com/D1894023
Signature: t1:1894023:1426026643:203945b6a7c318f6d2c9b94d876da61da31327bd
Currently we miss calling `-[super touches*]` on `_ASDisplayView` touch events. We delegate handling to the node which then forwards all touch events to the *superview*, skipping the current view. This seems to have some side effects with `UITableView` and it's cells/content views.
fixes#188
This is a remnant from before `willAppear` and `didDisappear` were
renamed to better reflect their hierarchy-change status (being added to
the hierarchy != being visible). May be useful for turians.
ASDisplayNode and several subclasses had previously cleared memory-heavy
objects like the backing store and text layout manager when the node's
view
or layer is removed from a visible heirarchy. This works great in any
system
that uses a "working range", where exiting the range removes the node
from
the hierarchy and reclaiming memory at that time is important.
However, for
standard UIViewController patterns (unused in Paper), this behavior
causes
highly undesirable thrashing (leading to visible flashes & wasteful
re-rendering of content).
After this change, node subclasses should implement -reclaimMemory if
they
need to perform any other cleanup besides backing store destruction
when they
leave a working range or other scenario where memory reduction is
valuable.
To trigger this behavior, calling code should use
-recursivelyReclaimMemory.
r=nadi
