This repository was archived by the owner on Feb 22, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
Support Hybrid Composition through the GoogleMaps Widget #4082
Merged
Merged
Changes from 1 commit
Commits
Show all changes
17 commits
Select commit
Hold shift + click to select a range
b17d1dc
start
bparrishMines 82c4614
change to hybrid composition in example
bparrishMines 7b6f801
UPdate readme
bparrishMines 736c073
Merge branch 'master' of github.com:flutter/plugins into android_maps
bparrishMines f6631b4
update README and remove unnecessary line
bparrishMines 50b548e
Merge branch 'master' of github.com:flutter/plugins into android_maps
bparrishMines 944d965
use buildViewWithTextDirection by default
bparrishMines e345f3a
remove hash
bparrishMines 1809e66
add default value if no directionality ancestor
bparrishMines f504ffc
remove mactro
bparrishMines be87b94
change text direction to layout direction
bparrishMines cf87583
Merge branch 'master' of github.com:flutter/plugins into android_maps
bparrishMines d907845
create android settings class
bparrishMines 58c3028
update readme
bparrishMines 0c26d6c
Update google_map.dart
bparrishMines 86f965c
Merge branch 'master' of github.com:flutter/plugins into android_maps
bparrishMines 35a8186
Merge branch 'master' of github.com:flutter/plugins into android_maps
bparrishMines File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -21,7 +21,10 @@ dependencies: | |
| flutter: | ||
| sdk: flutter | ||
| flutter_plugin_android_lifecycle: ^2.0.1 | ||
| google_maps_flutter_platform_interface: ^2.0.0 | ||
| google_maps_flutter_platform_interface: | ||
| git: | ||
| url: [email protected]:flutter/plugins.git | ||
| path: packages/google_maps_flutter/google_maps_flutter_platform_interface | ||
|
|
||
| dev_dependencies: | ||
| flutter_test: | ||
|
|
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't the new method be called unconditionally? The delegation to the old method was supposed to be handled by a default implementation in the platform interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default implementation (
MethodChannelGoogleMapsFlutter) does call the old method if the platform is not android or hybrid composition is turned off. However, web switches to another platform instance: https://github.com/flutter/plugins/blob/master/packages/google_maps_flutter/google_maps_flutter_web/lib/src/google_maps_flutter_web.dart#L13.So in this case, we would need to call the other method, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, that was poorly phrased; by "default implementation" I mean the code that's part of the base class that all implementations extend from. Having a fallback implementation there is what makes this overall change harmless even for federated implementations we don't even know about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok. So buildViewWithTextDirection was only added to
MethodChannelGoogleMapsFlutterand not to GoogleMapsFlutterPlatform. This is same for the flaguseAndroidViewSurface. This was done because this was an Android only requirement.Were you thinking that
buildViewWithTextDirectionshould have been added toGoogleMapsFlutterPlatformas well? I think that makes more sense and could be done without a breaking change.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was what I had intended in the discussion, yes. However, IIRC there was discussion of this being temporary, in which case I'm okay with this approach if you don't want to go back and make another change to the platform interface given that it's already been done. (If this were permanent, it would be more important that we not embed implementation-specific code here as much as possible.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this method to only be temporary, the platform_interface would have to be broken and bumped to version 3.0. This is because any implementation would need to add the additional parameter to their method. However, I believe the policy is to avoid breaking changes to the platform_interface.
An alternative is to have two methods, and to call
buildViewWithTextDirectionby default ingoogle_maps_flutter. But this would still break any implementation that doesn't implementbuildViewWithTextDirectionas the method would throw anUnimplementedError().This PR essentially makes
buildViewWithTextDirectionunique toMethodChannelPlatform. TheGoogleMapwidget then calls it iff it isMethodChannelPlatform. I believe this avoids any breaking changes and any of the implementations would still work with the plugin.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's why I had recommended having the method not throw UnimplementedError, but instead calling the old method.
But my question wasn't about implemented, but the ideal goal: do we want this new parameter forever, or is the need for this parameter temporary? I had thought it was the latter, but again, I may have misunderstood.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you wanted that done at the interface level and not the implementation level. That makes since.
This parameter is required for Android hybrid composition unless we don't want the user to be able to change the text direction. I haven't seen a way around it yet that doesn't involve framework changes. My intention is that it's a permanent parameter.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, sorry for the confusion on my part about the intended lifespan. In that case yes, I think we should update the platform interface to have a default implementation that calls the old method with a default value. Then implementations (those that want a different behavior than that default) can override both, but nobody will be broken and the details of who implements what won't bleed into this package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That works for me! I updated #4121 to reflect this.