[android] Give the shared engine app a chance to take control of application lifecycle state events. #30208
Conversation
|
The linked issues are un-prioritized. cc @blasten for guidance on is this is something we should do. |
c0b2fc8 to
5fe6d8b
Compare
In the add-to-app scenario, many applications choose the technical solution where multiple FlutterActivity shares the single cached engine. When a new FlutterActivity attaches to the single cached engine and the previous FlutterActivity detaches from it, the sequence of app lifecycle events will be unexpected and cause the new FlutterActivity to be frozen. See flutter/flutter#49950 for details. If we give the host application a chance to take control of the app lifecycle events, |
|
Ping @blasten for review. |
|
@blasten: You may be inundated to review requests. Is there anyone else I should redirect these reviews to? |
|
oh sorry, I had this PR opened in a tab. |
| * Give the host application a chance to take control of the app lifecycle events. | ||
| * | ||
| * <p>Return {@code false} means the host application dispatches these app lifecycle events, while | ||
| * return {@code true} means the engine dispatches these events. |
There was a problem hiding this comment.
can we explain why anyone may want to do this? The more context, the better.
I left some areas to cover in flutter/flutter#94702 (comment)
There was a problem hiding this comment.
can we explain why anyone may want to do this? The more context, the better.
I left some areas to cover in flutter/flutter#94702 (comment)
/**
* Give the host application a chance to take control of the app lifecycle events to avoid
* lifecycle crosstalk.
*
* <p>In the add-to-app scenario where multiple {@link FlutterActivity} shares the same {@link
* FlutterEngine}, the application lifecycle state will have crosstalk causing the page to
* freeze. For example, we open a new page called FlutterActivity#2 from the previous page
* called FlutterActivity#1. The flow of app lifecycle states received by dart is as follows:
*
* <p>inactive (from FlutterActivity#1) -> resumed (from FlutterActivity#2) -> paused (from
* FlutterActivity#1)
*
* <p>On the one hand, the {@code paused} state from FlutterActivity#1 will cause the
* FlutterActivity#2 page to be stuck; On the other hand, these states are not expected from the
* perspective of the entire application lifecycle. If the host application gets the control of
* sending {@link AppLifecycleState}, It will be possible to correctly match the {@link
* AppLifecycleState} with the application-level lifecycle.
*
* <p>Return {@code false} means the host application dispatches these app lifecycle events,
* while return {@code true} means the engine dispatches these events.
*/
boolean shouldDispatchAppLifecycleState();…ication lifecycle state events.
5fe6d8b to
bbf9039
Compare
|
@blasten This seems to be good for another review attempt. |
|
Ping @blasten |
| * | ||
| * <p>Return {@code false} means the host application dispatches these app lifecycle events, | ||
| * while return {@code true} means the engine dispatches these events. | ||
| */ |
There was a problem hiding this comment.
would you like to contribute with an e2e test?
There was a problem hiding this comment.
@blasten Thank you for your reply.
Does the e2e test block this PR? I may be available to write the e2e test after two weeks.
BTW, It would be nice if there was an e2e test guideline. :)
… of application lifecycle state events. (flutter/engine#30208)
Give the shared engine app a chance to take control of application lifecycle state events.
Related issues:
flutter/flutter#52456
flutter/flutter#94702
flutter/flutter#49950
Pre-launch Checklist
writing and running engine tests.
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.