[google_maps_flutter] Add onPoiTap callback to GoogleMap

[AsimRoyChowdhury]

This PR adds support for detecting taps on the base map's Points of Interest.

Issue: Fixes flutter/flutter#60695

Changes:

• platform_interface: Added PointOfInterest type, MapPoiTapEvent, and onPoiTap stream definition.
• android: Implemented OnPoiClickListener in GoogleMapController and wired the event to the method channel.
• ios: Implemented GMSMapViewDelegate POI tap handling and forwarded events to Dart.
• app-facing package: Exposed onPoiTap in the GoogleMap widget and GoogleMapController.
• example: Added a new "Place POI" example page to demonstrate the feature.

Fixes: N/A - This is a new feature.

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[^1].
• 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[^1].
• 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[^1].
• All existing and new tests are passing.

[gemini-code-assist]

Code Review

This pull request introduces the onPoiTap callback to the GoogleMap widget, allowing developers to handle user taps on points of interest on the map. The feature is implemented across the platform interface, Android, and iOS, with corresponding updates to the example application and tests. The changes involve adding new event types, updating platform-specific listeners, and exposing the new callback in the app-facing widget. My review includes suggestions for improving code clarity, test robustness, and fixing a critical dependency issue.

[gemini-code-assist]

The google_maps_flutter_platform_interface version should be ^2.15.0 to match the version in which onPoiTap support was added. The current version ^2.14.0 will cause dependency conflicts or build failures since this package uses types introduced in 2.15.0.

  google_maps_flutter_platform_interface: ^2.15.0

[gemini-code-assist]

This import is redundant as google_maps_flutter_platform_interface is already imported on line 13. Please remove this duplicate line to improve code cleanliness.

[gemini-code-assist]

Using Log.e for debugging messages is not recommended as it implies an error has occurred and can clutter error logs. For debugging purposes, it's better to use Log.d or Log.v. These temporary debug logs should be removed before merging.

[gemini-code-assist]

This test only verifies that a message is sent on the binary messenger, but it doesn't check the content of the message. A more robust test would be to use a mock MapsCallbackApi and verify that onPoiTap is called with the correct data. This ensures that the data is correctly constructed and passed to the Pigeon API.

Here's an example of how you could improve it:

  @Test
  public void onPoiClick_sendsCorrectData() {
    // Assuming 'controller' and 'flutterApi' are set up as in other tests.
    PointOfInterest poi = new PointOfInterest(new LatLng(1.0, 2.0), "placeId", "name");

    controller.onPoiClick(poi);

    ArgumentCaptor<Messages.PlatformPointOfInterest> poiCaptor = ArgumentCaptor.forClass(Messages.PlatformPointOfInterest.class);
    verify(flutterApi).onPoiTap(poiCaptor.capture(), any(Messages.VoidResult.class));

    Messages.PlatformPointOfInterest capturedPoi = poiCaptor.getValue();
    assertEquals("name", capturedPoi.getName());
    assertEquals("placeId", capturedPoi.getPlaceId());
    assertEquals(1.0, capturedPoi.getPosition().getLatitude(), 1e-6);
    assertEquals(2.0, capturedPoi.getPosition().getLongitude(), 1e-6);
  }

[gemini-code-assist]

The POIClickCallback typedef appears to be unused in the codebase. To maintain code cleanliness, please remove it.

[stuartmorgan-g]

Thanks for the contribution!

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.

This needs to follow our documented process for changing federated plugins, so that CI works.

Please also be sure to review the feedback on the previous PR, especially this comment, and update accordingly. Even if this PR doesn't include web support (although it would be preferable if it did, especially since there is a previous PR to draw on), it does need to be designed in such a way as to not cause this problem for web later.

[stuartmorgan-g]

Please follow our standard commenting style. Sentences should be properly punctuated, and we don't use emoji in comments.

[stuartmorgan-g]

pumpAndSettle is for waiting for rendering to complete, not for arbitrary specific tasks. The way to wait for onMapCreated to complete is to have a future that completes when onMapCreated is called, and then wait for that. It is important that tests not be flaky because they are using delays as a proxy for waiting for specific conditions.

[AsimRoyChowdhury]

Please review the package again. I have done the following works:

• Revamped the code as per the review of @stuartmorgan-g and @gemini_code_assist
• Added Support for flutter web for onPoiTap Callback
• Added Integration test for onPoiTap
• Updated Version for the google_maps_flutter_web package

[gemini-code-assist]

Thank you for addressing the feedback regarding the pumpAndSettle usage. The updated test now correctly waits for onMapCreated to complete using a Completer, which is a much more robust approach.

[stuartmorgan-g]

This needs to follow our documented process for changing federated plugins, so that CI works.

This has still not been done. We can't meaningfully review this while it's failing almost all of our CI checks.

[stuartmorgan-g]

Please see the discussion I linked to previously about separating the callback data from querying POI details. Creating a structure that requires data we can't provide and then returning incorrect data is not the API we want.