- -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.
This diff resolves all known consistency issues with ASTableView and ASCollectionView.
It includes significantly more aggressive thrash-testing in ASTableViewStressTest,
which now passes on a variety of device and simulator configurations. It also updates
the unit tests run on every commit to ensure any regression is caught quickly.
A few of the salient changes in this diff:
- ASTableView now uses Rene's ASCollectionViewLayoutController, and actually uses a
UICollectionViewFlowLayout without any UICollectionView. This resolves an issue where
ASFlowLayoutController was generating slightly out-of-bounds indicies when programmatically
scrolling past the end of the table content. Because the custom implementation is likely
faster, I will revisit this later with profiling and possibly returning to the custom impl.
- There is now a second copy of the _nodes array maintained by ASDataController. It shares
the same node instances, but this does add some overhead to manipulating the arrays. I've
filed a task to follow up with optimization, as there are several great opportunities to
make it faster. However, I don't believe the overhead is a significant issue, and it does
guarantee correctness in even the toughest app usage scenarios.
- ASDataController no longer supports calling its delegate /before/ edit operations. No
other class was relying on this behavior, and it would be unusual for an app developer to
use ASDataController directly. However, it is possible that someone with a custom view
that integrates with ASDataController and ASRangeController could be affected by this.
- Further cleanup of organization, naming, additional comments, reduced code length
wherever possible. Overall, significantly more accessible to a new reader.
- 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.
This applies primarily when beginUpdates / endUpdates is not used.
Due to user interaction-driven edits, like reloads or adding content
at the bottom, sometimes this is unavoidable in app design and thus
critical.
I have a diff in flight to make ASDataController / ASRangeController
robust against very aggressive thrash testing, which will be added
both to the unit test suite and this new example project.
ARC doesn't play nicely with structs that contain references to
Objective-C objects, which causes breakage when using AsyncDisplayKit as
a dynamic framework (e.g., with CocoaPods 0.36+). Fixes#198.
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.
