-
Notifications
You must be signed in to change notification settings - Fork 6k
Rework lifecycle reference provided to plugins to force plugins to use another plugin to dereference a Lifecycle object. #12715
Changes from all commits
1c2daa2
6c046b9
a47fc8b
2cfc39a
90e5353
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| // Copyright 2013 The Flutter Authors. All rights reserved. | ||
| // Use of this source code is governed by a BSD-style license that can be | ||
| // found in the LICENSE file. | ||
|
|
||
| package io.flutter.embedding.engine.plugins.lifecycle; | ||
|
|
||
| import android.arch.lifecycle.Lifecycle; | ||
| import android.support.annotation.Keep; | ||
| import android.support.annotation.NonNull; | ||
|
|
||
| /** | ||
| * An {@code Object} that can be used to obtain a {@link Lifecycle} reference. | ||
| * <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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need to update this to flutter_plugin_android_lifecycle |
||
| * {@link Lifecycle} in a way that makes it easier for Flutter and the Flutter plugin ecosystem to | ||
| * handle breaking changes in Lifecycle libraries. | ||
| */ | ||
| @Keep | ||
| public class HiddenLifecycleReference { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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) ?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
| @NonNull | ||
| private final Lifecycle lifecycle; | ||
|
|
||
| public HiddenLifecycleReference(@NonNull Lifecycle lifecycle) { | ||
| this.lifecycle = lifecycle; | ||
| } | ||
|
|
||
| @NonNull | ||
| public Lifecycle getLifecycle() { | ||
| return lifecycle; | ||
| } | ||
| } | ||
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.
does it also need to remove the imports?
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?