[ASCollectionView] Consistency issue when changing number / layout of supplementary nodes

[bsmith11]

I have an ASCollectionView that displays a grid of items. I am using supplementary nodes as item separators as shown in the following screenshot.

I am using a custom UICollectionViewLayout that also serves as the .layoutInspector object via ASCollectionViewLayoutInspecting. I'm getting some crashes when, after the collection view has already loaded and completed layout, I add more items which causes my layout to generate more supplementary nodes (a new column has been created, so an additional separator needs to be created as well). The crash is telling me that Supplementary node should exist., which I assume means that the layoutInspector didn't know that a supplementary node was supposed to be created, so an additional one wasn't.

After some digging, it looks like public func collectionView(collectionView: ASCollectionView!, supplementaryNodesOfKind kind: String!, inSection section: UInt) -> UInt is not getting called again after I make updates to the collection view (via performBatchUpdates). It looks like it needs to be getting called in - (void)willReloadData of the ASCollectionDataController, but it isn't.

Am I using all of these components correctly? Is my implementation possible?

[appleguy]

@bsmith11 happy to help.

• What version of the framework are you using? Please try again with 1.9.7 which has many improvements.
• Is it possible to share sample code, or your actual code, even privately to asyncdisplaykit@gmail.com? I would be able to help debug this weekend if you send it by Sunday morning.
• Please provide a full backtrace of when the crash happens.

As a worst-case workaround, you can add separators to the cells themselves. I have some tips on how you can do this easily if it gets to that point, but first would like to fix the supplementary nodes for you. At this stage I can't tell if it is your app code or the framework.

[bsmith11]

@appleguy

I'm using 1.9.7.

I've created a simple test project that demonstrates the same crash:
ADKTest.zip

Removing items from the collectionView works fine, but as soon as I add more items than the initial count, it crashes with the same message.

Thanks for the quick response

[smyrgl]

It seems like this might be related to this issue: #1322

[erichoracek]

I am experiencing this issue as well. As far as I can tell, this is due to a misconception within the implementation of ASCollectionView/ASCollectionDataController with respect to the behavior of collection supplementary views. From my experience, it is valid to have a dynamic number of supplementary views within a section. ASCollectionView does not accommodate this behavior, which explains the above crash.

Within ASCollectionView, there is an assumption that there will always be a static number of supplementary views per section—even when additional items are added or removed from that section. This is evidenced by the fact that when you invoke -[ASCollectionView insertItemsAtIndexPaths:], the data source method -[ASCollectionDataSource collectionView:nodeForSupplementaryElementOfKind:atIndexPath:] is not invoked, preventing consumers from specifying a new number of supplementary nodes for the new set of items.

From digging around a bit, this appears to be due to the logic (or lack thereof) within ASCollectionDataController regarding supplementary node management. The only methods that have a side-effect of recalculating the set of supplementary nodes for a section are prepareForReloadData, prepareForInsertSections:, and prepareForReloadSections:, via the _populateSupplementaryNodesOfKind:... methods.

It would seem that when there are a dynamic number of supplementary nodes per section, the set of supplementary nodes for a section would needs to be recalculated not only on section-level mutations, but also on item-level mutations as well. It doesn't appear that that there are item-level counterparts to the section-level -prepareFor.. subclassing hooks in ASDataController+Subclasses.h that would make this possible. However, something along those lines seems like the right direction.

Hope this helps to narrow down this issue—thanks!