Wait until all subnodes have the new trait collection before laying out the root node. The way I’m using `asyncTraitCollectionDidChange`, I sometimes call methods that call `setNeedsLayout` which causes a new layout pass to begin before the new trait collection has been propagated to all nodes. This leads to weird behavoir, like nodes being laid out twice in the same call stack!
This change won’t stop possibly unnecessary layout passes because of `asyncTraitCollectionDidChange`, but it will at least do a complete layout pass once we have propagated all traits.
Ultimately the solution to this problem (as Adlai pointed out) is to wait until the CA transaction commit to perform the actual layout.
Previously we were only propagating the trait collection on `viewWillTransitionToSize` since it is called shortly after `willTransitionToTraitCollection`. However, some important things can happen in that time “shortly after” (like collection view layout). As long as nothing changes from `willTransitionToTraitCollection` to `viewWillTransitionToSize` (which it shouldn’t) the traits will not be re-propagated anyhow.
Also make sure to use the `ASEnvironmentTraitCollectionMakeDefault` method when creating new envTraitCollection so the struct isn’t filled with junk.
* Revert "Revert "[ASLayoutSpec] Use childrenMap directly to prevent creating an NSArray within ASDK (#1937)""
This reverts commit 735b4ebd0872483044d98a5d05b43324e76fc8d4.
* Fix crash and add exception for mutating while using fast enumeration of ASLayoutSpec children
NSFastEnumeration is potentially quite dangerous in the wrong hands. In particular, it does not provide a safe mechanism for you to return temporary objects directly, and it does not provide any guarantee that you will be called when the enumeration has completed; therefore if we generate temporaries and store them in an instance variable, we will not necessarily be able to clean them up! This means fast enumeration methods should never be called within an autorelease pool or the autorelease pool be drained within the fast enumeration loop.
The reason is we store references to objects in the stackBuf struct by casting the child pointer to __autoreleasing id. If we pop the autorelease pool between calls to -countByEnumeratingWithState:objects:count:, it will die in a messy explosion of pointer dereferences and EXC_BAD_ACCESS.
* Add tests for ASDisplayNode and ASLayoutSpec fast enumeration
Something interesting going on here with ARC / Objective-C++ that we are investigating and will re-land.
This reverts commit c90ed08d1073701e2c7f8a2677d460c140f05264.
* Use childrenMap directly to prevent creating an NSArray in ASDK for ASLayoutSpec children
* Add locking for parent property in ASLayoutSpec
* Remove unnecessary import
* Add newline
* Add NSFastEnumeration to ASEnvironment and ASDisplayNode / ASLayoutSpec
* Change NSMutableArray initializer to arrayWithCapacity:
* Move ASLayoutSpec+Private.h into Private folder
Fixes building with Swift
* Remove lock for ASLayoutSpec parent
Summary:
The old assignment of `self.node.environmentTraitCollection.containerSize = windowSize;` doesn't because the struct creates a copy and then assigns `windowSize` to that copy.
Also realized that we need to create a new `ASEnvironmentTraitCollection` in `willTransitionToTraitCollection:withTransitionCoordinator`:. If we only update in `viewWillTransitionToSize:` we will only update the `containerSize` value in `self.environmentTraitCollection` as we don't have the new trait collection yet.
Differential Revision: https://phabricator.pinadmin.com/D101807
Passing around a pointer was leading to crashes as the ASVC was the sole owner of the context. There are cases where the VC would dealloc while its subnodes were laying out. This could lead to the subnodes accessing a garbage pointer.
* 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"
Summary: Don't set the new one in the subnodes yet as this will cause ASEnvironmentTraitCollectionIsEqualToASEnvironmentTraitCollection to return NO if only the displayContext changed.
Reviewers: garrett, levi, rmalik
Reviewed By: garrett, levi, rmalik
Subscribers: rmalik
Differential Revision: https://phabricator.pinadmin.com/D94320
* Fixed bug in `ASEnvironmentMergeObjectAndState`
* New ASLayoutSpec methods for `setChild`/`setChildren`/`setChild:forIdentifier:` have been added to take in a trait collection.
* Added `setChild:`-like methods for ASLayoutSpecs take a traitCollection
* Fixed instances where nodes in a data controller were not getting their trait collections
* propagate traitCollection in ASDisplayNode on insertSubnode or addSubnode
This reverts commit b34e8d78de20ea11b2b07a24df3b12d2936d1a5e.
In attempting to rebase my visibility patch, I overwrote all of Ricky's
changes to ASViewController. This puts them back in.
Summary:
This adds support for the concept of visibility depth.
Visibility essentially defines the number of user actions it would
take a user to have a view controller visible. Knowing a view controllers
visibility depth allows view controllers to take action such as clearing
out memory that can be restored at a later date.
This patch also add two new view controller subclasses which adopt
the ASManagesChildVisibilityDepth protocol. Any view controller
that has child view controllers can adopt this protocol to indicate
to the child what they're visibility is. For example, ASNavigationController
will return a visibility depth of it's own visibilityDepth + 1 for
a view controller that would be revealed by tapping the back button.
Move common implementations to macros
Turn off visibility logging
Differential Revision: https://phabricator.pinadmin.com/D90395
This adds support for the concept of visibility depth.
Visibility essentially defines the number of user actions it would
take a user to have a view controller visible. Knowing a view controllers
visibility depth allows view controllers to take action such as clearing
out memory that can be restored at a later date.
This patch also add two new view controller subclasses which adopt
the ASManagesChildVisibilityDepth protocol. Any view controller
that has child view controllers can adopt this protocol to indicate
to the child what they're visibility is. For example, ASNavigationController
will return a visibility depth of it's own visibilityDepth + 1 for
a view controller that would be revealed by tapping the back button.
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!
