-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Change timing of onSurfaceDestroyed to match onSurfaceCleanup
#161252
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
Change timing of onSurfaceDestroyed to match onSurfaceCleanup
#161252
Conversation
| * </pre> | ||
| */ | ||
| default void onSurfaceCleanup() {} | ||
| default void onSurfaceCleanup() { |
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.
Should we be in control of the call to onSurfaceDestroyed?
Seems confusing that if I override onSurfaceCleanup that this other life cycle method stops firing.
On the other hand, it's nice that if you use onSurfaceCleanup you don't have to worry about what to do with onSurfaceDestroyed because it won't ever be called.
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.
We should at least document this
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.
Done, and applied to created/available as well for consistency,
|
This looks good to me. I believe it should solve the video player issue, though I'm not familiar with camerax. |
…utter#161252) Follow-up to flutter#160937 (flutter#160933). This more or less mirrors what we did already for `onSurfaceCreated` to match `onSurfaceAvailable`. With this approach, the master branch should immediately start seeing better behavior in terms of being able to use the `onSurfaceDestroyed` callback effectively (before the surface has been released). For example, for a plugin that already uses `onSurfaceDestroyed`, [i.e `camerax`](https://github.com/flutter/packages/blob/97ce56a68eea650dc784617b4eed7814cccedeb8/packages/camera/camera_android_camerax/android/src/main/java/io/flutter/plugins/camerax/PreviewHostApiImpl.java): ```java @OverRide public void onSurfaceDestroyed() { // Invalidate the SurfaceRequest so that CameraX knows to to make a new request // for a surface. request.invalidate(); } ``` ... the request is now invalidated _before_ the surface has been destroyed, which is what (I believe) we wanted? --- Folks that want to publish package updates that _definitely_ use the correct timing will have to wait for the next stable. /cc @hasali19 would be great to get your input here.
Follow-up to #160937 (#160933).
This more or less mirrors what we did already for
onSurfaceCreatedto matchonSurfaceAvailable.With this approach, the master branch should immediately start seeing better behavior in terms of being able to use the
onSurfaceDestroyedcallback effectively (before the surface has been released). For example, for a plugin that already usesonSurfaceDestroyed, i.ecamerax:... the request is now invalidated before the surface has been destroyed, which is what (I believe) we wanted?
Folks that want to publish package updates that definitely use the correct timing will have to wait for the next stable.
/cc @hasali19 would be great to get your input here.