Bk/fix initial attributes target content offset

[bryankeller]

Details

This PR fixes 1 issue (can't find a fix for the other, sadly):

1. In certain cases, the initial layout attributes of an inserting item would be in the wrong spot. This would happen when the target content offset adjustment was changing the position that the newly inserted item would appear at. We need to compensate for this.

Before:

p1before.mp4

After:

p1after.mp4

---

2. [Not fixed, seems like a collection view bug where it skips trying to animate an item since it's end position is off screen] There's an off edge case with collection view that causes a moved item to render instantly at its final position, rather than smoothly sliding over. It's related to self-sizing cells (doesn't happen for statically sized items). All returned layout attributes look correct, so I don't think it's MagazineLayout's fault. It happens when the inserted item / moved item is close to the the top of the screen, which makes me think internally, UICollectionView thinks the moving item isn't visible, and therefore short-circuits its rendering. Interestingly, reducing the estimated item height from 150 -> 10 fixes it. 150 was a magic number, and 10 is too, but I think using a smaller number makes it less likely for collection view to hit this issue.

Before:

p2before.mp4

Related Issue

N/A

Motivation and Context

Bug fixes

How Has This Been Tested

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[bryankeller]

I need to do some testing to make sure this doesn't break anything in the Airbnb app

[brynbodayle]

Hmm, not sure about this. I think a lower estimated height could be mean more cells are initially loaded, it's a less accurate estimation. So we could be receiving worse performance to address the animation edge case.

Does the issue only occur if the estimated height puts the original layout attributes frame intersecting the top of the collection view?

[bryankeller]

Those are good points - I'll do some more investigation

[brynbodayle]

See we still use this constant elsewhere, should we change the constant value instead? A bit confused on when we want this smaller height versus not.

[bryankeller]

I realized we were using this default item height for not just the estimated height, but also the default static height if someone doesn't implement sizeModeForItemAt. Didn't want to cause a regression in that case.