Rework lifecycle reference provided to plugins to force plugins to use another plugin to dereference a Lifecycle object. #12715
Conversation
| * concerned about which Android Component is currently holding the {@link FlutterEngine}. | ||
| * TODO(mattcarroll): add info about ActivityAware and ServiceAware for plugins that care. | ||
| */ | ||
| class FlutterPluginBinding implements LifecycleOwner { |
There was a problem hiding this comment.
does it also need to remove the imports?
There was a problem hiding this comment.
I can definitely clean things up, but does this PR and the other PR look like they accomplish the goal? Mostly I'm wondering if this allows us to achieve the desired decoupling in plugins...
There was a problem hiding this comment.
I took another look at this class and there is a package private constructor at the bottom that takes in an actual Lifecycle. So unless we make further changes, we still need the import. Do you think there's any issue with what we have here?
shell/platform/android/io/flutter/embedding/engine/plugins/FlutterPlugin.java
Show resolved
Hide resolved
| * {@link Lifecycle} in a way that makes it easier for Flutter and the Flutter plugin ecosystem to | ||
| * handle breaking changes in Lifecycle libraries. | ||
| */ | ||
| public class HiddenLifecycleReference { |
There was a problem hiding this comment.
I'm curious - would it work if we make this a private class, and keep the exact same code duplicated as a private class in the lifecycle plugin (and in the plugin cast the Object to it's copy of HiddenLifecycleReference) ?
There was a problem hiding this comment.
I'm not sure, but I'd recommend against it. I think the answer to that question will always be determined by the details of Dalvik, Art, and any future bytecode system. If this were Objective-C then we might be able to do what you're saying because those dispatch tables can use strings as method identifiers, but the closest thing that Java has is reflection, which I think would be more trouble than it's worth.
...platform/android/io/flutter/embedding/engine/plugins/lifecycle/HiddenLifecycleReference.java
Outdated
Show resolved
Hide resolved
|
Shall we be updating FlutterEngine as well? e.g it's still possible for a plugin to do |
|
For the record, this PR cannot be merged until we have merged and published the flutter_android_lifecycle plugin: |
…e another plugin to dereference a Lifecycle object.
…ecycle package can access via reflection instead of compile-time references.
matthew-carroll
force-pushed
the
rework_plugin_lifecycle_reference
branch
from
ac1098f to
e46e58a
Compare
matthew-carroll
force-pushed
the
rework_plugin_lifecycle_reference
branch
from
e46e58a to
90e5353
Compare
| * <p> | ||
| * <strong>DO NOT USE THIS CLASS IN AN APP OR A PLUGIN.</strong> | ||
| * <p> | ||
| * This class is used by the flutter_android_lifecycle package to provide access to a |
There was a problem hiding this comment.
We need to update this to flutter_plugin_android_lifecycle
|
https://pub.dev/packages/flutter_plugin_android_lifecycle published, feel free to land this (after updating the comment with the final plugin name) |
|
Closing in favor of #13402 |
4 participants
Rework lifecycle reference provided to plugins to force plugins to use another plugin to dereference a Lifecycle object.
Plugin side:
flutter/plugins#2129