Fix target content offset edge case #115
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Details
This fixes an issue that could cause the target content offset to be computed with incorrect layout metrics (bounds / content size / content insets) when the collection view is first appearing. This can happen if there are some forced layout passes due to navigation bars being sized, for example.
The general issue is that
prepareForAnimatedBoundsChange
is called with anoldBounds
value, but we have no idea what the content inset / content size of the collection view was when that was our current bounds. If we use updated content inset / content size values, but with the previous bounds value, then we'll compute an incorrect target content offset. To make matters worse, there's no exact order of layout lifecycle calls that we can depend on to save our previous inset / bounds. To work around this, we need to store a few bounds + content inset + content size states, which we can later reference inprepareForAnimatedBoundsChange
so that we can use the right values.Previously, we just stored the last values seen in
invalidateLayout
, rather than the last 3. This isn't good enough, sinceinvalidateLayout
will be called many times with differing values, but the values that we actually have access to inprepareForAnimatedBoundsChange
might need to be from a few invalidations in the past. What a pain.Related Issue
N/A
Motivation and Context
Fix internal Airbnb issue
How Has This Been Tested
Example app, Airbnb app
Types of changes
Checklist