Do not explicitly set the constraints for refreshControl #202
+0
−10
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.
Today, the refresh control is installed with layout constraints explicitly set. The explicitly set layout constraints has no visible effect vs. just not setting them, but setting them does cause imcompatibility with any custom
consetInsets
of the scroll view.If for example a
VisitableView
is shown in an app with a translucent navigation bar, the refresh control will - with explicit layout constraints - be positioned under the tranlucent navigation bar, even if the scroll view has it'scontentInset
configured to correspond to the navigation bar height.Since the
installRefreshControl
method is marked as private, it's not possible to easily skip adding the layout constraints today to make the refresh control compatible with custom content insets.This PR removes the explicit layout constraints.
In the demo app, there's no visible difference between setting them explicitly and not setting them and the existing behavior. This is a video of the demo app with this PR applied:
Simulator.Screen.Recording.-.iPhone.15.Pro.-.2024-04-22.at.09.22.06.mp4