- Introduce thread-safe ASEventLog
- ASCollectionNode and ASTableNode share their event log with their ASDataController. The controller uses it to log change set submitting and finishing events.
- ASCollectionNode and ASTableNode print their data source and delegate in their debug description.
* [ASCellNode] Added indexPath property.
* [ASCellNode] Cached the type of scrollView we're using in the node, and placed that logic in setScrollView.
* [ASCellNode] Removed table and collection view from indexPath, since they return the index paths from the view-space.
* Changed the logic for getting indexPath so that it works even when the cell is not displayed.
* [VerticalWithinHorizontalScrolling] Explicitally synthesized indexPath property.
* Separate dataSource & UIKit index spaces
Beef up our supplementary node support
Make the API way better
Go nuts
Add a unit test for UICollectionView's handling of reloadData inside batch updates
Wrap indexPathForNode: in a cache
Convert index paths in delegate methods
Go back on table view
Put collection view back
Switch up the API
Move most ASCollectionView API to ASCollectionNode
Move most table logic over to ASTableNode
Do the things
More conversion work
Keep on keepin' on
Get table view delegate API done
More porting
Simplify
Clear the delegate
More cleanup
Move more stuff around
Remove pointless file
Re-add some API
Put back more API
Use the right flag
* Some cleanup
* Remove incorrect comment
* Tweak the API
* Put back a couple methods
* update example projects (note: ASCollectionView deprecation warnings expected)
* change reloadDataWithCompletion:nil --> reloadData
* Clean up rebase
* Make deprecated numberOfItemsInSection methods optional
* Use the right flag
* Address nits
* update ASDKTube, ASDKgram & ASViewController examples
- Objects conform to ASSectionContext protocol can be provided via ASCollectionDataSource and later retrieved from the collection view. They are guaranteed to be in sync with sections of the collection view. They can be used to store additional data associated with each section, to be used in collection view layout and the like.
- ASSection is an internal object that is the foundation for coming debugging tools.
- Unit tests included.
* Add unit test to confirm that supplementary items must be contained within actual sections
* [ASLayoutInspecting] Deprecate collectionView:numberOfSectionsForSupplementaryNodeOfKind:
* Add another test to dig deeper into UICollectionView
[ASRangeController] We're already on main thread, remove blocks
Make data source read-only, clarify what's asynchronous
[ASDataController] Clean up some interfaces
[ASDataController] A little more cleanup
[ASDataController] Cleanup
[ASDataController] Restore some changes, exit more often
[ASDataController] Use item counts that we already have rather than requerying them
[ASDataController] Revert weakifications
[ASDataController] Add a mechanism to measure how much work we avoided
* [ASDataController] Add some assertions to clarify what queues things happen on
* [ASCollectionDataController] Optimize willReloadData
* [ASDataController] Minor optimizations, no functional changes
* [ASDataController] Always reload data on _editingTransactionQueue
* [ASDataController] Remove async data fetching option, deprecate callbacks
* [ASDataController] Not mutable
* [ASMultidimensionalArrayUtils] Use fast enumeration
* Optimize ASMultidimensionalArrayUtils
Currently within `ASCollectionView`, there is an assumption that there will always be a static number of supplementary views per section—even when additional items are added or removed from that section. This is evidenced by the fact that when you invoke -[ASCollectionView insertItemsAtIndexPaths:], the data source method -[ASCollectionDataSource collectionView:nodeForSupplementaryElementOfKind:atIndexPath:] is not invoked, preventing consumers from specifying a new number of supplementary nodes for the new set of items.
With this change, the set of supplementary nodes for a section is now recalculated not only on section-level mutations, but also on item-level mutations as well. This adds item-level counterparts to the section-level `-prepareFor...` subclassing hooks in `ASDataController+Subclasses.h` to make this possible.
This should fix#1278 and #1322
This has been tested in my project and seen to fix the assertion. Open to suggestions on how to test in a more universal way.
* make variable naming reflect ASEnvironmentTraitCollection vs ASTraitCollection
* move trait propagation to cell allocation instead of via a nested block
* move trait propagation when setting a displaynode's supernode instead of when adding a subnode
* fixed misspelling of "colection"
- Mutating a dictionary using -enumerateKeysAndObjectsUsingBlock:
can have unintended consequences.
- Using a copy of the keys to iterate over the values inside the
dictionary instead.
- Mutating a dictionary using -enumerateKeysAndObjectsUsingBlock:
can have unintended consequences.
- Using a copy of the keys to iterate over the values inside the
dictionary instead.
- These calls cause supplementary nodes to be allocated and laid out, but not inserted afterward. So the nodes are thrown away.
- Next time when it is the right time to allocate these nodes, it is the second allocation request and triggers assertion in ASIndexedNodeContext #1296.
- It is a container object that holds enough information to construct and measure a cell node
- All information is gathered on main thread. This allows ASDataController to capture the correct state of its data source before going to background.
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.
