Fixes:
- Usage of UIScreen in -[ASDisplayNode init]
(the offending individual will be prosecuted)
- #38: Proper teardown of nodes owned by ASTableView / ASRangeController
- #34: Fix infinite recursion in very rare subclassing scenario
- #30: Avoid animating cell and section additions to ASTableView
- #19: Set a more reasonable default for maximum display concurrency
r=nadi
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
TextKit machinery automatically applies styling to text marked with the
NSLink attribute, but because ASTextNode is unaware of it, the node's
tap handler doesn't treat NSLinks as links. Add NSLinkAttributeName to
the default linkAttributeNames property.
`-[ASDisplayNode willEnterHierarchy]` and `-didExitHierarchy` are
subclass hooks and should not be called directly -- doing so will
trigger an assertion! Move these declarations to the subclassing
header.
Fix regression from the ARC conversion. Change the raw, unretained
pointers in ASControlNode to weak references. Use NSMapTable instead of
the pointer-as-NSValue system.
`-[ASDisplayNode addSubnodeAsynchronously::]` and
`-replaceSubnodeAsynchronously:::` are unused and confusingly increase
AsyncDisplayKit's API surface. `-addSubnode:` and friends are
thread-safe and can be used on background threads, so removing these
methods does not constitute a decrease in functionality.
