Post not yet marked as solved
Hi,
One of my views uses a CAShapeLayer to provide a line-dash. To date, I've been using the following technique to capture if there is an animation in progress in the layer's containing view and apply it to the layer also:
override func layoutSubviews() {
		let layerBoundsSizeAnimation = layer.animation(forKey: "bounds.size")
		CATransaction.begin()
		if let layerBoundsSizeAnimation = layerBoundsSizeAnimation {
				CATransaction.setAnimationDuration(
						layerBoundsSizeAnimation.duration)
				CATransaction.setAnimationTimingFunction(
						layerBoundsSizeAnimation.timingFunction)
let pathAnimation = CABasicAnimation(keyPath: "path")
borderLayer.add(pathAnimation, forKey: "path")
} else {
CATransaction.setDisableActions(true)
}
borderLayer.path = CGPath(rect: bounds, transform: nil)
CATransaction.commit()
}
This works well for non-interactive animations.
However, when I try to perform an interactive animation (i.e pausing a UIViewPropertyAnimator and adjusting its fractionComplete property) the layer animation fails to pause and simply continues to its end position.
Is there a simple way to setup a view's layer hierarchy to support the interactive animation of its sublayers?
Post not yet marked as solved
I'm using a UIPanGestureRecognizer and wish to prevent the start of the gesture unless the angle of the pan falls within a certain range.
To do this, I'm implementing the gestureRecognizerShouldBegin(_:) method in the recognizer's delegate and computing the angle based on the gesture velocity.
However, with relative frequency, I'm noticing that this method is called with a velocity/translation of zero (requested via velocity(in:) and translation(in:) respectively). This is occurring with pronounced gestures that you would intuitively expect to be non-zero.
Is it expected that gestureRecognizerShouldBegin(_:) will be called by a pan gesture recognizer with a zero velocity/translation?
When using a custom UICollectionViewLayout that makes use of self-sizing cells, it isn't clear to me how to influence the fitting priority sent to the cell's content view via systemLayoutSizeFitting(_:withHorizontalFittingPriority:verticalFittingPriority:) as part of UICollectionViewCell's default implementation of preferredLayoutAttributesFitting(_:).
For example, take a simple self-sizing cell with a basic UIContentView conforming content view that pins a UILabel to each edge using auto-layout:
If I use this cell with a stock list layout (i.e. UICollectionViewCompositionalLayout.list(using: .init(.plain)) ), I can see that when the collection view is laid out, each cell's content view has its systemLayoutSizeFitting(_:withHorizontalFittingPriority:verticalFittingPriority:) method called with the horizontal fitting priority set to .required/1000.
However, when using a custom layout, the fitting priority remains at .fitting/50.
How does UICollectionViewCompositionalLayout achieve this considering the cell is using its default implementation of preferredLayoutAttributesFitting(_:)? Is there a way of specifying the fitting priority from within a layout?
I'm creating some self-sizing cells that should dynamically size their height based on the length of text set in a UILabel with the new content view configuration mechanism in iOS 14.
Previously, I've had success setting the value of a label's preferredMaxLayoutWidth property within a cell's layoutSubviews() method.
However, it seems when a UICollectionViewCell uses the new content view configuration mechanism, this isn't called during the self-sizing pass, therefore I've been placing the call within an overridden systemLayoutSizeFitting(_:withHorizontalFittingPriority:verticalFittingPriority:)
method:
override func systemLayoutSizeFitting(
		_ targetSize: CGSize,
		withHorizontalFittingPriority horizontalFittingPriority: UILayoutPriority,
		verticalFittingPriority: UILayoutPriority
) -> CGSize {
let layoutMarginsFrame = bounds.inset(by: layoutMargins)
debugLabel.preferredMaxLayoutWidth = layoutMarginsFrame.width
return super.systemLayoutSizeFitting(
targetSize,
						withHorizontalFittingPriority: horizontalFittingPriority,
						verticalFittingPriority: verticalFittingPriority)
}
Is this the recommended location to set this property with self-sizing content views in iOS 14?
Post not yet marked as solved
I’ve been struggling to understand UICollectionViewLayout.
Specifically, I want to create layouts that handle self-sizing cells, seamless rotation animations, insertion/deletion animations, etc.
Whilst the examples and sample code provided at https://developer.apple.com/documentation/uikit/views_and_controls/collection_views/layouts/customizing_collection_view_layouts are a good start they omit key functionality for more involved layouts – namely the combination of self-sizing and rotation, insertion/deletion animations.
I’ve spent quite a bit of time now trying to understand how to create a layout that both self-sizes cells and supports rotation animations. I’ve discovered quite a few things that are undocumented with a collection view layout; for example, that a multi-pass layout phase commences and initialLayoutAttributes needs to match the last value returned by layoutAttributesForElements(in:) or layoutAttributesForItem(at:) to ensure a seamless cell animation.
But other things elude me, like how to ensure initialLayoutAttributesForAppearingItem(at:) is called for all the cells it should be. Without the expected call during a rotation transition a cell may appear at its final dimensions rather than animating smoothly from the dimensions that would be appropriate for the old bounds.
In an attempt to understand the behaviour of a UICollectionViewLayout more deeply, I've sub-classed Apple’s own compositional and flow layouts to when the public methods of UICollectionViewLayout are called and what they return. But it seems that most of UICollectionViewLayout's public methods aren’t called (only layoutAttributesForElements(in:)) which makes it really tough to try and understand and replicate the desired behaviour.
Are there any more resources to *really* understand how this key component works so that we as developers can create the same calibre of seamless transitions and layouts that Apple can?
(Documentation enhancement request FB8608656)
I'm creating a custom sub-class of UICollectionViewCell and would like to use the new configuration APIs but am confused about how to avoid a new content view being created each time the contentConfiguration property is set.
The documentation for UICollectionViewCell's contentConfiguration property states:
Setting a content configuration replaces the existing contentView of the cell with a new content view instance from the configuration, or directly applies the configuration to the existing content view if the configuration is compatible with the existing content view type. It's this second part that interests me, how can we apply a configuration directly to an existing content view in a custom cell?
Without this ability exposed, it seems we're left with an expensive call to UIContentConfiguration's makeContentView() each time we update the content configuration.
Tricky.