* First approach to improve accessiblity
* Clear accessibleElements in addSubview: and willRemoveSubview:
* Adjust comments and rename viewNode to node
* Create new accessible elements if screen coordinates of view changes
* Remove legacy clearing of accessibleElements
* Performance improvements
* Use bounds for screenFrame calculation and indexOfObjectIdentical: in indexOfAccessiblityElement:
* Add ASDK_ACCESSIBILITY_DISABLE compiler flag to disable custom accessibility code in ASDK
* No need to set a frame if a subnode view is an accessibility element and not layer backed
This situation is relatively uncommon. If a user manually uses -[UIView addSubnode:], the convenience category method,
and then calls -[ASDisplayNode removeFromSuperview] -- we would bypass performing the actual removal as no supernode pointer
is set. After further consideration, the special handling here to support divergence between the supernode pointer and
the view / layer hierarchy is not something we need to maintain going forward, and removing it makes addressing this easy.
This helps us support special cases such as ASScrollNode correctly driving the -layout
method for subclasses even though it is based on UIScrollView & can't use _ASDisplayView.
I suspect this will be useful for ASCollectionNode and ASTableNode as well, which would
allow nesting those classes inside of other collections / tables (e.g. horizontal
unit within a vertical unit).
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
