You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #12, but this question is about UIKit’s configuration-based cell architecture rather than applying @QuickLayout directly to each cell subclass.
QuickLayout currently special-cases UITableViewCell and UICollectionViewCell so that a cell’s QuickLayout body is hosted in cell.contentView. With UIContentConfiguration, UIKit creates and manages a custom UIContentView. I could not find an example of this pattern and am unsure which object should own QuickLayout layout and sizing.
When a generic UITableViewCell or UICollectionViewCell receives a custom UIContentView, is applying @QuickLayout to that content view the supported approach?
Minimal example
structCardConfiguration:UIContentConfiguration{lettitle:String@MainActorfunc makeContentView()->anyUIView&UIContentView{CardContentView(configuration:self)}func updated(for state:anyUIConfigurationState)->Self{self}}@QuickLayoutfinalclassCardContentView:UIView,UIContentView{privatelettitleLabel=UILabel()privatevarmodel:CardConfigurationvarconfiguration:anyUIContentConfiguration{get{ model }set{guardlet configuration = newValue as?CardConfigurationelse{return}
model = configuration
titleLabel.text = configuration.title
setNeedsLayout()}}init(configuration:CardConfiguration){
model = configuration
super.init(frame:.zero)self.configuration = configuration
}@available(*, unavailable)requiredinit?(coder:NSCoder){fatalError()}varbody:Layout{HStack{
titleLabel
}.padding(.horizontal,16).padding(.vertical,8)}}
// The same configuration is assigned to either cell type:
cell.contentConfiguration =CardConfiguration(title: title)
Could you clarify:
Should @QuickLayout live only on the custom UIContentView, leaving the cell generic, or should the cell also adopt @QuickLayout?
When applying a configuration that changes the content size, is setNeedsLayout() sufficient? Should invalidateIntrinsicContentSize(), a cell-level invalidation call, or a QuickLayout-specific helper be used?
On iOS 16+, should supports(_:) be implemented so UIKit can reuse the existing content view?
Are there any differences in the recommended pattern for UITableViewCell and UICollectionViewCell?
An official example covering both cell types would be very helpful. Thanks!
Question
Related to #12, but this question is about UIKit’s configuration-based cell architecture rather than applying
@QuickLayoutdirectly to each cell subclass.QuickLayout currently special-cases
UITableViewCellandUICollectionViewCellso that a cell’s QuickLayout body is hosted incell.contentView. WithUIContentConfiguration, UIKit creates and manages a customUIContentView. I could not find an example of this pattern and am unsure which object should own QuickLayout layout and sizing.When a generic
UITableViewCellorUICollectionViewCellreceives a customUIContentView, is applying@QuickLayoutto that content view the supported approach?Minimal example
Could you clarify:
@QuickLayoutlive only on the customUIContentView, leaving the cell generic, or should the cell also adopt@QuickLayout?sizeThatFits(_:)on the content view sufficient, or is cell-level sizing customization still required as discussed in Avoid overriding preferredLayoutAttributesFitting in every auto-sizing UICollectionViewCell #12?setNeedsLayout()sufficient? ShouldinvalidateIntrinsicContentSize(), a cell-level invalidation call, or a QuickLayout-specific helper be used?supports(_:)be implemented so UIKit can reuse the existing content view?UITableViewCellandUICollectionViewCell?An official example covering both cell types would be very helpful. Thanks!
Environment
mainat38020f2