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.
