This repository was archived by the owner on Feb 25, 2025. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6k
New Plugin API PR4: Adds Lifecycle support to the new plugin system. #9049
Merged
matthew-carroll
merged 3 commits into
flutter:master
from
matthew-carroll:31589_new_plugin_api_pr4
May 25, 2019
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
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
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
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
126 changes: 126 additions & 0 deletions
126
shell/platform/android/io/flutter/embedding/engine/FlutterEngineAndroidLifecycle.java
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 |
|---|---|---|
| @@ -0,0 +1,126 @@ | ||
| package io.flutter.embedding.engine; | ||
|
|
||
| import android.arch.lifecycle.DefaultLifecycleObserver; | ||
| import android.arch.lifecycle.Lifecycle; | ||
| import android.arch.lifecycle.LifecycleObserver; | ||
| import android.arch.lifecycle.LifecycleOwner; | ||
| import android.arch.lifecycle.LifecycleRegistry; | ||
| import android.support.annotation.NonNull; | ||
| import android.support.annotation.Nullable; | ||
|
|
||
| /** | ||
| * Android {@link Lifecycle} that is owned by a {@link FlutterEngine}. | ||
| * <p> | ||
| * {@code FlutterEngineAndroidLifecycle} exists so that {@code FlutterPlugin}s can monitor Android | ||
| * lifecycle events. When the associated {@link FlutterEngine} is running in an {@code Activity}, | ||
| * that {@code Activity}'s {@link Lifecycle} can be set as the {@code backingLifecycle} of this | ||
| * class, allowing all Flutter plugins to receive the {@code Activity}'s lifecycle events. Likewise, | ||
| * when the associated {@link FlutterEngine} is running in a {@code Service}, that {@code Service}'s | ||
| * {@link Lifecycle} can be set as the {@code backingLifecycle}. | ||
| * <p> | ||
| * Sometimes a {@link FlutterEngine} exists in a non-lifecycle location, e.g., an {@code Application}, | ||
| * {@code ContentProvider}, or {@code BroadcastReceiver}. In these cases, this lifecycle reports | ||
| * itself in the {@link Lifecycle.State#CREATED} state. | ||
| * <p> | ||
| * Regardless of what happens to a backing {@code Activity} or @{code Service}, this lifecycle | ||
| * will only report itself as {@link Lifecycle.State#DESTROYED} when the associated {@link FlutterEngine} | ||
| * itself is destroyed. This is because a {@link Lifecycle} is not allowed to emit any events after | ||
| * going to the {@link Lifecycle.State#DESTROYED} state. Thus, this lifecycle cannot emit such an | ||
| * event until its associated {@link FlutterEngine} is destroyed. This then begs the question, what | ||
| * happens when the backing {@code Activity} or {@code Service} is destroyed? This lifecycle will | ||
| * report the process up to the {@link Lifecycle.Event#ON_STOP} event, but will ignore the | ||
| * {@link Lifecycle.Event#ON_DESTROY} event. At that point, this lifecycle will be back in its | ||
| * default {@link Lifecycle.State#CREATED} state until some other backing {@link Lifecycle} is | ||
| * registered. | ||
| */ | ||
| final class FlutterEngineAndroidLifecycle extends LifecycleRegistry { | ||
| private static final String TAG = "FlutterEngineAndroidLifecycle"; | ||
|
|
||
| @Nullable | ||
| private Lifecycle backingLifecycle; | ||
| private boolean isDestroyed = false; | ||
|
|
||
| private final LifecycleObserver forwardingObserver = new DefaultLifecycleObserver() { | ||
| @Override | ||
| public void onCreate(@NonNull LifecycleOwner owner) { | ||
| // No-op. The FlutterEngine's Lifecycle is always at least Created | ||
| // until it is Destroyed, so we ignore onCreate() events from | ||
| // backing Lifecycles. | ||
| } | ||
|
|
||
| @Override | ||
| public void onStart(@NonNull LifecycleOwner owner) { | ||
| handleLifecycleEvent(Event.ON_START); | ||
| } | ||
|
|
||
| @Override | ||
| public void onResume(@NonNull LifecycleOwner owner) { | ||
| handleLifecycleEvent(Event.ON_RESUME); | ||
| } | ||
|
|
||
| @Override | ||
| public void onPause(@NonNull LifecycleOwner owner) { | ||
| handleLifecycleEvent(Event.ON_PAUSE); | ||
| } | ||
|
|
||
| @Override | ||
| public void onStop(@NonNull LifecycleOwner owner) { | ||
| handleLifecycleEvent(Event.ON_STOP); | ||
| } | ||
|
|
||
| @Override | ||
| public void onDestroy(@NonNull LifecycleOwner owner) { | ||
| // No-op. We don't allow FlutterEngine's Lifecycle to report destruction | ||
| // until the FlutterEngine itself is destroyed. This is because a Lifecycle | ||
| // is contractually obligated to send no more event once it gets to the | ||
| // Destroyed state, which would prevent FlutterEngine from switching to | ||
| // the next Lifecycle that is attached. | ||
| } | ||
| }; | ||
|
|
||
| FlutterEngineAndroidLifecycle(@NonNull LifecycleOwner provider) { | ||
| super(provider); | ||
| } | ||
|
|
||
| public void setBackingLifecycle(@Nullable Lifecycle lifecycle) { | ||
| ensureNotDestroyed(); | ||
|
|
||
| // We no longer want to propagate events from the old Lifecycle. Deregister our forwarding observer. | ||
| if (backingLifecycle != null) { | ||
| backingLifecycle.removeObserver(forwardingObserver); | ||
| } | ||
|
|
||
| // Manually move us to the Stopped state before we switch out the underlying Lifecycle. | ||
| handleLifecycleEvent(Event.ON_STOP); | ||
|
|
||
| // Switch out the underlying lifecycle. | ||
| backingLifecycle = lifecycle; | ||
|
|
||
| if (backingLifecycle != null) { | ||
| // Add our forwardingObserver to the new backing Lifecycle so that this PluginRegistry is | ||
| // controlled by that backing lifecycle. Adding our forwarding observer will automatically | ||
| // result in invocations of the necessary Lifecycle events to bring us up to speed with the | ||
| // new backingLifecycle, e.g., onStart(), onResume(). | ||
| lifecycle.addObserver(forwardingObserver); | ||
| } | ||
| } | ||
|
|
||
| @Override | ||
| public void handleLifecycleEvent(@NonNull Event event) { | ||
| ensureNotDestroyed(); | ||
| super.handleLifecycleEvent(event); | ||
| } | ||
|
|
||
| public void destroy() { | ||
| ensureNotDestroyed(); | ||
| setBackingLifecycle(null); | ||
| markState(State.DESTROYED); | ||
| isDestroyed = true; | ||
| } | ||
|
|
||
| private void ensureNotDestroyed() { | ||
| if (isDestroyed) { | ||
| throw new IllegalStateException("Tried to invoke a method on a destroyed FlutterEngineAndroidLifecycle."); | ||
| } | ||
| } | ||
| } | ||
Oops, something went wrong.
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.
It's unexpected to me that
onDestroyedwould be special cased to theFlutterEnginespecifically and that it's impossible to get anonDestroyedcallback for the actual underlying lifecycle. Any way we could propagate this information life normal without breaking any kind of Engine contract? Add in anonEngineDestroyedmethod just for this class to handle the final engine destruction?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 contract that we're trying not to violate is the
Lifecyclecontract, not theFlutterEnginecontract: https://developer.android.com/reference/android/arch/lifecycle/Lifecycle.State#destroyedThe unique thing about
FlutterEngineis that its backingLifecyclecan change over time. It goes fromActivitytoServiceto nothing toActivityagain. There is nothing preventing us from forwarding anActivity'sON_DESTROYevent, but then any other code that is designed to understandLifecycleevents will have undefined behavior when theFlutterEngine'sLifecycleturns right around and emits anON_CREATEDevent. Additionally, it is also conceptually incorrect to send thatON_DESTROYevent because even though theActivityhas been destroyed, theFlutterEngineremains, and at the end of the day thisLifecycleis truly owned by theFlutterEngine, it just temporarily takes on theLifecycleof various Android components.Does that make sense?