[google_maps_flutter] Set properties before adding maps objects

[stuartmorgan-g]

It appears that the Google Maps SDK on iOS renders on a different thread, and doesn't necessarily batch all updates that happen in a runloop the way standard iOS UI would, so that adding an object to the map before setting all of its properties can cause a flicker of the default property.

This ensures that updating the native maps object from the Dart version sets all properties before adding the object to the map, and refactors to make unit testing the update helper simpler (and in one case, to fix an init-calls-self violation).

Fixes flutter/flutter#143570

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[gemini-code-assist]

Code Review

This pull request refactors the update logic for various map objects on iOS to fix a potential flickering issue. The changes ensure all properties of an object are set before it's added to the map, preventing a flicker of default values. This is achieved by introducing static helper methods for each map object type (markers, circles, polygons, etc.) that apply all properties first and then set the map property to make the object visible. This refactoring also resolves some init methods that were incorrectly calling instance methods. The changes are consistently applied across all relevant controllers and are well-supported by new unit tests that verify the correct property update order.

[stuartmorgan-g]

This isn't actually deleted, I just renamed it (Polylines->Polyline) for consistency, and since I also add a lot of lines, git didn't see it as a rename.

[stuartmorgan-g]

We could extract this as a convenience constructor, but it was simple enough that I just copied it from the tests that already did it into each other test file.

[stuartmorgan-g]

I considered doing something sketchy with overriding core Obj-C selector handling methods to catch all property setters at once, instead of having boilerplate like this for every map object, but since that would have had to be rewritten to something like this to convert the tests to Swift I decided doing this was the better option.

[stuartmorgan-g]

I did this refactoring in all of the object files: every object had a bunch of these passthroughs, almost all of which were a single line, and they are all private and only called by the updateFrom* method, so it seemed like a lot of boilerplate for nothing, and it also prevented me from making the update method a class method. It's not necessary to fix the issue, but it makes the test setup much simpler.

[stuartmorgan-g]

This is the other part of the refactoring I made in every object. Having the class method helps with testing because I can expose this and not need to make a full controller (which for some objects has side effects on the map, which we aren't fully mocking, and it can get complicated). We also had a case where the controller's init* method called updateFrom*, which violates style, and making the class method allowed trivially fixing that.

[stuartmorgan-g]

This is the actual fix; about half the objects were setting visibility somewhere other than the end.

[stuartmorgan-g]

Drive-by fix; most of the headers had it, and I noticed this one was missing it.

[stuartmorgan-g]

I extracted this helper rather than inlining all of setHoles:. It's shorter than the original because the inner loop was doing exactly what the existing FGMGetPathFromPoints utility method (in the utils file) already does.

[stuartmorgan-g]

The registrar was either copypasta from another object, or it used to be needed and now isn't; it was unused, so I removed it in the refactoring.

[stuartmorgan-g]

This was exposed for testing, but since I inlined it the test now uses updatePolygon:... instead. That also means it's testing more of the codepath.

[vashworth]

LGTM with a few comments

[vashworth]

Do you know if there's any reason to have a separately named getter? I'm assuming you can get it either way, since your code does here

packages/packages/google_maps_flutter/google_maps_flutter_ios/ios/Classes/FGMGroundOverlayController.h

Line 22 in 0130bfc

@property(nonatomic, assign, getter=isCreatedWithBounds) BOOL createdWithBounds;

[stuartmorgan-g]

This is a style guide thing. From the Google Obj-C style guide:

Accessors that return the value of boolean adjectives have method names beginning with is, but property names for those methods omit the is.

Dot notation is used only with property names, not with method names.

// GOOD:

@property(nonatomic, getter=isGlorious) BOOL glorious;
// The method for the getter of the property above is:
// - (BOOL)isGlorious;

BOOL isGood = object.glorious;      // GOOD.
BOOL isGood = [object isGlorious];  // GOOD.
// AVOID:

BOOL isGood = object.isGlorious;    // AVOID.