[google_maps_flutter] Federate mobile implementations #6171
Conversation
|
|
||
| ## Usage | ||
|
|
||
| This package is [endorsed][2], which means you can simply use |
There was a problem hiding this comment.
Link to README of google_maps_flutter would be useful here to smooth out the user journey
There was a problem hiding this comment.
It's already linked a few lines above. (Also, the standard user journey is "nobody ever sees this file, or thinks much about this package at all" 🙂 )
packages/google_maps_flutter/google_maps_flutter_android/CHANGELOG.md
Outdated
Show resolved
Hide resolved
| commit-message: | ||
| prefix: "[google_maps]" | ||
| schedule: | ||
| interval: "weekly" | ||
| open-pull-requests-limit: 10 | ||
|
|
||
| - package-ecosystem: "gradle" | ||
| directory: "/packages/google_maps_flutter/google_maps_flutter/example/android/app" | ||
| directory: "/packages/google_maps_flutter/google_maps_flutter_android/android" |
There was a problem hiding this comment.
Are these two examples apps now duplicated or are they different?
There was a problem hiding this comment.
They are basically the same; see flutter/flutter#46716
Longer term it's something we want to fix, but we haven't been blocking federation on it. (It's a bit tricky to solve even beyond the package structure logistics, because sometimes, like here, we have shims that make the actual example code almost identical, whereas in others the examples are written against a different API layer; it depends on whether there is important widget code in the app-facing package. So we'll need a flexible approach.)
Yep, I've checked that drive is actually running tests for |
Moves the iOS and Android implementations to their own federated packages.
Temporarily marks
google_maps_flutteras unpublishable to allow the implementations to be moved, rather than copied and deleted, in order to better preserve git history. A follow-up PR will restore it to publishable form.In addition to moving the existing implementations, this adds the step of moving to in-platform method channels using platform-specific Dart implementations. Usually I make that a follow-up PR, but doing it this way means that I can clean up the tech debt of having the integration test inspector implementation for the shared method channel implementation living in the app-facing package (since I can rely on all implementations that we are testing with now providing their own implementations of the inspector). As usual, the Dart implementations and their tests are starting out as exact copies with only minor changes:
registerWith()and a test for itAlso as usual, currently the implementation package example and integration tests are all direct copies of the app-facing version, except for trimming out wrong-platform-specific test code from the platform implementation versions. Over time we can tune which things we test in both places vs just implementation packages.
Fixes flutter/flutter#68498
Fixes flutter/flutter#94224
Pre-launch Checklist
dart format.)[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style.///).