@matthew-carroll I don't think I'm as keyed in on this as you are at this point, but my instinct here would actually be to expose the underlying SurfaceView at some appropriate point for advanced users who really need to call SurfaceView specific APIs like this instead of trying to plumb calls all the way through the Android embedding that are ultimately view specific like this one to whatever view is attached. I get that we don't want to provide a false sense of security that any given view will remain associated with a particular engine, which as I understand it was the main problem with the v1 API exposing the view through some of its getters. But I also think wrapping plain old View APIs at a higher level would also be a mistake because then we'd be forcing clients to learn our wrapper layer in addition to Android, and it would inherently be a little confusing where all the API calls wouldn't work in all cases like you've mentioned, and we'd always be lagging in cases like this where we wouldn't be exposing the full API surface some users may want or need.

So ultimately I'd think of exposing a getView method on FlutterActivityAndFragmentDelegate with some clear warnings that there's no guarantees that the view is going to stay current for any amount of time after the API call. Maybe expose it only through some new callback registration so API users who care are forced to register onAdded/onRemoved listeners and so it's obvious through the API that the view is impermanent? That would match the rest of the flow. Could also give the Flutter view a specific ID and tell users who really want it to go find it within the layout directly, but it would be harder to do this since we don't distribute the engine as an AAR right now and so wouldn't be able to distribute the ID as an XML resource.

Expose setZOrderMediaOverlay in the new embedding #41984

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions