* [ASDisplayNode layout] Fix an issue that causes a node's pending layout to not be applied
- Since the implementation of layout version (#428), if a node's pending and calculated layouts have the same current version as well as the same constrained size, the 2 layouts are considered equal and can be used interchangeably. A layout version check between the 2 layouts was added in #695. This PR adds a missing constrained size check.
- If the pending layout has the same version but a different constrained size compare to the calculated layout's, we can assume that the pending layout is newer and should be preferred over the calculated one. That is because layout operations always register their new layout as pending, which then (immediately or eventually) get applied to the node as calculated layout.
- Failing to do so will introduce race conditions in which the property was updated on a background thread but main thread has not executed the block that updates the property of the node's layer. During that window, the layer's property is out-of-date and can't be used.
- After this change, ASDisplayNode's cornerRadius is the only source of truth and users must always use it instead of CALayer's.
This reverts commit 2e98588372 (#751).
The reason we can't wait for the coming CA's layout pass is that cell node visibility events occur before the pass, at which time the cell's subnodes don't have correct frames for impression tracking.
The root cause of this problem is that, right now, cell node visible states are set by ASRangeController well before the layout pass of the hosting collection/table view. That means we're "jumping the gun". The more I think about this, the more I agree with @Adlai-Holler that we need to treat visible state differently. That is, a node should only be visible (and thus get visibility events) after it's fully loaded, it's view/layer attached to the hierarchy and laid out by a CA transaction. In other words, at the end of the CA layout pass. Such change needs time and effort to be thoroughly reviewed and tested. Until then, let's roll with this fix.
* Fixed breaking issue where completeBatchFetching is called on a background thread when no items are added to the collection
* Changed spaces to tabs for consistency
* Moved return statement for Code Review feedback
* Fixed the same issue in the Objective-C version of ASDKgram
* One more
* Update PhotoFeedModel.m
Fix header
* Fix capturing self in the block while loading image in ASNetworkImageNode
* Restore re-strongify while switching on the main thread
* Update CHANGELOG.md
* Add support for piping arbitrary user info from ASImageDownloader to the ASNetworkImageNodeDelegate
* s/source/sourceType
* Fix stuff and take Michael's advice
* Faster collection operations
* Fix a few things
* Put the stupid semicolon
* Address warning
* Cut down retain/releases during collection operations
* Update CHANGELOG.md
- After #706, a layout pass is forced on an ASM-enabled node that enters preload state to make sure that its subnodes can start preloading as well. However, when the node is visible, a (coalesced, thus more efficient) layout pass will be triggered by CA soon anyways, so rely on it instead.
* [ASTraitCollection] Add missing properties to ASTraitCollection
* ASTraitCollection now completely reflects UITraitCollection
* Add ASContentSizeCategory enum that corresponds to
UIContentSizeCategory and can be used inside a struct.
* * Remove enum ASContentSizeCategory.
* Use __unsafe_unretained UIContentSizeCategory instead of the enum.
* Added ASPrimitiveTraitCollection lifetime test
* Changes requested at code review:
* Restore one of the ASTraitCollection constructors with a deprecation notice.
* Clean up API by the separation of tvOS-specific interfaces.
* Use [NSString -isEqualToString:] for ASPrimitiveContentSizeCategory equality tests for better readability.
* Encapsulate fallback logic for UIContentSizeCategoryUnspecified.
* Fix failing test
* Add "ASGraphicsContext" to skip copying our rendered images
* Zero the buffer before making a context
* Update license header
* Update dangerfile
* Make it a runtime flag
* Restore GState for good measure
* Free buffer if end without image
* Enable the experiment, and cut out the middle-man
* Fix typo
* Add support for interactive moves
* Enable drag & drop in collection view example
* Update changelog
* Change the gating logic to match UIKit
* Add a warning when we prevent interactive movement due to async layout
* Reimplement ASRectTable using unordered_map to avoid obscure NSMapTable exception.
The new class is called ASRectMap, which patterns alongside ASIntegerMap in both name and implementation.
After some pretty detailed investigation, including study of open-source reimplementations
of Foundation, the best lead I've found on the NSMapTable exception is that
some NSPointerFunction types are not fully supported. Strangely, the ones being used
do seem to work fine almost all of the time.
The main concern is the Struct memory type, which is not officially re-declared in
NSMapTable, and as such the documentation claims that there may exist some
combinations of NSPointerFunction that are not supported.
Because the exception is occurring frequently enough to be a concern (in the hundreds
to low thousands, though only 50 a day) - I decided to replace NSMapTable entirely
in order to ensure full correctness.
"*** -[NSMapTable initWithKeyPointerFunctions:valuePointerFunctions:capacity:] Requested configuration not supported."
* Fix Xcode project
- Fix an insta-crash that's caused by Webservice.load method to call its completion block off the main thread.
- Fix incorrect http status code check.
- Bump the deployment target to get the project compiling.
