Observe layout guides

[frederoni]

Fixes #6954

This PR adds observers to the top and bottom layout guides if necessary in order to re-layout after changes have occurred. (i.e due to showing/hiding a navigation bar)

It also replaces constraints with manual layout to avoid manipulating the view controller's view which is the developer's responsibility.

[mention-bot]

@frederoni, thanks for your PR! By analyzing this pull request, we identified @1ec5, @incanus and @boundsj to be potential reviewers.

[frederoni]

Comparing against the private class _UILayoutGuide is not particularly future proof.

[1ec5]

Instead of checking the object's class, pass in a context when adding the observer so you can check the context here.

[1ec5]

Nit: we don't expect to ever make this property public, so it can be an ivar.

[1ec5]

Would it work to observe viewController's topLayoutGuide.bounds key path instead?

[1ec5]

Instead of checking the object's class, pass in a context when adding the observer so you can check the context here.

[1ec5]

This works, but the more common practice is to pass in a selector such as _cmd.

[1ec5]

Er, I may be mistaken about _cmd. But in any case, the important thing is to ensure that the context’s value is unique. If we later add a key-value observer with a different constant set to 1, suddenly there’s an opportunity for crosstalk.

A simple fix is to set the context equal to its own address.

[1ec5]

Is topLayoutGuide really a UIView? I'd expect it to be a UILayoutGuide.

[1ec5]

Postponing to v3.4.1, per #6954 (comment).

[1ec5]

Since this PR is scheduled for iOS SDK v3.5.0, it needs to be rebased and retargeted at the release-ios-v3.5.0-android-v5.0.0 branch.

[frederoni]

• Rebased and retargeted against the 3.6 release branch.
• Fixed layout for the recently added scale bar.

@boundsj @fabian-guerra 👀

[1ec5]

The underlapping bug is significant enough that we should mention this fix in the changelog.

[1ec5]

This is OK, but just a stylistic tip: x and y variables that get repurposed multiple times carry the risk that we might fail to update one of these variables and its previous value may “bleed” into a subsequent use of it.

Instead, I sometimes take advantage of the struct initializer syntax to keep the values scoped to where they’re used. For example:

self.compassView.center = {
    CGRectGetWidth(self.bounds) - CGRectGetMidX(self.compassView.bounds) - self.contentInset.right - 5,
    CGRectGetMidY(self.compassView.bounds) + self.contentInset.top + 5,
};

If you’re concerned about accidentally swapping x and y, you can also use the C99 designated initializer syntax:

self.compassView.center = {
    .x = CGRectGetWidth(self.bounds) - CGRectGetMidX(self.compassView.bounds) - self.contentInset.right - 5,
    .y = CGRectGetMidY(self.compassView.bounds) + self.contentInset.top + 5,
};