[google_maps_flutter] Standardize iOS class and file names#10964
[google_maps_flutter] Standardize iOS class and file names#10964stuartmorgan-g wants to merge 10 commits intoflutter:mainfrom
Conversation
|
This is another one I should have done before #10852, but I can reconcile the two PRs once one lands. This annoys me every time I try to work in this plugin, and after all the recent time I've spent in it I couldn't take it any more 😐 |
There was a problem hiding this comment.
Code Review
This pull request standardizes Objective-C class and file names in the google_maps_flutter_ios package. The changes replace the FLT prefix with FGM, remove the GoogleMaps substring from many class names, and rename files to match their class names. Test classes and files have had prefixes removed, and test utility files have been moved into a TestUtils directory. The package version has been updated and a corresponding entry was added to the changelog.
|
Looks like there's still issues with |
|
I think while I was trying to fix whatever weird git state one copy of that file somehow ended up in (blame showed uncommitted changes to those lines, but |
|
The PR is finally in the same state my local machine was, and everything is green. |
Fixes inconsistencies in the class and file naming in
google_maps_flutter_ios:FGMinstead of a mix ofFGMand the olderFLT.GoogleMapsfrom most class names, as now that we are usingFGMwe don't need to further specific that it's related to Google Maps, and removing that makes it much easier to see the useful part of the name.Part of flutter/flutter#102601
Pre-Review Checklist
[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under1.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under1.///).Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2 ↩3