Skip to content

Conversation

@stuartmorgan-g
Copy link
Contributor

@stuartmorgan-g stuartmorgan-g commented Aug 10, 2021

Expands the existing desktop dartPluginClass support, with automatic Dart registration, to Android and iOS.

Since we do not have existing dartPluginClass implementations on mobile, this addresses from the outset the issue described in #87862, so that inline implementations mobile implementations will work as well. This does not attempt to change that behavior for desktop, since that has breaking implications, so will be handled separately.

Fixes #52267

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 Flutter Style Guide, including Features we expect every widget to implement.
  • I signed the CLA.
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt.
  • All existing and new tests are passing.

@stuartmorgan-g stuartmorgan-g requested a review from blasten August 10, 2021 14:48
@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Aug 10, 2021
@google-cla google-cla bot added the cla: yes label Aug 10, 2021
@stuartmorgan-g stuartmorgan-g changed the title Add dartPluginClass support for i Add dartPluginClass support for Android and iOS Aug 10, 2021
targetPlatform != TargetPlatform.linux_arm64 &&
targetPlatform != TargetPlatform.windows_x64 &&
targetPlatform != TargetPlatform.windows_uwp_x64;
final TargetPlatform? targetPlatform = platformName == null ? null
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: what about:

if (platformName == null) {
  return false;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what was there before, and has the effect that if a platform isn't passed it silently does nothing. I'd rather we only opt out for platforms we're sure we don't want to do this, since as a failure mode, failing to do registration silently is much worse that generating a registrant that shouldn't do anything.

final bool hasInlineDartImplementation =
plugin.pluginDartClassPlatforms[platform] != null;
if (defaultImplementation == null && !hasInlineDartImplementation) {
if (throwOnPluginPubspecError) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi: throwOnPluginPubspecError is false due to backward compatibilities.

Should it still print the error, but not exit with code?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the goal is to eliminate this error in a follow-up PR, I think we can leave it as-is for now.

Copy link

@blasten blasten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good. Just some minor comments

@stuartmorgan-g
Copy link
Contributor Author

stuartmorgan-g commented Aug 17, 2021

@blasten How is this intended to interact with flutter test? The reason CI is failing is that there's an end-to-end test that is making an app that includes path_provider (which means it will have a generated Dart registrant), building it for Android, and then running flutter test; that test is failing now. Experimenting locally, what seems to be happening is that if generated_main.dart exists, then flutter test is running its 'main' instead of the widget_test.dart's 'main', and generated_main.dart points directly to main.dart, so the test's main is never run.

If I delete generated_main.dart after building for Android and before running flutter test everything works, but presumably "delete that file at the beginning of flutter test" is not the right fix. Is something supposed to be restructuring the chain of mains here? Or was this a bug with the desktop version that just never got caught?

I'm not sure how to correctly wire this up so that we're calling all of the relevant mains in a test scenario.

@blasten
Copy link

blasten commented Aug 17, 2021

That is definitely problematic. We would detect if a test target is currently used, and set checkDartPluginRegistry: false in

checkDartPluginRegistry: environment.generateDartPluginRegistry,

@blasten
Copy link

blasten commented Aug 17, 2021

Maybe, it can be safely inferred from the target file? If not, we would need to pass that information to the build system.

@flutter-dashboard
Copy link

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

@stuartmorgan-g
Copy link
Contributor Author

With #90288 landed, it looks like the test issues are all resolved. Just waiting on Google test

christopherfujino added a commit that referenced this pull request Oct 4, 2021
stuartmorgan-g added a commit to stuartmorgan-g/flutter that referenced this pull request Oct 5, 2021
generateDartPluginRegistry was being set to true unconditionally in
ResidentRunner, bypassing the primary check in
DartPluginRegistrantTarget, and the targetPlatform was not set in that
codepath, bypassing the second after the changes in
flutter#87991. This caused web hot
restarts to be slower due to doing unnecessary work.

This ensures that generateDartPluginRegistry is false in the
ResidentWebRunner to skip that unnecessary step.

Fixes flutter#91262
zanderso added a commit that referenced this pull request Oct 5, 2021
* Don't generate plugin registry in ResidentWebRunner

generateDartPluginRegistry was being set to true unconditionally in
ResidentRunner, bypassing the primary check in
DartPluginRegistrantTarget, and the targetPlatform was not set in that
codepath, bypassing the second after the changes in
#87991. This caused web hot
restarts to be slower due to doing unnecessary work.

This ensures that generateDartPluginRegistry is false in the
ResidentWebRunner to skip that unnecessary step.

Fixes #91262

* Formatting

Co-authored-by: Zachary Anderson <[email protected]>

Co-authored-by: Zachary Anderson <[email protected]>
clocksmith pushed a commit to clocksmith/flutter that referenced this pull request Oct 29, 2021
clocksmith pushed a commit to clocksmith/flutter that referenced this pull request Oct 29, 2021
* Don't generate plugin registry in ResidentWebRunner

generateDartPluginRegistry was being set to true unconditionally in
ResidentRunner, bypassing the primary check in
DartPluginRegistrantTarget, and the targetPlatform was not set in that
codepath, bypassing the second after the changes in
flutter#87991. This caused web hot
restarts to be slower due to doing unnecessary work.

This ensures that generateDartPluginRegistry is false in the
ResidentWebRunner to skip that unnecessary step.

Fixes flutter#91262

* Formatting

Co-authored-by: Zachary Anderson <[email protected]>

Co-authored-by: Zachary Anderson <[email protected]>
auto-submit bot pushed a commit that referenced this pull request Jul 11, 2024
These changes allow to override existing native endorsed (federated & inline) plugins with e.g. non-endorsed plugin implementations via direct dependencies as described in the section *Platform implementation selection* in the [design doc](https://docs.google.com/document/d/1LD7QjmzJZLCopUrFAAE98wOUQpjmguyGTN2wd_89Srs).

```yaml
# pubspec.yaml
name: example
dependencies:
  my_plugin: ^0.0.1
  my_plugin_android_alternative: ^0.0.1
```

Closes #80374, closes #59657

Related: Override Dart plugins (#87991, #79669)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement dartPluginClass support for plugins

4 participants