[google_maps_flutter] cloud-based map styling implementation

[jokerttu]

This PR is sub-PR splitted out from the #3682
containing only following packages:

• google_maps_flutter_web
• google_maps_flutter_android
• google_maps_flutter_ios

Related to issue flutter/flutter#67631

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• 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 listed 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 this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[stuartmorgan]

I left a couple of comments about some small testing improvements that should be easy to add.

Unfortunately the overall testing of this feature is quite thin; the Dart integration test doesn't actually test that anything works beyond not crashing (i.e., they would pass even if we reverted all of the native changes), but given that we don't have real API testing working in general I don't see a way to do address that without blocking this feature indefinitely, so we'll have to live with that for now.

(Ideally we'd also do native unit testing of the native code, but we don't have the native test scaffolding set up for that; I'll file an issue for that rather than blocking this.)

[ditman]

Web bits LGTM.

I agree with Stuart that the testing is very bare bones, but this is the downside of a cloud-based feature, the plugin is completely unaware of what the endpoints end up doing.

Every testing solution I can think of is pretty brittle; for example: taking a screenshot and comparing against a reference image, or (in the web) inspecting the inner DOM of the map and see if we can find the mapId somewhere, or traces of WebGL ;)

[stuartmorgan]

Yes, I think the best we'll be able to do is just test that we're passing it through both the Dart->native (what I requested above) and native->SDK layers (filed as flutter/flutter#131851 for follow-up). Once we have that, the only plausible breakages I can think of on our side would be if that was insufficient (e.g., if at some point there were a requirement that some other data be passed with the cloud ID in order for it to work, in which case our tests would still pass but the feature wouldn't), but that's relatively low risk.

[ditman]

Yep, there's not much more we can do. The only breaking scenario that I can think of is if mapId makes some of the other properties that we accept incompatible/obsolete (imagine a map that happens to have "cloud styling" applied suddenly starts rejecting the local mapStyle property with an error)

[jokerttu]

I have added a few Dart unit tests as requested. These tests verify that the given cloudMapId is passed to the platform view via the method channel upon its creation.

Since the Maps SDK doesn't provide a means to retrieve the passed cloudMapId after a map instance is initialized, or even a status to indicate if the map has loaded with the applied cloud-based styling, I don't see any alternatives for effectively checking whether the cloud-based map styling is really applied, other than visual test comparison using screenshots.

It is possible to save the passed cloudMapId string at native side for our instance and pass that back over the GoogleMapsInspectorPlatform method implementation. Then it would be possible to test on integration tests that the requested mapId has been passed from the dart->native, but this won't test if the map is really initialized with the given mapId. If this is something you want to have, I can update the PR with this feature.

[reidbaker]

Leaving final approval for stuart but android and dart bits LGTM.

[stuartmorgan]

Sorry for the delay, LGTM. Thanks for adding the tests!

[auto-submit]

auto label is removed for flutter/packages/4638, due to Pull request flutter/packages/4638 is not in a mergeable state.

[jokerttu]

@stuartmorgan: merged with main and fixed Changelog conflicts

[cedvdb]

Note that the styles seem to be passed into the map still. On the web platform this gives a warning

Google Maps JavaScript API: A Map's styles property cannot be set when a mapId is present. When a mapId is present, Map styles are controlled via the cloud console. Please see documentation at https://developers.google.com/maps/documentation/javascript/styling#cloud_tooling

The property styles should not be part of the map options when a mapId is set.

[stuartmorgan]

@cedvdb Please report issues with landed code in the issue tracker; changes can't be made here as this is already merged.

[cedvdb]

@stuartmorgan will do, I was too lazy to make a repro but I can probably find the strength to do it today.