* WIP
* Calculate TextKit Height based on max lines to display
* Remove TODO
* Calculate height based on lineFragmentRect
* Fixes issue with calculated width
* Resolve TextKit stack threading issues
* Removes blank lines
* Open brace on next line
* setNeedsLayout in case of changes on live node
This updates the values automatically, which is perfect to reflect the growth of ASDK. I've wanted to do this for ages but the shield.io API didn't have the support up till now. We lose some granularity but I think this is worth it.
* added accessoryType to ASCellNode
* Moved the passthrough properties in an own section in ASEditableTextNode
* added documentation and reverted ASEditableCellNode changes
* fixed code signing
* adding seperatorInset property as a passthrough property
* revert changes to project file
* moved setting properties to setNode:
* moved clipsToBounds to setNode
- When a video node is first visible, it's player is called to play if auto play flag is on. However, the player might not be ready by that time, especially when the video is loaded on a slow network. The player just continues loading its asset.
- When the player is ready, we should check if it is expected to be playing and if true, try to play again.
* Don't lock while calling downloader
Addresses #2785
To avoid performance issues, we should avoid locking the downloader.
To achieve this we need to do some kinda gross things. Essentially
the cost is the code is more complex and potentially far less performant
in edge cases. In testing, edge cases are nearly never hit, but I'm not
sure how good I feel about the cost in code complexity. This exacerbates
the locking issues in ASNetworkImageNode:
1. There is no convention for which methods lock.
2. There's no indication which vars are only set on init and therefore
safe to access except in the class extension definition.
* Shouldn't have checked in product changes.
* Using ivar instead of local var copied within lock.
* ASDataController: Correctly handle fetching node at nil index path (return nil).
* Be more aggressive, in order to avoid needlessly waiting for updates to complete
* Test that the initial range bounds are what we expect
* Use the user's previous scroll direction in the range controller
* Remove flow layout assertion
* full screen button for ASVideoPlayerNode
* fixed a small issue when disabling controlsDisabled is set
* styling fixed
* make videoNode public on ASVidePlayerNode
* [ASVideoPlayerNode] fixed an issue when re-enabling the controls the duration time label didn't updated correctly
* [ASVideoPlayerNode] Check if CMTime is valid before setting the labels
* Improve visibility handling for range-managed nodes
* Tweak ASWeakSet & the test
* Put back a few things that are pending a different diff
* Add a test
* Ensure we update visible nodes, even if there are no new ones
* Implement mutex ownership and use it to check potential upward lock gathering
* Don't hold instance lock and call willEnterHierarchy/didExitHierarchy of ASDisplayNode
- This can cause deadlocks (e.g #2605) if subsequent methods, that are implemented by developers, walk up the node tree.
- This is a way to keep the optimizations introduced in 9e87813 while making sure the locking situation is a bit safer.
* More lock ownership assertions in ASDisplayNode
* Document main thread contract of -clearContents
* ASNetworkImageNode shoud not call setNeedsPreload while holding instance lock
- This helps to avoid potentially deadlocks caused if the node (esp in case it's a subclass of ASNetworkImageNode) walks up the tree in didEnterPreloadState, for example to build logging context.
* ASVideoNode should not call setNeedsPreload while holding instance lock
- This helps to avoid potentially deadlocks caused if the node (esp. if it's a subclass of ASVideoNode) walks up the tree in didEnterPreloadState, for example to build logging context.
* Don't hold instance lock for the entire insert subnode operation
- The recursive lock should not be held throughout `_insertSubnode:atSubnodeIndex:sublayerIndex:andRemoveSubnode:`. The method instead should manage the lock itself and acquire it as shortly as possible. The reason is that this method calls many methods outside the scope of `self`. `[subnode __setSupernode:self]` is especially troublesome because it causes the subnode to migrate to new hierarchy and interface states, which triggers `didEnter/Exit(.*)State` methods. These methods are meant to be overriden by subclasses. Thus they might walk up the node tree and potentially cause deadlocks, or they perform expensive tasks and cause the lock to be held for too long.
- Other methods that call this method should release the lock before doing so.
* Lock getter and setter of `synchronous` flag
* Address comment in ASVideoNode
* Add main thread assertions to methods that change asset and assetURL of ASVideoNode
* Explain CHECK_LOCKING_SAFETY flag
* More thread and locking assertions in ASVideNode
- It's not safe to call `-[subnode __setSupernode:self]` while holding instance lock of soon-to-be supernode (e.g `self`).
- It's also not safe to call `[subnode __setSupernode:nil]` while holding the instance lock of the old supernode (e.g `self`).
- did(Enter|Exit)(.*)State methods are always called on main. Add main thread assertions to indicate that.
* Minor change in explanation of CHECK_LOCKING_SAFETY flag
