* Rebase ASRangeController diff with master.
* fix Table / CollectionNode debug label names
- now returns class names rather than generic ASTableNode, ASPagerNode
- ASPagerNode will be labeled as ASPagerNodeProxy (not sure how to get around this)
* refactor layout code: use ASDk's own resizeableRoundedCorner... methods
* Fixes and cleanup for manual layout version of range controller debug overlay.
I am working on a layout spec-based version, but it has some issues, so landing this to get the near-term value is probably the best next step.
* Remove .orig and .rej files.
* One last .orig file to remove.
* Final project file cleanup and tweaks to implementation for ASTableNode.
* fix build issues
* fix arrow directions
[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
* Perhaps controversially, decomposing ASRangeControllerUpdateRangeProtocol+Beta.h such that the categories on various classes are defined in the classes themselves since that's where the implementation of those categories is provided.
* Updating unit tests and import other headers the tests took for granted. The tests could probably import the umbrella header and not have to worry about this.
* Updating the "Life without Cocoapods" sample to build and run dependent on ASDK as a static library.
* Added a "Life With Frameworks" sample app to build and run dependent on ASDK as a framework, proving the framework targets work.
* [ASTableView] constrainedSizeForRowAtIndexPath
* Quick fix to header file
* Switch to Delegate from DataSource.
* Update testing variables to reflect switch to delegate
* [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
Initial attempt to get display traits working with ASEnvironment.
To get proper ASDisplayTraits support, you must use an ASViewController. The ASViewController implements UITraitCollection-related methods (`traitCollectionDidChange:`, `willTransitionToTraitCollection:withTransitionCoordinator:`, viewWillTransitionToSize:withTransitionCoordinator`) to update the internal ASDisplayTraits and propagate them to subnodes.
ASTableNode and ASCollectionNode don't actually have their cells as subnodes, so a little bit of trickery is involved (on `setEnvironment:` the table/collection node gets its data controllers completedNodes and propagates the new traits. see `ASDisplayTraitsCollectionTableSetEnvironmentState`). The data controller also passes the current display traits when creating new cells.
ASViewController also supports the ability to return a custom set of display traits. So if you have a modal dialog that should always be told it is in a compact size class, you can set the override block before displaying the VC.
A new example, called Display Traits, has been added. It shows how display traits can be used in a ASViewController with a normal ASDisplayNode as its root, as well as in ASViewControllers hosting table nodes and collection nodes. There is also an example of overriding the default display traits of a VC.
Please provide feedback!
Further information:
- We mark every node as visible in the ASRangeController which NSIndexPath is returned from visibleNodeIndexPathsForRangeController:
- In visibleNodeIndexPathsForRangeController: we get the visible index path's via a call to UITableView's "indexPathsForVisibleRows" method.
- Unfortunately in this case we cannot use indexPathsForVisibleRows to get all the visible index paths as apparently in a grouped UITableView it would return index paths for cells that are just a bit over the edge of the visible area.
- But this edge cells will never get a call for -tableView:cellForRowAtIndexPath:, but we will mark them as visible in the range controller
- In tableView:cellForRowAtIndexPath: we call -configureContentView:forCellNode
- Because we never get a -configureContentView:forCellNode call for the edge cells, the _ASDisplayView of the nodes will never be added to the window and get a willMoveToWindow and didMoveToWindow call and it's never get's added to the window for now and so the node is NOT marked as "in the hirarchy"
- If the deallocation of the views are happening without the UITableView ever scrolled, the cells don't get a call to __exitHierarchy as they were never added to the window and stay in the interface state "visible" and an exception will be raised within the dealloc method of the ASDisplayNode
Grab a strong reference for asyncDataSource and asyncDelegate in ASCollectionView and ASTableView before executing the range update to be sure they are not going away while executing the range update. This can happen in range updates while going back in the view controller hierarchy
