- Injection can be done via a new internal initializer. The class will be used by ASTableView to create (and configure) a new data controller.
- ASTableViewTests now injects its own type of ASDataController. This facilitates new ways for testing ASTableView-specific behaviours. The first application is counting the number of times relayoutAllNodes is called on the data controller.
- After node constrained sizes were changed (because the table view width was changed, for example) and before relayoutAllNodes is executed (on main), if there is any layout tasks being executed on background, the new sizes will be used immediately. Therefore, by the time relayoutAllNodes is performed, some nodes already have an up-to-date layout and don't need to remeasure.
- As a result, after relayoutAllNodes is completed, the number of layout passes performed on main thread for each node increased between 0 and 1 (i.e some nodes were remeasured, others weren't). ASTableViewTests is updated to assert this behaviour.
- Above is the generic case. Correctly handling it means relayout when the table view enters or leaves editing mode is solved as well.
- Async data source API removal: In a table view, cell nodes should always fill its content view and table view widths. Thus async data source can no longer provide custom constrained size for cell nodes. This removal allows table view to better handle relayout.
- Some more tests are added to ASTableViewTests to check against use cases handled in this diff.
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.
