-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Implement dartPluginClass support for plugins #74469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@jonahwilliams what do you think of this approach? It supports hot-reload, etc... If it makes sense, I will still need to get the metadata from pubspec.yaml, which I don't think it's accessible at this point. |
| print('_registerPlugins is called'); | ||
| } | ||
| void main() { |
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.
If you're going to generate a synthetic entrypoint, then I don't think you need the pragma or anything else special - just invoke _registerPlugins() before calling entrypoint.main.
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.
main can be overridden by the embedding at runtime.
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.
right :) . lots of moving parts here.
|
IIRC this won't work as is without more changes in the resident_runner or the hot reload pipeline. The development compiler needs to be given the same entrypoint to compile as the app was built with - otherwise I don't believe hot reloads will work until a hot restart - and in this case that hot restart would blow away the plugin callback. This will also require some special casing for g3, since they'll likely generate that file in a different way. |
jonahwilliams
left a comment
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.
Still looking at actual implementation, first comment is not to introduce more globals usage
packages/flutter_tools/test/general.shard/build_system/targets/common_test.dart
Show resolved
Hide resolved
jonahwilliams
left a comment
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.
General feedback: it is difficult to do a thorough review without tests, as I'm not quite sure what all of the expected changes are
bcea090 to
892f721
Compare
|
Re: test failures I added On this PR If that's the intended behavior of this PR, those tests should be updated. |
|
Thanks @jmagman. That seems correct based on my changes. (which I had to review again :)) |
| || !podfileLockOutput.contains(':path: Flutter/ephemeral/.symlinks/plugins/url_launcher_macos/macos') | ||
| || !podfileLockOutput.contains(':path: Flutter/ephemeral/.symlinks/plugins/test_plugin_swift/macos') | ||
| || podfileLockOutput.contains('url_launcher/')) { | ||
| || !podfileLockOutput.contains('url_launcher/')) { |
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 spirit of this check was to make sure the url_launcher framework was not embedded in the app. It was using the Podfile.lock as a shortcut for this. A more appropriate test now would be to validate that the generated app contains Contents/Frameworks/url_launcher_macos.framework but not Contents/Frameworks/url_launcher.framework.
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.
got it. I added another check to the test for the time being. Do you have any suggestion about how to verify the frameworks?
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.
Something like
final String appDirectory = path.join(
appPath,
'build',
'macos',
'Build',
'Products',
'Release',
'${path.basename(appPath)}.app',
);
final String frameworksDirectory = path.join(
appDirectory,
'Contents',
'Frameworks',
);
checkDirectoryExists(path.join(
frameworksDirectory,
'url_launcher_macos.framework',
));
checkDirectoryNotExists(path.join(
frameworksDirectory,
'url_launcher.framework',
));There also may be a more appropriate test location for that check, like https://github.com/flutter/flutter/blob/master/packages/flutter_tools/test/integration.shard/macos_content_validation_test.dart
|
This pull request is not suitable for automatic merging in its current state.
|
… infinite recursion in analyzing packages
This reverts commit b7d4806. Kick.
This reverts commit b7d4806. Kick.
This reverts commit b7d4806. Kick.
* Revert "Enable dart_plugin_registry_test (#76645)" This reverts commit 109e0bb. * Revert "Apply changes caused by #76662 (#77093)" This reverts commit cdca648. * Revert "Disable clang format in the plugin registrants (#76662)" This reverts commit dadbd47. * Revert "Disable warnings for the dart plugin registrant (#76561)" This reverts commit 098ece5. * Revert "Remove dart_plugin_registry_test timeouts (#76838)" This reverts commit 1610a27. * Revert "Implement dartPluginClass support for plugins (#74469)" This reverts commit b7d4806. Kick.
…r#74469" (flutter#78623)" This reverts commit 5efc716.
Tool side of #52267
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.