- -layoutSpecThatFits: must return an ASLayoutSpec.
- Move ASDisplayNode's -measureWithSizeRange: redeclaration to ASDisplayNode.h.
- Rename ASStackLayoutChild.h to ASStackLayoutDefines.h.
- Rename ASStaticLayoutSpecDimension.h to ASRelativeSize.h.
- Don't import ASLayout.h in other headers to prevent circular inclusions.
- Explain use cases of ASLayout's initializers.
- Clean up ASInternalHelpers.h.
- constrainedSizeForCalculatedLayout is of type ASSizeRange.
- calculatedLayout is better explained.
- Since ASLayout is cached and reused, its position property is mutable.
- ASLayoutable requires mutable properties that are used when attached to a stack layout.
- Thus, ASLayoutable objects (including ASDisplayNode) can be injected into stack layout directly.
- ASStackLayoutNodeChild no longer needed.
- Tests and Kitten sample updated.
- Both ASDisplayNode and ASLayoutNode conforms to this protocol.
- ASDisplayNode can be embeded directly into layout graph.
- Eliminate ASCompositeNode.
- Fix ASStaticSizeDisplayNode not recpect min constrained size.
- Updated tests.
- Introduce ASLayoutNode and its subclasses.
- ASDisplayNode measures its ASLayoutNode and cache the result (ASLayout). Calculated size and position of each subnode can be retrieved from the calculated layout.
- Custom nodes need to override -layoutNodeThatFits:(CGSize) instead of -calculateSizeThatFits:(CGSize).
- Custom nodes do not need to layout its subnodes (in -layout:) anymore. ASDisplayNode can handle the job most of the time, by walking through its layout tree.
- ASCompositeNode is used to embed (display) subnodes to a node's layout. That way, each subnode will also be measured while the parent node is measuring. And the parent node knows where its subnodes are within its layout.
- The code is forked from LayoutComponents in ComponentKit.
- Public interfaces are modified to be strictly Objective-C. As a result, users are not forced to switch to Objective-C++, the linker can happily compile and Swift fans can continue using the mighty ASDK.
These have been superseded by -[ASDisplayNode initWithViewBlock:] and
-[ASDisplayNode initWithLayerBlock:], respectively -- the new API allows
for custom initialisers, but does not support asynchronous display.
The old initialisers are still available in ASDisplayNodeInternal.h, for
internal subclasses and daring adventurers.
This adds new initializer methods to ASDisplayNode:
```objc
initWithViewBlock:(ASDisplayNodeViewBlock)viewBlock
initWithLayerBlock:(ASDisplayNodeLayerBlock)layerBlock
```
Sometimes a view can't be constructed with `-[initWithViewClass:]` but you want to use it with ASDK, so these new methods provide a way to wrap an existing view in a node.
The API is meant to preserve ASDisplayNode's behavior, so you can still construct and set properties on the node on a background queue before its view is loaded; even though the view was created a priori, it is not considered to be loaded until `node.view` is accessed.
Using the API looks like this:
dispatch_async(backgroundQueue, ^{
ASDisplayNode *node = [ASDisplayNode alloc] initWithViewBlock:^{
// Guaranteed to run on the main queue
UIButton *button = [UIButton buttonWithType:UIButtonTypeSystem];
[button sizeToFit];
node.frame = button.frame;
return button;
}];
// Use `node` as you normally would...
node.backgroundColor = [UIColor redColor];
});
The main thing this bridging API doesn't do (can't do?) is layout. Methods like `-[ASDisplayNode calculateSizeThatFits:]` and `-[ASDisplayNode layout]` cannot delegate to `[UIView sizeThatFits:]` and `[UIView layoutSubviews]` since the UIView methods must run on the main thread. If ASDK were internally asynchronous and could dispatch its layout methods to different threads (sort of like how ASTableView computes its cells' layouts) then we could mark nodes with externally provided views/layers as having "main-queue affinity" and delegate its layout to UIKit.
Test cases are included and all existing tests pass.
ASDisplayNodes now have an overidable method -placeholderImage that lets you provide a custom UIImage to display while a node is displaying asyncronously. The default implementation of this method returns nil and thus does nothing. A provided example project also demonstrates using the placeholder API.
Postpone manual display until a future release when it can be called on any thread. Provide the current node manual display logic as a category on ASDisplayNode only available for ASRangeController. Deprecate -displayImmediately.
ASDISPLAYNODE_DELAY_DISPLAY unconditionally delays *all* attempts to
execute display blocks, even those that have been cancelled. Fix that.
The DELAY_DISPLAY debugging tool is intended to simulate the effect of
expensive draw calls -- it lets you test your app's behaviour under
conditions potentially even worse than an iPhone 4. Unfortunately, the
current simulation is unusably incorrect, as can be demonstrated by
repeatedly scrolling up and down in the Kittens example project.
ASRangeController enqueues asynchronous display of ASTableView cell
nodes when they enter the working range, and suspends their display when
they exit. On a slow device, this performs as desired, limiting
expensive display computation to the space of the working range. In
the DELAY_DISPLAY simulation, the suspended displays are as expensive as
the executed ones, so ASRangeController becomes unusably slow.
Rename the ASDisplayNode property to match its _ASDisplayLayer
counterpart -- `displaySuspended` is more succinct and is a more
plausible name for a Cocoa BOOL property.
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.
* Reorganise and rename `_flags` for clarity and consistency.
* Remove ambiguity between `implementsDisplay` and `hasClassDisplay`.
* Delete useless `hasWillDisplayAsyncLayer` check -- make it a simple
subclass override point, as with `didDisplayAsyncLayer:`.
* Minor comment cleanup.
Initial open-source release of ASMultiplexImageNode. Documentation and
example code forthcoming.
Note: ASMultiplexImageNode requires Xcode 6 to compile. Tests are now
compiled against the iOS 8 SDK and run on iOS 7.1 and iOS 8.
ASImageNode and ASHighlightOverlayLayer were both using
[[UIScreen mainScreen] scale] directly. Bad. No cookie. Use
ASDisplayNodeScreenScale() instead.
(Also, regenerate Xcode project with Xcode 6 and current CocoaPods.)
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
