UICollectionViewFlowLayout subclass crashes accessing array beyond bounds while scrolling and reloading

Edit 2, as per 2nd BenRB's comment.

When dataSource gets updated and you call reloadData, this latter really invalidates everything in the collection view. However the logic and the exact sequence of the initiated refresh process happens inside the default flow layout and is hidden from us.

In particular, the default flow layout has its own private _prepareLayout (exactly, with underscore) method, which is independent from the prepareLayout and its overloads provided by the subclasses.

prepareLayout's (without underscore) default implementation of the base flow layout class does nothing, by the way.

During the refresh process the default flow layout gives its subclass a chance to provide more information (e.g. additional layoutAttributes) through layoutAttributesForElementsInRect: and layoutAttributesForItemAtIndexPath: "callbacks". To guarantee the consistency between base class' data and respective indexPath / layoutAttributes array, calls to corresponding "super" should only happen inside these respective methods:

• [super layoutAttributesForElementsInRect:] only inside the overloaded [layoutAttributesForElementsInRect:]

• [super layoutAttributesForItemAtIndexPath:] only inside the overloaded [layoutAttributesForItemAtIndexPath:],

No cross-calls between these methods should happen, at least with indexPaths not supplied by their corresponding "super" methods, because we don't know exactly what happens inside.

I was fighting with my collection view for a long time and ended with the only working sequence finally:

1. Prepare add'l layout data by directly accessing the dataSource (without mediation of collection view's numberOfItemsInSection:), and store that data inside the subclass' object, e.g. in a dictionary property, using indexPath as a key. I am doing this in the overloaded [prepareLayout].

2. Supply the stored layout data to the base class when it requests this information through callbacks:

// layoutAttributesForElementsInRect

- (NSArray *)layoutAttributesForElementsInRect:(CGRect)rect {

//calls super to get the array of layoutAttributes initialised by the base class
**NSArray *array = [super layoutAttributesForElementsInRect:rect];**

for(MyLayoutAttributes *la in array)

    if(la.representedElementCategory == UICollectionElementCategoryCell ){
       NSIndexPath indexPath =  la.indexPath //only this indexPath can be used during the call to layoutAttributesForItemAtIndexPath:!!! 
       //extracts custom layout data from a layouts dictionary
       MyLayoutAttributes *cellLayout = layouts[la.indexPath];  
       //sets additional properties
        la.this = cellLayout.this
        la.that = cellLayout.that
        ...
    }
   ....
return array;
}

//layoutAttributesForItemAtIndexPath:

- (UICollectionViewLayoutAttributes *)layoutAttributesForItemAtIndexPath:(NSIndexPath *)indexPath {

  MyLayoutAttributes *la = (MyLayoutAttributes *)[super layoutAttributesForItemAtIndexPath:indexPath ];

    if(la.representedElementCategory == UICollectionElementCategoryCell ){
        NSIndexPath indexPath =  la.indexPath //only this indexPath can be used during the call !!! 
       //extracts custom layout data from a layouts dictionary using indexPath as a key
       MyLayoutAttributes *cellLayout = layouts[la.indexPath];  
       //sets additional properties
        la.this = cellLayout.this
        la.that = cellLayout.that
    }
return la;
}

I'm now getting a crash that looks similar, i.e. where the layout is out of sync with the data source. This one I can reproduce and I believe I've found the cause. Since it is similar, I'm wondering if it is the same cause as my original crash/question. The error is:

UICollectionView recieved [sic] layout attributes for a cell with an index path that does not exist

My UICollectionViewFlowLayout subclass implements shouldInvalidateLayoutForBoundsChange: (so that I can position section headers at the top of the viewable bounds as the user scrolls). If a bounds change occurs and that method returns YES, the system requests a light-weight layout invalidation, i.e. all the properties on the invalidation context that is passed to the layout are NO: invalidateEverything, invalidateDataSourceCounts, invalidateFlowLayoutAttributes and invalidateFlowLayoutDelegateMetrics. If reloadData is then called afterwards (presumably before the layout has been reprocessed) then the system will not automatically call invalidateLayout, i.e. it will not trigger a heavy-weight invalidation context where all those properties are YES. So when that happens the layout apparently does not update its internal cache of section/item counts and such, which the leads to the layout being out of sync with the data source and a crash.

So for the particular situation I just ran into, I was able to work around it by simply calling invalidateLayout myself after calling reloadData. I'm not sure if this is the same situation as my original question/crash but it sure sounds like it.