The optimization seems correct now, but apps like Pinterest have some core code relying on edit operation
order that is actually not permitted by UIKit (and this diff) but were tolerated previously. We will
re-land this once we have time to adapt the code.
Introduced ASIndexPath for efficient handling of index paths in C++ vectors,
while maintaining the readability of ".section" and ".row" instead of
".first" and ".second" inside of complicated business logic.
Confirmed that the working range calls are firing appropriately during
ASTableViewStressTest, including the deallocation of the rich text placeholders
provided by ASTextNode.
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.
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.
This brings back the concept of a window store for nodes that are in the working range (reverting #127). It turns out that due to the system architecture if there are nodes who fetch remote content (e.g. `ASNetworkImageNode`), calls to `-display` will occur before fetching has been completed. The next chance the nodes have to decode and display content is then when they are actually on the screen, thus defeating the purpose of a working range.
With the reintroduction of the working range window, nodes are "stored" in the window and when content is finished being fetched, CA triggers `-display` since they are part of a view hierarchy.
This can be tested in the Kittens project by insuring that before `ASRangeController` adds a node to [a visible view](https://github.com/facebook/AsyncDisplayKit/blob/master/AsyncDisplayKit/Details/ASRangeController.mm#L57) that the image node (with remote content) has set its layer's contents.
This is a step towards a preloading range. We first want to migrate towards arbitrary ranges instead of being coupled to the notion of a single "working range".
ASRangeController previously enqueued display of individual nodes by
adding their views to the hierarchy, wrapping each `-addSubview:` call
in an explicit CATransaction to force displays to occur in order. This
hack is no longer necessary -- kill it.
