`

UILabel自动换行适应

阅读更多
一般有两种类型的collection view布局:

1.独立于内容的布局计算。这正是你所知道的像UITableView和UICollectionViewFlowLayout这些情况。每个cell的位置和外观不是基于其显示的内容,但所有cell的显示顺序是基于内容的顺序。可以把默认的flow layout做为例子。每个cell都基于前一个cell放置(或者如果没有足够的空间,则从下一行开始)。布局对象不必访问实际数据来计算布局。

2.基于内容的布局计算。我们的日历视图正是这样类型的例子。为了计算显示事件的起始和结束时间,布局对象需要直接访问collection view的数据源。在很多情况下,布局对象不仅需要取出当前可见cell的数据,还需要从所有记录中取出一些决定当前哪些cell可见的数据。

在我们的日历示例中,布局对象如果访问某一个矩形内cells的属性,那就必须迭代数据源提供的所有事件来决定哪些位于要求的时间窗口中。 与一些相对简单,数据源独立计算的flow layout比起来,这足够计算出cell在一个矩形内的index paths了(假设网格中所有cells的大小都一样)。

如果有一个依赖内容的布局,那就是暗示你需要写自定义的布局类了,同时不能使用自定义的UICollectionViewFlowLayout。所以这正是我们需要做的事情。\
当collection view的宽度改变时,我们自定义的布局必须被丢弃,但这滚动并不会影响到布局。幸运的是,collection view将它的新bounds传给shouldInvalidateLayoutForBoundsChange: method。这样我们便能比较视图当前的bounds和新的bounds来确定返回值:
- (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds
 
{
 
CGRect oldBounds = self.collectionView.bounds;
 
if (CGRectGetWidth(newBounds) != CGRectGetWidth(oldBounds)) {
 
return YES;
 
}
 
return NO;
 
}
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics