[video_player] Adds platform view support on macOS

[stuartmorgan-g]

Adds macOS support for the platform view display option, brining macOS in line with the iOS implementation.

This:

• extracts the macOS additions from [video_player_avfoundation] macOS platform view support #8558 as cherry picks,
• updates it for some changes that happened during iOS review, and
• makes some minor adjustments (mostly combining the factory classes into one shared file)

Part of flutter/flutter#86613

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PRx falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[stuartmorgan-g]

This takes over #8558, since I wanted to make sure we don't lose that work and have unnecessary platform forking in the plugin.

[LongCatIsLooong]

Doesn't this make this NSView's layer a AVPlayerLayer? If so why do we still need to initialize another AVPlayerLayer (in initWithFrame) and add it to this layer as a child?

[LongCatIsLooong]

Also what's the purpose of this NSView subclass, can the logic be moved to FVPNativeVideoView instead?

[stuartmorgan-g]

Doesn't this make this NSView's layer a AVPlayerLayer?

It turns out that this does... nothing. layerClass is an iOS-ism that isn't implemented on macOS. The fun of using a language without override annotations to warn about this kind of mistake. The macOS equivalent is the slightly more cumbersome makeBackingLayer.

If so why do we still need to initialize another AVPlayerLayer (in initWithFrame) and add it to this layer as a child?

I suspect that not realizing the above is the answer to this question 🙂

Also what's the purpose of this NSView subclass, can the logic be moved to FVPNativeVideoView instead?

Probably translating too closely from the iOS version, and on iOS the platform view APIs are a bit weirder. Although now I'm thinking I should take another look at the iOS version to see if we actually need a second view there; we may be able to simplify that code too. (I refreshed my memory of these APIs, and I'm pretty sure that's what happened. On iOS, FlutterPlatformView isn't a view at all, it's a protocol that does nothing but return a view. That seemed so strange that I didn't replicate it into the macOS version of the API when I was bringing up the macOS embedding, so on macOS there is no wrapper object, so no need for two objects at all.)

[stuartmorgan-g]

Thanks, I was so focused on updating the PR to current main that I didn't (dust off my long-unused layer-backed NSView experience and) step back and do a big-picture review of the structure of this part of the code.

The new version is much simpler, and seems to work well in my testing.

[stuartmorgan-g]

Doesn't this make this NSView's layer a AVPlayerLayer?

It turns out that this does... nothing. layerClass is an iOS-ism that isn't implemented on macOS. The fun of using a language without override annotations to warn about this kind of mistake. The macOS equivalent is the slightly more cumbersome makeBackingLayer.

If so why do we still need to initialize another AVPlayerLayer (in initWithFrame) and add it to this layer as a child?

I suspect that not realizing the above is the answer to this question 🙂

Also what's the purpose of this NSView subclass, can the logic be moved to FVPNativeVideoView instead?

Probably translating too closely from the iOS version, and on iOS the platform view APIs are a bit weirder. Although now I'm thinking I should take another look at the iOS version to see if we actually need a second view there; we may be able to simplify that code too. (I refreshed my memory of these APIs, and I'm pretty sure that's what happened. On iOS, FlutterPlatformView isn't a view at all, it's a protocol that does nothing but return a view. That seemed so strange that I didn't replicate it into the macOS version of the API when I was bringing up the macOS embedding, so on macOS there is no wrapper object, so no need for two objects at all.)

[LongCatIsLooong]

LGTM!