13

I'm using UICollectionView with self sizing cells and have set the estimatedItemSize property for this to work.

When performing a delete animation however, the cells animate to their position if they were sized with the estimatedItemSize property, rather than their auto layout (actual) size.

What's worse is that our cells are variable sizes and there doesn't seem to be a method like UITableView where we can pass an estimated size per index path.

I attempted to subclass the collection view flow layout and override the initialLayoutAttributesForAppearingItemAtIndexPath(_:) and finalLayoutAttributesForDisappearingItemAtIndexPath(_:), but on inspection the superclass's return values for these methods are correct.

Does anyone know of a solution to this seemingly basic bug?

Adam Carter
  • 4,741
  • 5
  • 42
  • 103
  • Hi Adam, i found too that animations always fallback to the estimated size, which makes for some "interesting" animations. I also have the problem that a static estimated Size is not precise enough. Did you find something to improve this. – Peter Schumacher Sep 07 '16 at 08:18
  • Sadly not. We went back to using a UITableView which seems backwards but is the only solution so far (that I know of anyway) – Adam Carter Sep 11 '16 at 22:14
  • I am now calculation the sizes myself. UIView's systemLayoutSizeFittingSize: is very helpful with that. – Peter Schumacher Sep 13 '16 at 09:39
  • 1
    Had the same problem but after insertion. For some reason, UICollectionViewFlowLayout forgot about autolayouted sizes and applied estimatedItemSize for already visible cells.Which led to terrible animation jumps. Managed to solve it with custom UICollectionViewLayout which remembers attributes and update their sizes on -invalidationContextForPreferredLayoutAttributes:withOriginalAttributes:. – Alexey Mar 26 '17 at 19:50
  • @Alexey Interesting suggestion, but could you help out a bit, please? I tried following your advice, but the jumps still happen (all existing cells disappear before appearing again). In `invalidationContext(forPreferredLayoutAttributes:withOriginalAttributes)` I save the `preferredLayoutAttributes`, then in `layoutAttributesForItem` I return them, if they exist, or save them again if their `size != estimatedSize` (meaning they were calculated - I thought). – Roland Nov 29 '17 at 17:21
  • @Roland we ended up with using this solution: https://github.com/adamwaite/SelfSizingWaterfallCollectionViewLayout it worked without our changes. Can you try it out? This layout does what I wrote above but with headers and footers support. I hope it will help – Alexey Nov 30 '17 at 08:34
  • Hey @Alexey, thanks for your help! Sadly it enters a loop inside `prepareLayout` and I haven't been able to find the problem. I can't really replicate the logic either :( I'll keep the project around, maybe I'll eventually better understand it, and I'll be able to reproduce it. – Roland Nov 30 '17 at 21:10
  • @Roland you need to be sure that what you return in preferredLayoutAttributesFitting of a cell is the same what you return in this custom layout, as I know by default it has 2 columns, try to set 1 – Alexey Dec 01 '17 at 11:31
  • @Alexey Thanks for your continued input, but I couldn't make it work :( Tried with 1 column, setting the cell size, or trying to replicate its functionality. Among other things, I also tried to subclass a `flowLayout`, override its `collectionViewContentSize` and return a "correct" size (the one right before deletion/insert), but it still jumps/doesn't properly reload new items. Guess I'll open an ATS, hopefully they can help. Will provide some info if I manage to solve this, but since there are at least 3 bug reports for this, one dating since iOS 8 ... I don't have much confidence :( – Roland Dec 02 '17 at 16:14
  • hey, I'm also stuck here, do we have any update? or should we just need to use tableView in this case? – boog May 22 '18 at 05:29

0 Answers0